fix(agents-core): handle same-server MCP tool name collisions - #1935

Reviewed the complete three-file change at 3281882 against d187747, including #1934, the existing allocation/dispatch paths, and the v0.18.0 compatibility baseline.

Need status: demonstrated. This is a supported tool-identity failure with a caller-visible consequence, and the patch is merge-worthy as-is. I found no blocking correctness, compatibility, or scope issues.

The root cause is twofold: the default check converts each server's names to a Set before checking only previously processed servers, hiding duplicates within a server; the prefixed allocator compares names before the final toFunctionToolName normalization, so search-a and search_a appear distinct until both become mcp_docs__search_a. The runner then retains only one function under its default collision policy.

I independently reproduced both levels of the problem using source snapshots of the exact base and head, synthetic MCP discovery/call stubs, and the SDK's ScriptedModel:

• Running the PR's mcpCache tests against the base produces exactly the two reported failures: 67 pass and 2 fail. Both failures disappear on the PR head.
• Through the public run API, the base exposes only one prefixed tool and invokes only the original search_a tool. The head exposes two unique tools and invokes both original names, search-a and search_a. This holds for streaming and non-streaming runs.
• Without prefixing, the head raises UserError before any model request or MCP invocation, rather than silently allowing the runner to drop a tool.
• Additional controls confirm that a normalized local function name is reserved correctly, and filtering out one colliding tool avoids an unnecessary error.

The implementation is placed at the right boundary. findDuplicateToolNames checks both intra-batch and prior-server duplicates without mutating the caller's set. Applying the existing normalization to the allocator's counts, reservation checks, and used-name checks closes the same identity gap throughout allocation. Keeping raw tool names in the hash seed and dispatch closure preserves deterministic disambiguation and correct remote invocation. Changing global function-name normalization would have a much broader compatibility impact; reusing this existing allocator is the narrower fix. Configuring prefixes alone does not solve the problem on the base.

I also inspected the affected identity/security boundary: server-name redaction still occurs before prefix/hash allocation, and this patch does not change MCP approval, guardrail, credential, or execution configuration. Existing focused coverage for redaction, guardrail isolation, cache rebinding/filtering, reserved handoff names, and long-name allocation passes.

Validation: 139 tests passed across mcpCache, mcpToFunctionTool, mcpToolFilter, runner/modelPreparation, and six independent reproduction/control cases. The six controls also pass against the base with expectations for its observed broken behavior. ESLint passed for both changed TypeScript files; Prettier passed for all three changed files; git diff --check passed.

Limits: these were deterministic local tests, not live model/MCP service calls. I did not rerun the full monorepo verification stack. GitHub CI for this head currently reports action_required, so this code approval does not establish CI readiness.