microsoft / microsoft/vscode

Claude agent: MCP tools discoverable via toolSearch but invocation fails with "No such tool available"

Open
#331,725 1 comment 0 reactions 2 assignees Claimed by @TylerLeonhardt View on GitHub
Dominant language
TypeScript
Stars
193k
Forks
42.4k
PR merge metrics
PR metrics pending

Description

Description:

In the Claude agent within Copilot Chat, MCP tools registered in `mcp.json` are correctly discovered via `toolSearch`, tool names and descriptions surface normally, but invoking any of those tools fails with `No such tool available`, under every naming variant tried. The same MCP server and the same `mcp.json` work correctly end to end (discovery and invocation) in the default Copilot agent in the same VS Code window at the same time, so the MCP server itself is healthy and this is isolated to the Claude agent's invocation path.

Steps to Reproduce:

1. Configure an HTTP-type MCP server in `mcp.json` (used Atlassian Rovo MCP at `/v1/mcp/authv2`):
```json
{
"servers": {
"atlassian-mcp": {
"url": "https://mcp.atlassian.com/v1/mcp/authv2",
"type": "http"
}
}
}
```
2. Confirm the server starts and authenticates successfully (console shows `Discovered 40 tools`, no auth errors).
3. In the default Copilot agent (non-Claude), confirm the MCP server's tools are invocable, e.g. fetch a Confluence page. This works.
4. Switch to the Claude agent in the same window, same session.
5. Ask Claude to use the same MCP tool (e.g. fetch the same Confluence page).
6. Observe: `toolSearch` surfaces the tool by name (`getConfluencePage` etc.), but invoking it returns `No such tool available`, tried under every naming variant (`mcp__atlassian-mcp__getConfluencePage`, `mcp_atlassian-mcp_getConfluencePage`).

Expected behavior: MCP tools discovered via `toolSearch` in a Claude agent session should be invocable in that same session, matching the working behavior of the default Copilot agent with identical MCP configuration.

Ruled out before filing:
- Endpoint deprecation (`/v1/sse` retirement): confirmed on current `authv2` endpoint.
- Duplicate/conflicting server entries in `mcp.json`: cleaned up, issue persists with a single correctly named entry.
- Stale OAuth/session state: reset trust, reset cached tools, full re-auth, still fails.
- `chat.agentHost.enabled`: disabled entirely, issue persists identically, not agent-host-specific.
- Server-side health: confirmed working via console log and via successful invocation in the default Copilot agent.

Suspected root cause:
The installed extension's `package.json` currently depends on `@anthropic-ai/sdk` (`^0.82.0`), not `@anthropic-ai/claude-agent-sdk` (actively maintained upstream, currently 0.3.234). The Agent SDK provides built-in tool discovery and execution orchestration, including MCP tool binding. The base SDK does not.

This suggests a dependency swap between extension versions. If Copilot Chat moved off the Agent SDK's orchestration layer and reimplemented tool search/execution itself, that would explain the gap: the custom tool-search index finds MCP tools, but the custom invocation path doesn't bind to them.

Version boundary not yet isolated. Can bisect via "Install Another Version" against:
```
grep -o '"@anthropic-ai/[^"]*"[^,}]*' "/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/copilot/package.json"
```

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.