MCP servers report Connected but expose zero tools via ToolSearch (persists across restarts, reinstalls, and OS reboot)

Status Closed — not planned
Reported on v2.1.241
Maintainer reply None cached
Activity 1 comment · opened Aug 24, 2026 · closed Aug 24, 2026

Description

Two project-local MCP servers (playwright, stdio, and fal, HTTP) both report ✔ Connected via claude mcp get <name>, but their tools never appear via ToolSearch (the mechanism Claude Code uses to load deferred MCP tool schemas). This persists across every restart/reinstall combination we tried, across multiple sessions on the same machine.

Environment

  • Claude Code version: 2.1.241
  • OS: Windows 11 Home 10.0.26200
  • Shell: PowerShell (primary), Git Bash also available

MCP server config (project-local scope, from .claude.json)

"playwright": {
  "type": "stdio",
  "command": "npx",
  "args": ["-y", "@playwright/mcp@latest"],
  "env": {}
},
"fal": {
  "type": "http",
  "url": "https://mcp.fal.ai/mcp",
  "headers": { "Authorization": "Bearer <redacted>" }
}

Steps to reproduce

  1. Add the two servers above at local project scope (claude mcp add ... -s local).
  2. Start a session in the project directory.
  3. Run claude mcp get playwright and claude mcp get fal — both report Status: ✔ Connected.
  4. Ask Claude to use a Playwright or fal tool, or call ToolSearch directly with e.g. select:mcp__playwright__browser_navigate or a keyword query like "playwright" / "fal".
  5. ToolSearch returns "No matching deferred tools found" for both servers, every time.

What we tried (all failed to fix it)

  • Starting a brand-new session (same terminal process)
  • Fully closing and relaunching the terminal application
  • claude mcp remove <name> -s local followed by claude mcp add ... to re-add fresh
  • A full Windows OS restart (not just terminal relaunch)
  • Every ordering/combination of the above (e.g. remove+re-add then full OS restart)

In every case, claude mcp get <name> continues to report ✔ Connected immediately, but ToolSearch never surfaces any mcp__playwright__* or mcp__fal__* tool, in that session or any subsequent one.

Other observations

  • This does not appear to be a general ToolSearch failure: other deferred MCP/tool namespaces (e.g. mcp__claude-in-chrome__*, mcp__plugin_sentry_sentry__*) load and are callable via ToolSearch without issue in the same sessions.
  • claude mcp list (the bulk command) is inconsistent: in some sessions its first invocation omits playwright/fal entirely from the printed list (while other servers show fine), and a second, immediate invocation shows all servers including both as ✔ Connected. This suggests the server health-check/registration is asynchronous and can race the first list call.
  • Both a stdio server (playwright) and an HTTP server (fal) are affected identically, which argues against a transport-specific cause (e.g. a slow first-run binary download for Playwright's Chromium) — we did also separately confirm the Playwright Chromium binary was fully downloaded and not still installing, and the bug persisted regardless.

Expected behavior

If claude mcp get <name> reports a server as Connected, its tools should be discoverable via ToolSearch (or claude mcp list should reflect the same status consistently, and tool discovery should not require an unpredictable number of session/process/OS restarts to succeed).

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