[BUG] "MCP Tools Not Available in Conversation Interface Despite Successful Connection"

Version 0.12.28 is also affected
Windows 11 with Python MCP servers
Same symptoms: server runs, shows as "running", but tools don't appear

I'm experiencing this as well. A test MCP server I made fails to register tools with both Claude Clode and Claude Desktop, but the Anthropic example Fetch MCP server connects and exposes tools fine. This tells me that it's possible to expose the tools, but I cannot find any fundamental difference in the implementation.

The capabilities are defined, and the list-tools response is working on a local MCP client. Logs show that Claude never sends a list-tools request at all.

edit: And in typical bug report fashion, I've resolved my particular issue. Claude was calling list-tools appropriately and my tool input schema was improperly defined. The example structure from the docs works for me:

inputSchema: {
  type: 'object',
  properties: {
    example: {
      type: 'string',
      description: 'Ask me a question',
    },
  },
  required: ['example'],
}

I finally resolved the issue which was maily with the oAuth protocol.

Confirming This Issue on Claude Code v2.0.15 (macOS)

I'm experiencing the exact same symptoms described in this issue and can confirm it affects the latest Claude Code version.

Environment

• Claude Code: v2.0.15
• Platform: macOS (Darwin 25.0.0)
• MCP Servers: Basic Memory v1.16.0, Pieces v0.2.0
• Date: October 20, 2025

Symptoms Match Exactly

✅ Working:

• MCP servers initialize successfully
• Tools returned via tools/list (Basic Memory: 17 tools, Pieces: 2 tools)
• Logs show proper JSON-RPC responses
• No errors in logs

❌ Not Working:

• Tools NOT exposed to LLM conversation
• Only Context7 MCP tools visible (proves MCP support exists)
• No mcp__basic-memory__* or mcp__pieces__* tools available
• Cannot invoke any of the returned tools

Critical Evidence: Claude Desktop Works

Same exact configuration works perfectly in Claude Desktop:

{
  "mcpServers": {
    "basic-memory": {
      "command": "/Users/[username]/.local/bin/uvx",
      "args": ["basic-memory", "mcp", "--project", "[project-name]"]
    },
    "pieces": {
      "command": "/opt/homebrew/bin/pieces",
      "args": ["--ignore-onboarding", "mcp", "start"]
    }
  }
}

Timeline:

• 14:09:43 - Both servers initialize in Claude Code (tools returned)
• 14:13:59 - Claude Desktop successfully uses ask_pieces_ltm tool
• 14:14:14-34 - Claude Desktop successfully uses Basic Memory tools

This proves the configuration is valid and the servers are functional.

Troubleshooting Attempted

All standard troubleshooting completed with no effect:

• ✅ Multiple system restarts
• ✅ Verified absolute paths
• ✅ Confirmed servers running
• ✅ Reviewed logs (no errors)
• ✅ Tested prerequisites (Pieces LTM enabled, etc.)
• ✅ Compared Desktop vs Code behavior

Impact

This blocks all MCP functionality in Claude Code for affected servers:

• Cannot use Basic Memory's 17 knowledge management tools
• Cannot use Pieces' 2 long-term memory tools
• Forces users to switch to Claude Desktop for MCP-based workflows

Comparison Table

| Aspect | Claude Desktop | Claude Code |
|--------|----------------|-------------|
| MCP servers start | ✅ Yes | ✅ Yes |
| Servers initialize | ✅ Yes | ✅ Yes |
| Tools returned | ✅ Yes (19 total) | ✅ Yes (19 total) |
| Tools exposed to LLM | ✅ Yes | ❌ NO |
| Tool calls work | ✅ Yes | ❌ Can't test |

Additional Context

Interesting observation: Context7 MCP tools work fine in Claude Code, which suggests:

1. MCP support exists and functions
2. The issue is selective tool exposure/registration
3. Some mechanism is filtering or preventing certain MCP tools from being exposed

Hypothesis: Claude Code's tool registration/exposure mechanism differs from Claude Desktop's implementation, possibly:

• Async registration timing out
• Overly restrictive tool filtering
• Schema pattern recognition issues
• Maximum tool count limitations

---

This confirms the issue persists in the latest Claude Code version (v2.0.15) and affects multiple established MCP server implementations.

Confirming This Issue Persists in Claude Code v2.0.26 (macOS)

I'm experiencing the exact same symptoms described in this issue and can confirm the bug still persists in the latest version despite 11 releases since my initial testing.

Environment

• Claude Code: v2.0.26 (tested October 24, 2025)
• Previous Test: v2.0.15 (tested October 20, 2025)
• Platform: macOS (Darwin 25.0.0)
• MCP Servers: Basic Memory v1.16.0, Pieces v0.2.0
• Versions Between Tests: 11 releases (v2.0.15 → v2.0.26)
• Time Elapsed: 4 days with no fix

Critical Finding: Bug NOT Fixed in 11 Versions

v2.0.15 vs v2.0.26 Comparison:

