[BUG] Claude Code fails to expose MCP tools to AI sessions when running a local Playwright MCP server

Config might need a "type":

{
  "mcpServers": {
    "playwright": {
      "type": "sse",
      "url": "http://host.docker.internal:8931/sse"
    }
  }
}

but I dont think would fix your issue as your MCP is recognized even without it.

I have the same error with the new connectors from Claude.ai with paid pro plan. It could be the same issue in their backend. I tried several things, but after successful oauth to the remote mcp server exposed in a cloud, the connecotr is connected in their console but the available tools will not be shown because Claude never starts tools/list request.

According to MCP Specs:
"To discover available tools, clients send a tools/list request. This operation supports pagination."

I'm also facing this issue in a reproducible and consistent manner.
After successful OAuth authentication with a remote MCP server, Claude establishes the connection, but never initiates the tools/list call, making all tools inaccessible within Claude.
I've validated this using multiple working test scripts and confirmed through logs that the issue is not related to configuration errors. The problem persists across different environments and appears to be systemic in how Claude handles MCP integration after OAuth.
Would appreciate any updates or guidance on potential workarounds. This is currently blocking core development workflows.

Just as a side note Anthropic updated there infos just one day ago regarding the handling of self build remote mcp servers.
https://support.anthropic.com/en/articles/11503834-building-custom-connectors-via-remote-mcp-servers
They claim that they support now 06-18 specs, and additional features but I wonder how they have developed those features if not even basic functionalities such as the tools/list request is working? @ollie-anthropic are you aware of those problems or can you provide more information why your client is not behave accoridng to the mcp specs?

Yeah @samuelhurni, pretty strange. It’s been a couple of days, and the basic functionality on which everything else depends is still broken.
@ollie-anthropic, is there any known workaround for this?

@ollie-anthropic, it would be nice to have feedback about this issue.

I am also facing this issue in Claude.AI Web UI (Max Plan) when adding a Custom Connector. After successful OAuth authentication with a remote MCP server, Claude establishes the connection, but never initiates the tools/list call, making all tools inaccessible within Claude. The remote MCP server uses Transport Type Streamable HTTP.

Confirming this happens to my integration too.

I’ve gone through the flow hundreds of times and confirmed that it’s 100% compliant with the latest MCP oauth spec.

From my cloudflare workers logs I see the same pattern each time:

• [401] HEAD /
• successfully retrieves metadata from well-known endpoints
• user is redirected to, and successfully passes through, 3rd-party oauth flow
• successful dynamic client registration also occurs sometime during this flow
• redirected back to Claude’s callback URL and connections screen
• toast message displays claiming that the server is successfully connected
• “Connect” button in claude.ai still displays instead of “Configure”
• corroborated by Cloudflare logs showing all the oauth routes being accessed as expected, with no errors, but there is never any subsequent call back to the original resource after successful authentication. So of course tools/list does not appear in the logs

Same issue with serena

🐛 Root Cause Identified: Infinite Recursion in @browsermcp/mcp

I've identified the exact bug causing MCP tools to not be exposed. It's an infinite recursion in the browsermcp package that crashes the server during cleanup.

The Bug

Location: node_modules/@browsermcp/mcp/dist/index.js (lines 248-252)
Package Version: @browsermcp/mcp@0.1.3

server.close = async () => {
    await server.close();  // ← BUG: Calls itself infinitely!
    await wss.close();
    await context.close();
};

What Happens

1. ✅ Claude Code connects to the MCP server
2. ✅ Server successfully returns tool list via tools/list
3. ❌ Server immediately crashes with RangeError: Maximum call stack size exceeded
4. ❌ Claude Code never registers the tools because the server dies

Reproduction

echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | npx @browsermcp/mcp@latest

Output:

{"result":{"tools":[...]}} 
# Server returns tools successfully

