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

[FlavorFlav25]

Claude Code version 1.0.43 has a critical bug preventing MCP (Model Context Protocol) tools from being exposed to AI sessions, specifically affecting local Playwright MCP server integration. This issue has been reproduced consistently across multiple Claude Code sessions and affects both stdio and SSE transport mechanisms.

Environment Details

System Information

• OS: Linux 6.6.87.2-microsoft-standard-WSL2 (Windows Subsystem for Linux)
• Platform: WSL2 on Windows
• Node.js: v20.19.3
• NPM: 10.8.2
• Claude Code Version: 1.0.43
• Working Directory: /mnt/f/PlayWrightMCP

MCP Server Details

• Package: @playwright/mcp@0.0.29
• Protocol Version: 2024-11-05
• MCP SDK: @modelcontextprotocol/sdk@^1.15.1

Bug Description

Primary Issue

Claude Code successfully starts MCP servers but fails to expose MCP tools to AI sessions. The browser_navigate, browser_take_screenshot, and other Playwright tools are not available despite proper MCP server configuration and successful server startup.

Error Manifestations

1. Tool Availability: Error: No such tool available: browser_navigate
2. Timeout Errors: "Failed to get tool list", "error": "Request timeout (30s)"
3. Protocol Communication: MCP server starts but Claude Code cannot communicate with it properly
4. Cross-Session Persistence: New Claude Code sessions cannot see configured MCP servers

Reproduction Steps

Configuration Attempted (All Failed)

1. Manual JSON Configuration

// /home/user/.config/claude/mcp-settings.json
{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp"],
      "env": {
        "HEADLESS": "true"
      }
    }
  }
}

Result: Tools not exposed, server not recognized

2. Claude MCP Add Command (Stdio)

claude mcp add playwright -- npx @playwright/mcp@latest --headless --user-data-dir ~/.cache/claude-playwright

Result: Server configured but tools not exposed

3. WSL Shell Wrapper

claude mcp add playwright-wsl /bin/sh -c "npx @playwright/mcp@latest --headless"

Result: Same issue - server starts but tools unavailable

4. SSE Transport (HTTP)

# Start server on port 3001
npx @playwright/mcp@latest --port 3001

# Configure SSE transport
{
  "mcpServers": {
    "playwright": {
      "url": "http://localhost:3001/sse"
    }
  }
}

Result: Server accessible via HTTP but tools still not exposed to Claude Code

Verification of MCP Server Functionality

Direct Server Communication Test

# Test direct communication with MCP server
echo '{"jsonrpc": "2.0", "id": 1, "method": "tools/list"}' | npx @playwright/mcp@latest

Result: ✅ Server responds correctly with full tool list (26 tools available)

Process Verification

ps aux | grep -i playwright
# Shows: MCP server process running successfully (PID 12751)

claude mcp list
# Shows: playwright: npx @playwright/mcp@latest --headless --user-data-dir /home/user/.cache/claude-playwright

Expected vs Actual Behavior

Expected Behavior

After configuring MCP server, Claude Code should:

1. Successfully communicate with the MCP server
2. Retrieve the tool list via tools/list request
3. Expose tools like browser_navigate, browser_take_screenshot, etc.
4. Allow AI sessions to use these tools directly

Actual Behavior

Claude Code:

1. ✅ Recognizes MCP server configuration
2. ✅ Starts MCP server process successfully
3. ❌ Fails to retrieve tool list (30s timeout)
4. ❌ Does not expose any MCP tools to AI sessions
5. ❌ Cannot use tools across different Claude Code sessions

Error Logs and Evidence

MCP Security Log Entries

{"timestamp":"2025-07-13T01:21:16.145Z","level":"error","message":"Failed to get tool list","data":{"error":"Request timeout (30s)"}}
{"timestamp":"2025-07-13T01:21:16.149Z","level":"info","message":"🔧 Tool call received","data":{"toolName":"browser_navigate","args":{"url":"https://google.com"}}}

Claude Code Debug Information

claude mcp list
# Output: playwright: npx @playwright/mcp@latest --headless --user-data-dir /home/user/.cache/claude-playwright

# But tools are not available:
browser_navigate(url="https://google.com")
# Error: No such tool available: browser_navigate

MCP Server Startup Success

