OpenBMB / OpenBMB/PilotDeck

MCP wire names mis-parse server IDs containing double underscores

Open
#424 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
4k
Forks
453
Avg merge
12h 30m
Merged PRs (30d)
46

Description

MCP wire names mis-parse server IDs containing double underscores

Summary

buildMcpToolWireName() formats MCP tool names as mcp__<serverId>__<toolName>. The normalizer allows underscores, including double underscores, but parseMcpToolWireName() splits on the first __ after the mcp__ prefix. As a result, a server ID containing __ is parsed as a different server/tool pair.

Affected revision

Observed on main at 9ad10eb0e1ed75f864ca8cbda7f659f7c3b163e9.

Affected code

  • src/mcp/runtime/wireName.ts:4 documents the format as mcp__<serverId>__<toolName>.
  • src/mcp/runtime/wireName.ts:6-9 documents the allowed segment characters as [A-Za-z0-9_-], which permits underscores.
  • src/mcp/runtime/wireName.ts:12-13 builds the wire name.
  • src/mcp/runtime/wireName.ts:21-24 parses by splitting at the first __.

Reproduction

From the repository root:

cat > repro-wire-name.mts <<'EOF'
import {
  buildMcpToolWireName,
  parseMcpToolWireName,
} from "./src/mcp/runtime/wireName.ts";

const serverId = "0__A";
const toolName = "a";
const wireName = buildMcpToolWireName(serverId, toolName);
const parsed = parseMcpToolWireName(wireName);

console.log({
  serverId,
  toolName,
  wireName,
  parsed,
  expected: { serverId, toolName },
  roundTrips: parsed?.serverId === serverId && parsed?.toolName === toolName,
});
EOF

pnpm exec tsx repro-wire-name.mts
rm repro-wire-name.mts

Observed output:

{
  serverId: '0__A',
  toolName: 'a',
  wireName: 'mcp__0__A__a',
  parsed: { serverId: '0', toolName: 'A__a' },
  expected: { serverId: '0__A', toolName: 'a' },
  roundTrips: false
}

Expected behavior

A wire name created by buildMcpToolWireName(serverId, toolName) should parse back to the same normalized server/tool identity, or the builder should reject or escape delimiter sequences that cannot be parsed unambiguously.

Actual behavior

Server IDs containing __ are accepted by the builder but parsed as a different server ID and tool name.

Impact

An MCP server ID that naturally normalizes to a string containing double underscores can route calls to the wrong server/tool identity after parsing. This is especially easy to miss because both the built wire name and parsed result are syntactically valid.

Existing coverage

I could not find an existing issue or pull request covering this ambiguous MCP wire-name parsing case.

Suggested fix

Make the format unambiguous. Options include escaping segment delimiters, rejecting/collapsing __ inside normalized segments, or using an encoded representation for the two segments. Add a regression test that builds and parses a server ID containing __.

Suggested tests

  • serverId = "0__A" and toolName = "a" round-trips correctly or is rejected by the builder.
  • Sanitized server IDs that contain underscores do not get split into the wrong server/tool pair.
  • Parser rejects malformed ambiguous wire names if delimiter escaping/rejection is chosen.

Submitted with Codex.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with src/mcp/runtime/wireName.ts, especially buildMcpToolWireName() and parseMcpToolWireName(). Run the provided pnpm exec tsx reproduction to confirm the incorrect split, then inspect nearby coverage or test conventions. Done means double-underscore server IDs round-trip correctly or are rejected, with a regression test covering the chosen behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
backend-api-design
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.