RangeError: Maximum call stack size exceeded
    at server.close (file://.../node_modules/@browsermcp/mcp/dist/index.js:248:18)
    at server.close (file://.../node_modules/@browsermcp/mcp/dist/index.js:249:18)
    at server.close (file://.../node_modules/@browsermcp/mcp/dist/index.js:249:18)
    [... infinite recursion ...]

The Fix

The developer tried to wrap server.close() to add cleanup logic but forgot to save the original method reference:

// FIXED VERSION:
const originalClose = server.close?.bind(server);
server.close = async () => {
    if (originalClose) {
        try { await originalClose(); } catch (e) {}
    }
    await wss.close();
    await context.close();
};

Temporary Workaround

Patch the installed package (this is a one-time fix per installation):

// save as fix_browsermcp.js
const fs = require('fs');
const path = require('path');
const glob = require('glob');

// Find the package
const files = glob.sync('**/node_modules/@browsermcp/mcp/dist/index.js', {
    cwd: process.env.HOME,
    absolute: true
});

if (files.length === 0) {
    console.error('❌ @browsermcp/mcp not found');
    process.exit(1);
}

const packagePath = files[0];
console.log(`📦 Found package at: ${packagePath}`);

// Read the file
const content = fs.readFileSync(packagePath, 'utf8');

// Fix the bug
const buggyCode = `  server.close = async () => {
    await server.close();
    await wss.close();
    await context.close();
  };`;

const fixedCode = `  const originalClose = server.close?.bind(server);
  server.close = async () => {
    if (originalClose) {
      try { await originalClose(); } catch (e) {}
    }
    await wss.close();
    await context.close();
  };`;

const fixed = content.replace(buggyCode, fixedCode);

if (fixed === content) {
    console.log('⚠️  Pattern not found - may already be patched or version mismatch');
    process.exit(0);
}

// Write the fixed version
fs.writeFileSync(packagePath, fixed, 'utf8');
console.log('✅ Patched browsermcp infinite recursion bug');
console.log('🔄 Restart Claude Code to apply the fix');

Run with: node fix_browsermcp.js

Then fully quit and restart Claude Code (Cmd+Q on Mac, not just close window).

Verification

After patching and restarting, test that the server doesn't crash:

echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | npx @browsermcp/mcp@latest | jq -r '.result.tools[] | .name'

Expected output (no crash):

browser_navigate
browser_go_back
browser_screenshot
...

Permanent Solution

This bug should be fixed in the @browsermcp/mcp package itself. I recommend:

1. Opening an issue at https://github.com/BrowserMCP/mcp/issues
2. Submitting a PR with the fix shown above

Impact

This bug affects all users trying to use browsermcp with Claude Code. The server appears "Connected" in claude mcp list but crashes during the first tool list request, causing the "Failed to get tool list" timeout errors.

---

Environment:

• macOS (but likely affects all platforms)
• @browsermcp/mcp@0.1.3 (latest)
• Node.js v22.18.0
• Claude Code v1.0.43

Hope this helps! 🚀

Adding in here that I also see the same issue.
I have created my own small MCP server with some resources and tools and when initializing it returns both:

$ curl -X POST http://127.0.0.1:8000/mcp/jsonrpc -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","method":"initialize","params":{"protocolVersion":"2024-11-05"},"id":1}
{"jsonrpc":"2.0","result":{"protocolVersion":"2024-11-05","serverInfo":{"name":"MCP NetOps","version":"1.0.0"},"capabilities":{"tools":{},"resources":{}}},"id":1}

But Claude Code only detects the resource-capability, not tools.

> /mcp
╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ Netops MCP Server                                                                                                                                                                                                     │
│                                                                                                                                                                                                                       │
│ Status: ✔ connected                                                                                                                                                                                                   │
│ URL: http://127.0.0.1:8000/mcp/jsonrpc                                                                                                                                                                                │
│ Config location: /home/markus/.claude.json [project: /home/markus/git/mcp-netops]                                                                                                                                     │
│ Capabilities: resources

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.

Comprehensive Diagnosis: MCP Tool Availability in Subprocess/Plugin Context

We've identified and confirmed this issue affects multiple MCPs in subprocess contexts, not just Playwright. This appears to be a Claude Code CLI environment inheritance problem when spawning subprocesses.

Diagnostic Summary

Test Environment:

• 5X VM (Debian 12, containerized)
• Claude Code CLI with 7 active MCPs: exa, firecrawl, basic-memory, beads, probe, clickup, snowflake
• Multiple projects with independent BEADS databases and Basic Memory configurations

Key Finding: MCP tool availability is 100% reliable when accessed directly via the CLI, but fails ~30% of the time when invoked through subprocesses (plugin context, bash -c, etc.).

Evidence: Multi-MCP Confirmation

This issue extends beyond Playwright to affect multiple MCPs:

1. BEADS MCP (stdio-based)

• Direct CLI queries: 9/9 successful (100%)
• Subprocess queries: ~7/10 successful (~30% failure rate)
• Error: "No such tool available: bd-list" / "No such tool available: bd-show"

1. Basic Memory MCP (stdio-based)

• Tested in subprocess context: Same "No such tool available" errors
• Confirms issue is systemic to stdio MCP transport in subprocesses

1. Plugin Context Reproducibility

• /session-start plugin (runs as subprocess) consistently experiences MCP failures
• Direct CLI calls to same tools: 100% success rate
• Error frequency increases with number of MCP invocations in single plugin run

Root Cause Analysis

The issue is not with individual MCP servers (all show "✓ Connected" in registry), but rather Claude Code CLI's subprocess environment handling:

1. Environment Variable Inheritance: Subprocess contexts may not inherit complete MCP registry or tool list from parent
2. MCP Process Management: Multiple MCP instances spawn instead of reusing stdio connections (observed PIDs: 882, 12427, etc.)
3. Tool Registry Synchronization: Tool availability information from tools/list requests appears to degrade in subprocess contexts

This aligns with your diagnosis in this thread: "Claude Code successfully communicates with the MCP server, but fails to retrieve tool list via tools/list request".

Reproduction Steps

1. Run CLI with active MCPs configured in /home/.claude/.claude.json
2. Execute /session-start plugin (or any subprocess that invokes multiple MCPs)
3. Observe ~30% failure rate on MCP tool invocations with "No such tool available" errors
4. Run identical commands directly via CLI: 100% success rate

Suggested Investigation Areas

1. Subprocess environment setup - Ensure CLAUDE_CONFIG_DIR and tool registry are fully inherited
2. MCP stdio connection lifecycle - Verify connections aren't being prematurely closed/recreated
3. Tool list caching - Check if tool availability information is stale in subprocess contexts
4. Environment variable propagation - Confirm MCP-related env vars reach subprocess MCPs

Related MCP Repositories

For users who may be looking at MCP server issues:

• BEADS MCP: https://redirect.github.com/steveyegge/beads
• Basic Memory MCP: https://redirect.github.com/basicmachines-co/basic-memory

These MCPs operate correctly in direct CLI context; the issue is Claude Code's subprocess environment, not the MCP servers themselves.

Summary

This appears to be a systemic issue affecting all stdio-based MCPs in plugin/subprocess contexts, not individual server implementations. The diagnosis suggests environment variable inheritance or tool registry synchronization problems in Claude Code's subprocess handling.

## Comprehensive Diagnosis: MCP Tool Availability in Subprocess/Plugin Context We've identified and confirmed this issue affects multiple MCPs in subprocess contexts, not just Playwright. This appears to be a Claude Code CLI environment inheritance problem when spawning subprocesses. ### Diagnostic Summary Test Environment: - 5X VM (Debian 12, containerized) - Claude Code CLI with 7 active MCPs: exa, firecrawl, basic-memory, beads, probe, clickup, snowflake - Multiple projects with independent BEADS databases and Basic Memory configurations Key Finding: MCP tool availability is 100% reliable when accessed directly via the CLI, but fails ~30% of the time when invoked through subprocesses (plugin context, bash -c, etc.). ### Evidence: Multi-MCP Confirmation This issue extends beyond Playwright to affect multiple MCPs: 1. BEADS MCP (stdio-based) - Direct CLI queries: 9/9 successful (100%) - Subprocess queries: ~7/10 successful (~30% failure rate) - Error: "No such tool available: bd-list" / "No such tool available: bd-show" 2. Basic Memory MCP (stdio-based) - Tested in subprocess context: Same "No such tool available" errors - Confirms issue is systemic to stdio MCP transport in subprocesses 3. Plugin Context Reproducibility - /session-start plugin (runs as subprocess) consistently experiences MCP failures - Direct CLI calls to same tools: 100% success rate - Error frequency increases with number of MCP invocations in single plugin run ### Root Cause Analysis The issue is not with individual MCP servers (all show "✓ Connected" in registry), but rather Claude Code CLI's subprocess environment handling: 1. Environment Variable Inheritance: Subprocess contexts may not inherit complete MCP registry or tool list from parent 2. MCP Process Management: Multiple MCP instances spawn instead of reusing stdio connections (observed PIDs: 882, 12427, etc.) 3. Tool Registry Synchronization: Tool availability information from tools/list requests appears to degrade in subprocess contexts This aligns with your diagnosis in this thread: "Claude Code successfully communicates with the MCP server, but fails to retrieve tool list via tools/list request". ### Reproduction Steps 1. Run CLI with active MCPs configured in /home/.claude/.claude.json 2. Execute /session-start plugin (or any subprocess that invokes multiple MCPs) 3. Observe ~30% failure rate on MCP tool invocations with "No such tool available" errors 4. Run identical commands directly via CLI: 100% success rate ### Suggested Investigation Areas 1. Subprocess environment setup - Ensure CLAUDE_CONFIG_DIR and tool registry are fully inherited 2. MCP stdio connection lifecycle - Verify connections aren't being prematurely closed/recreated 3. Tool list caching - Check if tool availability information is stale in subprocess contexts 4. Environment variable propagation - Confirm MCP-related env vars reach subprocess MCPs ### Related MCP Repositories For users who may be looking at MCP server issues: - BEADS MCP: https://redirect.github.com/steveyegge/beads - Basic Memory MCP: https://redirect.github.com/basicmachines-co/basic-memory These MCPs operate correctly in direct CLI context; the issue is Claude Code's subprocess environment, not the MCP servers themselves. ### Summary This appears to be a systemic issue affecting all stdio-based MCPs in plugin/subprocess contexts, not individual server implementations. The diagnosis suggests environment variable inheritance or tool registry synchronization problems in Claude Code's subprocess handling.

I can confirm this happens to me as well. I can also confirm the 30% failure rate. This is too strange.

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.

I'm experiencing a related issue on Claude Code 2.0.75 (macOS):

New observation: MCP tools become unavailable to the main conversation session mid-session, but subagents spawned via the Task tool DO have access to the same tools.

• claude mcp list shows playwright-electron as "✓ Connected"
• Main session cannot see mcp__playwright-electron__* tools
• Spawning a subagent via Task tool successfully accesses those tools
• No config changes made during session

This suggests the tool registration is working at spawn time but becomes stale/disconnected for long-running parent sessions. The subagent workaround may help others while this is being investigated.

Still happening please fix

Hello, any update on this issue? It is still consistently reproducible for me, here's a diagnosis claude agent ran:

recursing_heisenberg            | 
recursing_heisenberg            | Based on my investigation, here's what I found:
recursing_heisenberg            | 
recursing_heisenberg            | **What's Working:**
recursing_heisenberg            | 1. ✅ The Playwright MCP server is running (process ID 93)
recursing_heisenberg            | 2. ✅ The MCP server binary is available at `/app/node_modules/.bin/mcp-server-playwright`
recursing_heisenberg            | 3. ✅ The Claude Agent SDK is configured with the correct MCP configuration
recursing_heisenberg            | 4. ✅ The `--allowedTools mcp__playwright__*` parameter is set correctly
recursing_heisenberg            | 
recursing_heisenberg            | **The Issue:**
recursing_heisenberg            | The Playwright MCP tools are not being exposed in my function schema despite the server running. This suggests there's a communication issue between the MCP server and the Claude Agent SDK. The tools should be available with names like:
recursing_heisenberg            | - `mcp__playwright__browser_navigate`
recursing_heisenberg            | - `mcp__playwright__page_click` 
recursing_heisenberg            | - `mcp__playwright__page_fill`
recursing_heisenberg            | - etc.
recursing_heisenberg            | 
recursing_heisenberg            | **Expected Tools (from the README):**
recursing_heisenberg            | - `browser_navigate` - Navigate to a URL
recursing_heisenberg            | - `browser_navigate_back/forward` - Navigation controls
recursing_heisenberg            | - `page_click` - Click elements
recursing_heisenberg            | - `page_fill` - Fill form fields
recursing_heisenberg            | - `page_screenshot` - Take screenshots
recursing_heisenberg            | - `page_get_content` - Get page content
recursing_heisenberg            | - And many more...
recursing_heisenberg            | 
recursing_heisenberg            | **Possible Root Causes:**
recursing_heisenberg            | 1. **MCP Protocol Version Mismatch** - The server and SDK might be using incompatible MCP protocol versions
recursing_heisenberg            | 2. **Initialization/Handshake Failure** - The initial connection between the MCP server and SDK may have failed
recursing_heisenberg            | 3. **Tool Registration Issue** - The tools might not be getting registered properly in the SDK's function schema
recursing_heisenberg            | 
recursing_heisenberg            | **Recommendation:**
recursing_heisenberg            | Since the Playwright MCP server is properly installed and running but the tools aren't available, this appears to be an infrastructure-level issue with the MCP integration rather than a configuration problem. You may need to:
recursing_heisenberg            | 
recursing_heisenberg            | 1. Restart the Claude Agent SDK with fresh MCP connections
recursing_heisenberg            | 2. Check for any MCP protocol compatibility issues between versions
recursing_heisenberg            | 3. Verify the MCP server is properly responding to the SDK's requests
recursing_heisenberg            | 
recursing_heisenberg exited with code 0

Still happening for me as well. When I told it about the pagination it was finally able to find all tools, but not within the /mcp command.