ℹ️ [2025-07-13T01:29:49.314Z] INFO: 🚀 Starting Secure Playwright MCP Server
ℹ️ [2025-07-13T01:29:49.317Z] INFO: 🎭 Launching Microsoft Playwright MCP server...
ℹ️ [2025-07-13T01:29:49.343Z] INFO: 🔒 Secure Playwright MCP wrapper is ready
ℹ️ [2025-07-13T01:29:52.345Z] INFO: ✅ Microsoft Playwright MCP server started

Root Cause Analysis

Based on extensive testing and research, the issue appears to be a protocol validation bug in Claude Code 1.0.43 where:

1. Stdio Transport Bug: Claude Code fails to include proper protocolVersion field when preparing initialize requests for stdio MCP servers
2. Timeout Issues: Communication timeouts occur during the tools/list request phase
3. WSL Environment Issues: Additional complications in WSL2 environments with stdio communication
4. Tool Registration Failure: Even when MCP server starts successfully, individual tools are not registered in Claude Code's tool registry

Impact Assessment

Severity: CRITICAL

• Functionality: Complete loss of local MCP server integration
• User Experience: Users cannot use any MCP tools, defeating the purpose of MCP integration
• Development Workflow: Severely impacts development productivity for users relying on browser automation

Affected Functionality

• ❌ Local Playwright MCP integration
• ❌ Browser automation capabilities
• ❌ Web scraping and testing workflows
• ❌ Cross-session MCP tool persistence
• ❌ Any stdio-based MCP server integration

Workarounds Attempted (All Failed)

1. Environment Variables: MCP_TIMEOUT=60000, DISPLAY=:0
2. Alternative Installation Methods: Direct npx, shell wrappers, manual JSON config
3. Transport Alternatives: Both stdio and SSE (HTTP) transports tested
4. Configuration Variations: Project-level vs global configuration
5. Server Variations: Official Microsoft MCP vs custom security wrapper

None of these workarounds resolved the tool exposure issue.

Recommended Solutions

Immediate Fix Required

1. Fix Protocol Validation: Resolve the protocol validation bug preventing stdio communication
2. Improve Error Reporting: Provide clearer error messages when MCP tool registration fails
3. Enhance Timeout Handling: Implement more robust timeout mechanisms for MCP communication

Version Compatibility

• Current Issue: Claude Code 1.0.43 with @playwright/mcp@0.0.29
• Recommend Testing: Newer Claude Code versions (if available) with same MCP setup
• Backward Compatibility: Ensure future versions maintain compatibility with existing MCP configurations

WSL-Specific Fixes

• Stdio Transport: Fix stdio communication issues in WSL2 environments
• Process Management: Improve child process handling for MCP servers in WSL
• Environment Detection: Auto-detect WSL environment and apply appropriate configurations

Additional Context

Multi-Agent Reproduction

This issue has been consistently reproduced by 4 different AI agents attempting the same integration, confirming this is not a configuration error but a systematic bug in Claude Code.

Community Impact

Based on research, this appears to be a known issue affecting multiple users attempting local MCP server integration, particularly with Playwright MCP servers.

Test Cases for Verification

1. Basic Tool Exposure: After MCP configuration, verify browser_navigate tool is available
2. Cross-Session Persistence: Verify tools remain available across Claude Code restarts
3. Multiple Transport Types: Test both stdio and SSE transport mechanisms
4. WSL Compatibility: Ensure proper function in WSL2 environments

Files and Logs Available

• Configuration Files: /mnt/f/PlayWrightMCP/.mcp.json, /home/user/.config/claude/mcp-settings.json
• Log Files: /mnt/f/PlayWrightMCP/logs/mcp-security.log
• Test Scripts: Multiple working test scripts demonstrating MCP server functionality
• Environment Setup: Complete reproduction environment available

Contact Information

Reporter: User experiencing the issue
Environment: WSL2 Linux, Claude Code 1.0.43
Reproduction Rate: 100% consistent across multiple sessions and agents
Urgency: High - Blocks essential development workflow functionality

---

Status: OPEN
Priority: P1 (Critical functionality broken)
Component: Claude Code MCP Integration
Affects Versions: 1.0.43 (confirmed), potentially earlier versions

[stevemarksd]

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.

[samuelhurni]

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."

[AnshumanSharma23]

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.

[samuelhurni]

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?

[AnshumanSharma23]

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?

[FlavorFlav25]

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

[BenjiJack]

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.

[jkhaui]

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