| Aspect | v2.0.15 (Oct 20) | v2.0.26 (Oct 24) | Status |
|--------|------------------|------------------|--------|
| MCP servers initialize | ✅ Yes | ✅ Yes | Same |
| Tools returned by servers | ✅ Yes (19 total) | ✅ Yes (19 total) | Same |
| Tools exposed to LLM | ❌ NO | ❌ NO | BUG PERSISTS |
| Context7 MCP works | ✅ Yes | ✅ Yes | Same |

Symptoms Match Exactly

✅ Working:

• MCP servers initialize successfully
• Tools returned via tools/list (Basic Memory: 17 tools, Pieces: 2 tools)
• Logs show proper JSON-RPC responses
• No errors in logs
• Context7 MCP tools work perfectly

❌ Not Working:

• Tools NOT exposed to LLM conversation
• No mcp__basic-memory__* or mcp__pieces__* tools available
• Cannot invoke any of the returned tools
• Issue affects ALL tested servers except Context7

Critical Evidence: Claude Desktop Works

Same exact configuration works perfectly in Claude Desktop:

{
  "mcpServers": {
    "basic-memory": {
      "command": "/Users/[username]/.local/bin/uvx",
      "args": ["basic-memory", "mcp", "--project", "[project-name]"]
    },
    "pieces": {
      "command": "/opt/homebrew/bin/pieces",
      "args": ["--ignore-onboarding", "mcp", "start"]
    }
  }
}

Timeline Evidence:

• Servers initialize in Claude Code (tools returned)
• Claude Desktop successfully uses the same tools immediately after
• This proves the configuration is valid and the servers are functional

Troubleshooting Attempted

All standard troubleshooting completed with no effect:

• ✅ Multiple system restarts
• ✅ Verified absolute paths
• ✅ Confirmed servers running
• ✅ Reviewed logs (no errors)
• ✅ Tested prerequisites (Pieces LTM enabled, etc.)
• ✅ Compared Desktop vs Code behavior

Impact

This blocks all MCP functionality in Claude Code for affected servers:

• Cannot use Basic Memory's 17 knowledge management tools
• Cannot use Pieces' 2 long-term memory tools
• Forces users to switch to Claude Desktop for MCP-based workflows
• Blocks adoption of third-party MCP ecosystem in Claude Code

Comparison Table

| Aspect | Claude Desktop | Claude Code |
|--------|----------------|-------------|
| MCP servers start | ✅ Yes | ✅ Yes |
| Servers initialize | ✅ Yes | ✅ Yes |
| Tools returned | ✅ Yes (19 total) | ✅ Yes (19 total) |
| Tools exposed to LLM | ✅ Yes | ❌ NO |
| Tool calls work | ✅ Yes | ❌ Can't test |

Root Cause Hypothesis

Interesting observation: Context7 MCP tools work fine in Claude Code, which suggests:

1. MCP support exists and functions correctly
2. The issue is selective tool exposure/registration
3. Some mechanism is filtering or preventing certain MCP tools from being exposed
4. Not a general MCP failure or configuration issue

Hypothesis: Claude Code's tool registration/exposure mechanism differs from Claude Desktop's implementation, possibly:

• Async registration timing out
• Overly restrictive tool filtering
• Schema pattern recognition issues
• Server name whitelist/blacklist
• Maximum tool count limitations

Severity Assessment

This confirms the issue:

• ✅ Persists in the latest Claude Code version (v2.0.26)
• ✅ Affects multiple established MCP server implementations
• ✅ Has NOT been fixed in 11 version releases over 4 days
• ✅ Blocks MCP ecosystem adoption in coding workflows

Workaround: Use Claude Desktop for MCP-based workflows (not ideal for coding sessions)

---

This bug significantly impacts the Claude Code user experience and prevents adoption of the broader MCP ecosystem. A fix would be greatly appreciated.

I believe this bit of string and sealing wax on Pandora's box may there by design; to <a href=https://syzygysys.github.io/docs/architects_notebook/log_13.html>partition agency from sovereignty</a>.

Wanted to share that I spent hours trying to fix a similar issue with my own local MCP server... connection was good but Claude Code CLI wasn't able to "see" any tools.

Once I realized there was a debug mode ("claude --debug"), I got my breakthrough. There was an input schema issue in my code, and I could have only discovered that in claude code's debug logs. I fed the logs to another instance of Claude Code, and it sorted it out within minutes.

Fixed - for me the issue was that claude_desktop_config.json was missing the Docker MCP gateway configuration.

Solution:
Add the MCP_DOCKER server entry to your config file at ~/Library/Application Support/Claude/claude_desktop_config.json:

```
{
"mcpServers": {
"MCP_DOCKER": {
"command": "docker",
"args": [
"mcp",
"gateway",
"run"
]
},
// ... rest of your MCP servers
}
}

  After adding this configuration and restarting Claude  Code, the Docker MCP tools became available immediately.

Debug Investigation: MCP Tool Visibility Bug

Investigation Date: November 18, 2025
Claude Code Version: v2.0.44
Platform: macOS (Darwin 25.1.0)

---

Executive Summary

I've completed a comprehensive debug log analysis using Claude Code's MCP server logs. The findings reveal that this issue is fundamentally different from the community solutions posted on November 3-5, 2025.

Critical Discovery: The bug is NOT a schema or configuration issue. It's a stdio pipe communication breakdown that occurs AFTER tools are successfully listed and returned.

---

Key Findings

1. Tools ARE Successfully Registered ✅

Debug logs confirm both Basic Memory and Pieces servers successfully return complete tool lists via JSON-RPC:

Basic Memory returns all 17 tools:

{
  "jsonrpc":"2.0",
  "id":1,
  "result":{
    "tools":[
      {"name":"delete_note","description":"..."},
      {"name":"read_content","description":"..."},
      {"name":"build_context","description":"..."},
      {"name":"recent_activity","description":"..."},
      {"name":"search_notes","description":"..."},
      {"name":"read_note","description":"..."},
      {"name":"view_note","description":"..."},
      {"name":"write_note","description":"..."},
      {"name":"canvas","description":"..."},
      {"name":"list_directory","description":"..."},
      {"name":"edit_note","description":"..."},
      {"name":"move_note","description":"..."},
      {"name":"list_memory_projects","description":"..."},
      {"name":"create_memory_project","description":"..."},
      {"name":"delete_project","description":"..."},
      {"name":"search","description":"..."},
      {"name":"fetch","description":"..."}
    ]
  }
}

Pieces returns both tools:

{
  "jsonrpc":"2.0",
  "id":1,
  "result":{
    "tools":[
      {"name":"ask_pieces_ltm","description":"..."},
      {"name":"create_pieces_memory","description":"..."}
    ]
  }
}

Conclusion: Tool schemas are valid and complete. Claude Code IS receiving the tool lists successfully.

---

2. Critical Error: BrokenPipeError ❌

Both servers experience the same error pattern AFTER successfully returning tools:

Basic Memory Log:

ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception)

╭────────────────────────────── Sub-exception #1 ──────────────────────────────╮
│ /site-packages/mcp/server/stdio.py:81 in stdout_writer                       │
│   78 │   │   │   │   async for session_message in write_stream_reader:       │
│   79 │   │   │   │   │   json = session_message.message.model_dump_json(     │
│   80 │   │   │   │   │   await stdout.write(json + "\n")                     │
│ ❱ 81 │   │   │   │   │   await stdout.flush()                                │
╰───────────────────────────────────────────────────────────────────────────────╯

BrokenPipeError: [Errno 32] Broken pipe
Exception ignored in: <_io.TextIOWrapper name='<stdout>' encoding='utf-8'>
BrokenPipeError: [Errno 32] Broken pipe

Pieces Log:

Error in sse_reader
    raise BrokenResourceError from None
anyio.BrokenResourceError

Exception ignored while flushing sys.stdout:
BrokenPipeError: [Errno 32] Broken pipe

Critical: The pipe breaks during stdout.flush() AFTER the tools have been successfully sent, preventing the LLM from accessing them.

---

3. Successful MCP Initialization Sequence ✅

Both servers follow proper MCP protocol:

1. ✅ Client sends initialize request
2. ✅ Server responds with capabilities:

``json
{
"protocolVersion":"2025-06-18",
"capabilities":{
"tools":{"listChanged":true}
},
"serverInfo":{
"name":"Basic Memory",
"version":"2.13.0.2"
}
}
``

1. ✅ Client sends notifications/initialized
2. ✅ Client requests tools/list
3. ✅ Server returns complete tool list
4. ❌ Communication breaks during stdout flush

---

4. Log File Analysis

MCP server logs in ~/Library/Logs/Claude/:

| Server | Log Lines | Status | Notes |
|--------|-----------|--------|-------|
| Basic Memory | 12,155 | ❌ BrokenPipeError | Multiple pipe breaks |
| Pieces | 1,242 | ❌ BrokenResourceError | Multiple pipe breaks |
| Context7 | 0 | ✅ Working | Empty log file |
| Filesystem | 528 | ✅ Working | Normal operation |

Key Observation: Context7 has a completely empty log file (0 bytes) despite working perfectly. This suggests it may use a different transport mechanism or is handled specially by Claude Code.

---

Comparison: This Issue vs Community Solutions

| Aspect | Community Solutions | This Investigation |
|--------|---------------------|-------------------|
| Problem | Schema/Config issues | stdio pipe breakdown |
| Tools Listed | No (validation failed) | ✅ Yes (successfully) |
| Schemas Valid | No (fixed with docs) | ✅ Yes (complete) |
| Config Correct | No (missing entries) | ✅ Yes (works in Desktop) |
| Error Type | Validation/missing config | BrokenPipeError |
| Solution | Fix schema/add config | ❌ Requires engineering fix |

Community Member Quirds (Nov 3):

• Issue: Input schema validation error
• Solution: Fixed schema using claude --debug
• Outcome: ✅ Resolved

Community Member Richard-Warren4 (Nov 5):

• Issue: Missing Docker MCP gateway config
• Solution: Added MCP_DOCKER entry
• Outcome: ✅ Resolved

This Investigation:

• Issue: stdio pipe communication breakdown
• Evidence: Tools successfully listed, then BrokenPipeError
• Configuration: ✅ Verified correct (works in Claude Desktop)
• Outcome: ❌ NOT fixable by user - requires Claude Code engineering fix

---

Root Cause Analysis

Primary Hypothesis: stdio Pipe Communication Breakdown

Evidence:

1. ✅ Servers initialize correctly using MCP 2025-06-18 protocol
2. ✅ Tools are listed and returned successfully
3. ✅ Schemas are valid (successfully parsed and returned)
4. ❌ BrokenPipeError occurs during stdout.flush() operation
5. ❌ Pipe breaks AFTER tools are sent but BEFORE LLM receives them

Likely Causes:

• Timing Issue: Claude Code may be closing stdin/stdout prematurely
• Buffer Issue: Large tool schemas may exceed pipe buffer limits (17 tools for Basic Memory)
• Async Issue: Background processes (e.g., Basic Memory's sync operations) interfere with pipe
• Protocol Implementation: Claude Code stdio handling differs from Claude Desktop

Why Claude Desktop Works:

• Same configuration, same servers, same MCP protocol
• Different stdio handling implementation
• Possibly longer timeouts or larger buffers
• Better async coordination with background processes

---

Bug Persistence Timeline

| Date | Version | Status | Notes |
|------|---------|--------|-------|
| Oct 20, 2025 | v2.0.15 | ❌ Broken | Initial testing |
| Oct 24, 2025 | v2.0.26 | ❌ Broken | Retested (11 versions later) |
| Nov 18, 2025 | v2.0.44 | ❌ Broken | Debug investigation |

Total Versions Affected: 29+ versions (v2.0.15 → v2.0.44)
Duration: 143 days since issue creation (June 28, 2025)

---

Impact Assessment

Severity: HIGH

Affected Systems:

• ✅ Basic Memory (17 tools) - 100% unusable in Claude Code
• ✅ Pieces (2 tools) - 100% unusable in Claude Code
• ❌ Context7 - Works (possibly different implementation)
• ❌ Filesystem - Works

User Impact:

• Blocks third-party MCP ecosystem adoption
• Forces switching between Claude Code and Claude Desktop
• Prevents knowledge management workflow integration
• Cannot test MCP integrations in coding environment

NOT Affected:

• Built-in Claude Code tools
• Same servers work perfectly in Claude Desktop (same config)

---

Recommended Engineering Investigation

For the Anthropic team to investigate:

1. Compare stdio implementations: Claude Code vs Claude Desktop

• How are stdin/stdout pipes managed?
• Are there timeout/buffer differences?
• How are background async tasks coordinated?

1. Investigate Context7 implementation:

• Why does it have a 0-byte log file?
• Is it using a different transport mechanism?
• Is it built-in vs external MCP server?

1. Test stdio pipe limits:

• Does payload size matter? (Basic Memory = 17 tools, Pieces = 2 tools)
• Are there buffer size constraints?
• How does async activity affect pipe stability?

1. Review error handling:

• Why does BrokenPipeError occur after successful tool listing?
• Can Claude Code add better error messages for pipe failures?
• Should there be retry logic or better async coordination?

---

Technical Details

Error Stack Trace:

File: /site-packages/mcp/server/stdio.py:81
Function: stdout_writer
Line: await stdout.flush()

Error: BrokenPipeError: [Errno 32] Broken pipe

Context:
  78 │   async for session_message in write_stream_reader:
  79 │   │   json = session_message.message.model_dump_json()
  80 │   │   await stdout.write(json + "\n")
  81 │   │   await stdout.flush()  # ← BREAKS HERE
  82 │   except anyio.ClosedResourceError:
  83 │   │   await anyio.lowlevel.checkpoint()

MCP Protocol Versions:

• Client (Claude Code): 2025-06-18
• Basic Memory: 2025-06-18 ✅ Match
• Pieces: 2025-06-18 ✅ Match

Protocol version mismatch is NOT the issue.

---

Workarounds (For Other Users)

Option 1: Use Claude Desktop ✅ Recommended

• Same configuration works perfectly
• Full MCP functionality available
• Proven to work with Basic Memory and Pieces

Option 2: Use CLI Tools ✅ Partial Solution

Basic Memory:

uvx basic-memory tool search-notes "query" --project [project-name]
uvx basic-memory tool recent-activity --timeframe "7d"

Pieces:

pieces ask "query" --ltm
pieces search "keyword"

---

Conclusion

This debug investigation confirms that the MCP tool visibility bug is NOT a user-fixable configuration or schema issue. It is a Claude Code stdio pipe communication bug that requires engineering investigation.

Evidence:

• ✅ Configuration verified correct (works in Claude Desktop)
• ✅ Schemas verified valid (tools successfully listed)
• ✅ Protocol verified matching (2025-06-18)
• ❌ BrokenPipeError during stdio communication
• ❌ Persists across 29+ versions over 143 days

Requires: Anthropic engineering team investigation into Claude Code's stdio transport implementation for MCP servers.

---

Investigation Complete
Claude Code Version Tested: v2.0.44
Platform: macOS (Darwin 25.1.0)
Date: November 18, 2025

Investigation Date: November 18, 2025
Preflight Tools Version: v0.1.0
Reference: “Debugging the Bridge: Six MCP Fixes for Claude Desktop” (SHA-256: 3b0423991e3ee85a9e2ab84402a0fff2955b81bf9cf3063290a60300ca6ac83a)

---

Summary

• We hit the same silent MCP failure mode (Claude Code receives tools/list, then throws BrokenPipeError during stdout.flush()). Knowing we'd bump into this again, we codified the six fixes we needed—tool naming, schema objects, content wrappers, notification handling, stdout hygiene, and JSON-RPC id/jsonrpc preservation—into an open-source validator.
• Running mcp-preflight-check validate … produces a rich table with line numbers and remediation hints. The stdout detector now uses AST analysis to catch the print()/sys.stdout.write pollution described in this thread, and the JSON-RPC check flags model_dump_json(exclude_none=True) or .pop("id") calls that drop required headers.
• A2A support and the MCP/A2A cli entry points, are still placeholders—we don’t exercise that protocol in ACE yet—but the scaffolding is there if folks want to expand coverage.

How to Use

git clone https://github.com/Syzygysys/preflight-tools.git
cd preflight-tools
poetry install          # or pip install -e .

Example validation run

poetry run mcp-preflight-check validate --strict --verbose path/to/your/tools.py

or, if you already have a venv:

./.venv/bin/mcp-preflight-check validate src/your_mcp_project
If your MCP server passes these six checks but Claude Code still drops the connection, attach the report when escalating—it documents exactly what we’ve been using to keep Claude Desktop healthy while Anthropic investigates stdio handling.

Hope this helps others avoid the same rabbit holes. — Team Syzygysys.io

Confirming on VS Code Extension v2.0.55 (Windows 11)

Adding another data point to this issue.

Environment

• Claude Code VS Code Extension: v2.0.55 (latest as of Dec 1, 2025)
• Platform: Windows 11
• MCP Server: mcp-server-tree-sitter (Python-based, 26 tools)

Verification Performed

1. MCP Inspector confirms server works perfectly:

• All 26 tools visible and callable
• Server responds correctly to all requests
• No errors in communication

1. Direct Python testing works:

``bash
python -m mcp_server_tree_sitter.server
# Server starts and responds correctly
``

1. Configuration verified correct:

• .mcp.json properly configured with full Python path
• .claude/settings.json has enabledMcpjsonServers: ["tree_sitter", "MCP_DOCKER"]
• MCP_DOCKER tools work fine in the same session

Symptoms Match Exactly

• ✅ Server connects successfully
• ✅ tools/list returns all 26 tools
• ❌ Tools never exposed to AI assistant in conversation
• ❌ No tools/call requests ever made

Observation

Interestingly, MCP_DOCKER tools work perfectly in the same VS Code session where tree-sitter tools don't appear. Both are configured in the same .mcp.json file. This suggests the issue may be specific to certain server types or connection patterns rather than a universal MCP failure.

This aligns with @Lalita061985's November 18 investigation pointing to stdio pipe communication issues.

I encourage you to check out the MCP server preflight tool posted by syzygysys. Claude is very prone to silent failure on malformed data.

https://github.com/SyzygySys/preflight-tools

https://syzygysys.github.io/docs/architects_notebook/log_14.html

• Kevin

This was the fix for my issue, maybe it will help someone else.

chat request: check the code for issues using the Claude Code MCP documentation."

chat response: The Root Cause: The protocol-enforcer wasn't wrapping responses in the proper JSON-RPC 2.0 format required by the MCP specification.
What I fixed:

1. initialize response - Now returns proper JSON-RPC format:

{
  "jsonrpc": "2.0",
  "id": <request-id>,
  "result": { ... }
}

1. tools/list response - Now wraps tools array correctly:

``
{
"jsonrpc": "2.0",
"id": <request-id>,
"result": { "tools": [...] }
}
``

1. tools/call response - Now wraps tool results in JSON-RPC format
2. Error handling - Proper JSON-RPC error responses with error codes

Next steps:

1. I killed all old protocol-enforcer processes
2. Reload Cursor (Cmd+Shift+P → "Developer: Reload Window")
3. Test the tools

Success! The ******** MCP server is now working!

Experiencing the same issue on Windows 11 with VS Code extension and Google Drive and Docs MCPs

Environment:

• Platform: Windows 11
• Claude Code Version: 2.0.61
• Interface: VS Code extension (not terminal)
• MCP Server: Google Drive/Google Docs MCP (https://github.com/a-bonus/google-docs-mcp)

Symptoms:

• claude mcp list shows server as "✓ Connected"
• Terminal Claude Code can successfully use the MCP tools (list my Google Drive files works perfectly)
• VS Code extension shows the same "connected" status but Claude responds "I don't have access to your Google Drive"
• No tools/call requests ever reach the MCP server from the VS Code extension

Impact:

This blocks my users' workflow. They need to:

1. Access medical documentation stored in Google Docs (requires MCP)
2. Work on code in VS Code with Claude's assistance

Currently impossible to do both simultaneously. Terminal works but has no VS Code integration. VS Code extension has integration but broken MCP support.

Request:

This bug has been open since June 2025 (5+ months). Please prioritize fixing MCP tool availability in the VS Code extension. The terminal version proves the MCP infrastructure works - this is specifically a VS Code extension issue.

---
Session: Mouse (c877)

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

This issue should not be closed. MCP tools are available only in the terminal version and not VSCode extension.

Additional data point: We identified a specific trigger for this issue while debugging a tower-mcp server.

When an MCP server advertises the completions capability (valid per MCP 2025-11-25 spec), Claude Code fails to expose tools to the assistant - even though the initialize response correctly includes "tools": {"listChanged": false}.

Observations:

• Server with capabilities: {tasks, tools} -> tools exposed correctly
• Server with capabilities: {completions, prompts, resources, tasks, tools} -> tools NOT exposed
• Claude Code UI shows "Capabilities: resources / prompts" but omits "tools"
• The tools/list response is valid and returns all tools with correct schemas

The server responses are structurally identical; only the presence of additional capabilities (specifically completions) triggers the bug.

Workaround: Don't register a completion handler on the server, or strip the completions capability.

Related: Opening a separate issue with minimal repro steps.

Same issue

GitHub_Connector_Bug_Report.docx

Restarting with clearing the cache
rm -rf '~/Library/Application Support/Claude/Cache/'
solved the problem for me

Still happening, v2.1.76 / Claude Desktop on Windows 11.

The specific failure mode: conversation in Claude Desktop says "I don't have direct access to your local Windows filesystem (C:\Users\...) from this chat interface" even though the filesystem MCP server is configured in claude_desktop_config.json. Then it asks the user to upload the file or paste the contents.

The user has to explicitly say "You do too. Read via file system" before Claude will attempt to use the MCP tool it already has. That shouldn't require prompting — if the MCP filesystem server is configured and connected, Claude should know to use it without being told.

This is the exact scenario: agent was asked to read a local plan file at a specific path. Response was to explain it couldn't access local files and offer workarounds (upload, paste). User had to explicitly correct it. The tool was available the entire time.

The issue isn't just the handshake — it's that even after the server is running and connected, Claude's default behavior in conversation is to disclaim filesystem access rather than proactively try the tool.

I found that I needed to restart Claude Code _after_ the MCP server started up for it to be recognized in tools, despite it showing as "connected" in /mcp. Particular MCP servers initiated while a Claude agent is already running do not always become recognized until a restart of the Claude instance.

well, looks like coding is still not solved after all, this issue is almost a year now, and the famous, autonomously programming claude agent still haven't fixed it.

Hi everyone — I know this thread has been going for a while and the frustration is real. We ran into the exact same "tools connect but never appear" problem when integrating our own MCP servers, and after a long debugging session we identified six specific root causes that account for the vast majority of these failures.

We wrote up the full debugging story here:
Debugging the Bridge — Architect's Notebook Log 14

The TL;DR — these are the six things that silently break tool discovery:

Tool names with dots (my.tool.name) — must match ^[a-zA-Z0-9_-]{1,64}$
Empty properties as [] instead of {} — JSON Schema requires an object
Missing content wrapper — responses must be {"content": [{"type": "text", "text": "..."}]}
Notification handling — requests without id are notifications; return empty string, not an error
Stdout pollution — any print() or debug output to stdout corrupts the JSON-RPC stream on stdio transport
Missing id/jsonrpc in responses — Pydantic's exclude_none=True can strip required fields
To make it easier to catch these before you spend hours debugging, we open-sourced a validator:

preflight-tools — pip install preflight-tools

Validate your MCP tool definitions

mcp-preflight-check validate path/to/tools.py

Test a running server

mcp-preflight-check test http://localhost:8000
It checks all six issues and gives you specific fix suggestions with line numbers. One command, no configuration needed.

Working example from our live internal stack
Once the six fixes are in place, this is what a healthy MCP connection looks like. We run 6 internal services behind an MCP gateway — here's an agent connecting, authenticating via OAuth2, and querying the tool catalog:

1. Acquire OAuth2 token (client_credentials grant)

TOKEN=$(curl -s -X POST "http://localhost:9010/application/o/token/" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials&client_id=service-ace-comms-external&client_secret=${PORTER_CLIENT_SECRET}" \
| jq -r '.access_token')
echo "Token: ${#TOKEN} chars"

2. Verify agent is registered and recognized

curl -sL http://localhost:8400/api/v1/discover/ \
| jq '.data.services[] | select(.service_id == "chuck") | {is_known, status}'

3. List MCP tools via JSON-RPC

curl -s -X POST http://localhost:8350/mcp/rpc \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"tools/list","params":{},"id":1}' \
| jq '.result.tools[:10][] | "\(.name) — \(.description[:80])"'
Results:

Token: 1230 chars
{ "is_known": true, "status": "healthy" }

Top 10 capabilities across registered services:
3x mcp-server
2x code-analysis
2x diagnosis
2x mcp-client
2x reasoning
1x ace-ledger
1x ace-porter
1x agent-lifecycle-manager
1x agent-runtime

Top 10 of 84 MCP tools:
lap_health_ping — Ping LAP::CORE for liveness
lap_core_status — Summarize platform status
prom_query_instant — Run a PromQL instant query
prom_query_range — Run a PromQL range query
caddy_admin_reload — Reload Caddy (HITL)
ace_registry_list_services — List services registered in ACE::REGISTRY
ace_registry_service_tools — Get MCP tools exposed by a specific service
field_agent_query — Consult with chuck (Claude) for complex reasoning
direct_response — Provide a direct response using the LLM's knowledge
create_code_example — Generate example code in a supported language
All 84 tools discovered, all callable. The key was fixing the six issues above — once those are right, tool discovery just works.

Hope this helps someone save a few hours. Happy to answer questions.

— on behalf of Chuck and Team SyzygySys

this is a live mcp query to our internal ACE Registry server:

<img width="1556" height="849" alt="Image" src="https://github.com/user-attachments/assets/24c4adc3-5680-4456-90ac-b868fa6d308c" />

This Bug Is Costing Real Users Real Time — Every Single Session

Concrete example from today (April 1, 2026, v2.1.89):

User: 'check the assets of the 1 min pipeline'
Claude Desktop: 'I don't have access to your filesystem to check directly. Here's what to ask the agent...'
User: 'the fuck you don't. read via file system MCP'
Claude Desktop: 'My bad. Let me look directly.'

This happened THREE TIMES in the same session today. The filesystem MCP server is connected. The tools are registered. They WORK when the user explicitly says 'use MCP.' The model just doesn't know the tools exist until reminded.

This is happening on every single session start. The user has to re-educate the model about its own capabilities every time they open Claude Desktop. It's been open since MCP launched. There are zero responses from Anthropic engineers on this issue or #23808.

The fix should be trivial: The model's system prompt or tool discovery needs to surface MCP filesystem tools so the model knows it can read local files. This is not a complex architectural problem — it's a system prompt gap.

Impact: Users paying USD 200/month for Max plan are getting a tool that disclaims its own capabilities and requires manual correction on every interaction involving local files. For a product built around filesystem interaction, this is a fundamental failure.

This issue has been open for months with community reports confirming it persists across every version. Can someone from Anthropic please acknowledge this?

The link to the blog Debugging the Bridge — Architect's Notebook Log 14 is 404, and pip install preflight-tools returns

ERROR: Could not find a version that satisfies the requirement preflight-tools (from versions: none)

Fixed both:

(python-3.13.11) @.***:~/projects/preflight-tools
(main *%=)$ preflight version
preflight-tools 0.1.1

https://syzygysys.github.io/docs/architects_notebook/log_14.html

note:

Claude Desktop and mobile still only support remote (HTTPS) MCP servers.
Localhost/stdio MCP servers are only available in Claude Code and via the
API.

Sorry for the hassle

• K

On Fri, Apr 3, 2026 at 7:19 PM Neutrino @.***> wrote:

Neutrino-Sunset left a comment (anthropics/claude-code#2682) <https://github.com/anthropics/claude-code/issues/2682#issuecomment-4184624468> The link to the blog Debugging the Bridge — Architect's Notebook Log 14 <https://syzygysys.github.io/docs/architects_notebook/log_14.html> is 404, and pip install preflight-tools returns ERROR: Could not find a version that satisfies the requirement preflight-tools (from versions: none) — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/2682?email_source=notifications&email_token=BUJAM6B7KOXRNHTEM64TOOD4T76BJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJYGQ3DENBUGY4KM4TFMFZW63VGNVQW45LBNSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4184624468>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BUJAM6BQGGQVK67CLYGJI7D4T76BJAVCNFSM6AAAAACAKGC3W2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCOBUGYZDINBWHA> . You are receiving this because you are subscribed to this thread.Message ID: @.***>

but why cant Claude just spin up a couple more agents and automatically program support for stdio MCP in a couple of minutes ? The coding is solved anyway, agents are programming everything in a couple of minutes. Why can't the agents implement this?

Agents can, and do, build stdio MCP bridges. We built one in a single
session (163 lines of Python).

The constraint you're hitting is platform-level, not code-level:

   | Client                | stdio/local MCP | Remote (SSE/HTTPS) MCP |
   |-----------------------|-----------------|------------------------|
   | Claude Code (CLI/IDE) | ✅              | ✅                     |
   | Claude Desktop        | ❌              | ✅                     |
   | Claude mobile         | ❌              | ✅                     |

My read on it at the time we looked at this in november, was that it was
likely a security/sandboxing decision. Desktop apps are used by
non-technical users who install things. Allowing stdio means the app can
launch arbitrary local processes; that's a supply chain risk vector. A
malicious MCP server config could execute anything on the user's machine.
It's not that remote is safe it's that stdio gives the app process
launch capability, which is a privilege escalation that desktop apps
typically don't have. Browsers learned this lesson decades ago.

And judging by today's news on how Anthropic has decided to kill OpenClaw,
and soon other 3rd party interfaces, it was most likely done deliberately
back then, with today in mind...

https://techcrunch.com/2026/04/04/anthropic-says-claude-code-subscribers-will-need-to-pay-extra-for-openclaw-support/

• K

On Sun, Apr 5, 2026 at 4:07 PM nik @.***> wrote:

Nikita628 left a comment (anthropics/claude-code#2682) <https://github.com/anthropics/claude-code/issues/2682#issuecomment-4189029298> but why cant Claude just spin up a couple more agents and automatically program support for stdio MCP in a couple of minutes ? The coding is solved anyway, agents are programming everything in a couple of minutes. Why can't the agents implement this? — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/2682#issuecomment-4189029298>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BUJAM6HQ5DXJLGKM6MXV5QT4UJZETAVCNFSM6AAAAACAKGC3W2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCOBZGAZDSMRZHA> . You are receiving this because you are subscribed to this thread.Message ID: @.***>

I beg your pardon, but how come that the same MCP works in CLI mode, but not in the native mode? I mean, I just switch modes, no other changes. And also, are there some docs or something on the topic of properly adding MCP in native mode?

Still Broken. Still No Response.

April 3, 2026. This issue has been open for months. Zero responses from Anthropic engineers. Zero acknowledgment.

Today's count: Claude Desktop was told THREE SEPARATE TIMES in a single session that it has filesystem MCP access. Each time it said 'I don't have access to your filesystem.' Each time, telling it 'use the filesystem MCP' made it immediately work.

The fix is not complex. The tools are registered. The connection is active. The model just needs to know they exist at session start. This is a system prompt or tool discovery gap that should take hours to fix, not months.

Claude Code is marketed as a filesystem-aware agentic tool. On Claude Desktop, it disclaims that capability by default on every single session. For users running multi-agent workflows where Desktop is one of the agents, this is not a minor inconvenience — it breaks the entire workflow until the user manually corrects it.

Months open. Zero responses. Please at minimum acknowledge this is being tracked internally.

Desktop (native?), web, mobile, code cli, code ide, all report different
features and support different things depending on which version and
surface you run them on.

You can't even fully trust any of the interfaces to consistently and
honestly report what surface or version they are by directly prompting
them: "are you running on desktop, mobile, web, ide, or cli"? Try it.

Hard to say what's by design, or lack of design, intentional or just sloppy
practice. But probably all of the above.

• K

On Sun, 5 Apr 2026, 20:24 nik, @.***> wrote:

Nikita628 left a comment (anthropics/claude-code#2682) <https://github.com/anthropics/claude-code/issues/2682#issuecomment-4189394102> I beg your pardon, but how come that the same MCP works in CLI mode, but not in the native mode? — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/2682#issuecomment-4189394102>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BUJAM6CYH3NWXOAINT2WGY34UKXGZAVCNFSM6AAAAACAKGC3W2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCOBZGM4TIMJQGI> . You are receiving this because you are subscribed to this thread.Message ID: @.***>

Same issue on macOS — HTTP-type MCP servers connected but tools unavailable

Environment

• Claude Code: 2.1.161
• macOS Darwin 25.5.0
• 4 MCP servers configured (2 stdio, 2 HTTP)

Key observation: stdio works, HTTP does not

| Server | Type | mcp get status | Tool call result |
|--------|------|-----------------|-----------------|
| playwright | stdio | ✓ Connected | ✅ Works |
| chrome-devtools | stdio | ✓ Connected | ✅ Works |
| apifox-new-mcp | http | ✓ Connected | ❌ "No such tool available" |
| context7 | http | ✓ Connected | ❌ "No such tool available" |

Reproduction steps

1. Configure an HTTP-type MCP server via claude mcp add --transport http ...
2. Start a session — claude mcp get <name> shows ✓ Connected
3. Call WaitForMcpServers — returns ready: true
4. Attempt to call any tool from that server → No such tool available
5. stdio-type servers in the same session work perfectly

Additional finding

Curling the MCP HTTP endpoint directly returns:
{"jsonrpc":"2.0","error":{"code":-32000,"message":"Bad Request: No valid session ID provided"},"id":null}

This suggests Claude Code is reporting the server as "connected" before a valid session is actually
established, and the tool registration step never completes for HTTP-type servers.

Confirmed duplicate of #62072 and #62556.
https://github.com/issues/created?issue=anthropics%7Cclaude-code%7C69345

Adding OAuth scope evidence not present in those issues.

Logs from ~/Library/Logs/Claude/main.log confirm
user:mcp_servers is never requested by Cowork sessions:

scope: 'user:inference user:file_upload user:profile'

This is consistent across every Cowork session on this
machine. Claude Code CLI on the same machine works correctly.
App version: 1.13576.4 (414f85) — 2026-06-18

For anyone here on Claude Desktop with a local .mcpb extension (this thread has several different causes — OAuth, input-schema, stdio-pipe — so this is just one of them): a specific, reproducible one is that the manifest name must be identical to the serverInfo.name your server returns from initialize. If they differ, the extension installs, shows enabled, and the server answers initialize + tools/list, but the model never gets the tools and tools/call never fires — silently, with no warning. Making the two names identical fixes it.

Quick check: compare the top-level name in your manifest.json to the serverInfo.name in your server's initialize response. Full write-up, controlled A/B, and logs: #70397.

Faced the same issue on mac: in the Claude desktop UI everything appears to be correctly set up, but the agent does not have access to the tools. In my case the name of the MCP server seems to have been the issue. Renaming it from "Intervals.icu" to "intervals_icu" fixed it. The upper-case "I" or/and the underscore seems to have been problematic. It's odd because it has been working for months until it suddenly didn't anymore.