[Bug] Claude Desktop: "Could not attach to MCP server {NAME OF MCP SERVER}"

[jigarvyasidea]

Description

Everything is working properly:

• MCP server is running
• Configuration is valid
• The tool works and gives correct responses when tested directly

The MCP tool itself is functioning fine.
But in Claude Desktop pop-up, it still shows:

So the tool is usable, but the Desktop client UI wrongly shows this error.

---

Steps to Reproduce

1. Start MCP server (works fine independently).
2. Add configuration in claude_desktop_config.json.
3. Restart Claude Desktop.
4. Test the tool → it responds correctly.
5. Open Desktop pop-up → error message appears:

---

Expected Behavior

Claude Desktop should:

• Attach to the MCP server without error

---

Actual Behavior

• MCP tool works and returns responses
• But the Claude Desktop pop-up shows only an error message:

---

Additional Notes

• Everything else works perfectly, only the pop-up shows a misleading error
• Tool calls and responses are successful despite the error
• Tried restart, absolute paths, different transports → still same result

[jigarvyasidea]

can you please help me with this i faceing this from last 2 week @olaservo , @dsp-ant and @jspahrsummers

[mosesleesh]

Same here, keep popping up even all MCP works fine.

[brs96]

Also getting the same issue. Claude Desktop, the server and tool calling are working, but the error pops up.

[fourbytes]

Yep same here

[sreenaths]

Same here. I can reproduce with the following configuration.

{
    "mcpServers":
    {
        "math-server":
        {
            "command": "uvx",
            "args":
            [
                "--from",
                "minimcp-servers",
                "math-server"
            ],
            "env":
            {
                "MCP_SERVER_LOG_FILE": "/tmp/math_mcp_server.log"
            }
        }
    }
}

[riyas50]

It also stops the session unexpectedly without completion and the chat title remains untitled. After the reload, the chat session become blank. [Pro Subscription]

[AnotherAngleSolutions]

I also am experiencing the same bug after using WinGet to install the script on Windows 11.

I'm using the following config:
{ "mcpServers": { "fetch": { "command": "uvx", "args": ["mcp-server-fetch"] } } }

[steschas-jimdo]

We are also experiencing this problem, and here are some observations, hope they help:

• I had a working MCP setup last Wednesday (2025-09-17)
• I did not use my machine after that and before Monday (2025-09-22) (vacation)
• On Monday this issue appeared in version 0.13.11
• I upgraded on Monday (after experiencing this issue) to 0.13.19 - thus, I believe, I was on 0.13.11 when it was working
• MCP server is working correctly using Cursor and MCP inspector
• My MCP has logs: spawning the MCP shows correct logs, also Claude Desktop receives the tool list correctly and also shows it in the config
• When sending a prompt in Claude Desktop, it shows the wait spinner indefinitely, when clicking the "stop" button, it shows a correct request using the correct tool from the MCP
• However, when Claude is waiting, the logs don't show any further output, while the MCP logs every request correctly in the logs when using Cursor/MCP inspector
• I set PYTHONUNBUFFERED=1 for the MCP and verified that it is received in the env within Python - this didn't change anything
• We downgraded to 0.9.1 (only other dmg we had), this was working in the past with the same MCP, but now shows the same problem

So, the issue seems to be between Claude Desktop and the MCP, it somehow doesn't seem to send the request, but is waiting for a response that never comes. As this happened to a working setup, and also persists with old versions, we guess that some underlying dependency changed something. It is possible, I upgraded Cursor on the Monday I was back, which might have updated some shared library, or some electron settings. Still, I couldn't trace it much further than the wait loop and the missing log output.

System: Apple M1 Max
OS: macOS Sequoia 15.6.1 (24G90)

From "About Cursor":

Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.6.0

[olaservo]

I believe this was an issue with Claude Desktop that has since been resolved.

[correspond9]

20 April 2026, not resolved yet

[Shehzadcyber]

21 May 2026, Not resolved yet this error, i'm facing the same error

[correspond9]

21 May 2026, Not resolved yet this error, i'm facing the same error

Dude, because of your comment, it had came to my attention that iI had wrongly mentioned the month as May instead of April.
I corrected it, you should too.

[Fuijin]

Hit the same symptom from a different repo (TKasperczyk/thunderbird-mcp) and tracked the root cause down today, sharing in case it helps anyone landing here.

Symptom: Claude Desktop spawns the MCP server, logs Server started and connected successfully, the client sends initialize, then 60 seconds later the client cancels with MCP error -32001: Request timed out. No Message from server: ... log entry ever appears -- the server's response is never observed by the client.

Root cause: Claude Desktop's "built-in Node.js" host loads each .cjs MCP server through an internal wrapper script. Confirmed via runtime trace from inside our bridge:

LOAD require.main===module: false
LOAD require.main path: ...\Claude\app.asar\.vite\build\mcp-runtime\nodeHost.js
LOAD module.filename: ...\thunderbird-mcp\mcp-bridge.cjs
LOAD argv=["node.exe", "...\thunderbird-mcp\mcp-bridge.cjs"]

Standard CommonJS entry-point detection:

if (require.main === module) {
  startServer();
}

evaluates to false under this wrapper. Top-level constants get evaluated and the file is loaded, but startServer() never runs, no stdio listener is registered, and the client sits at the 60s timeout. Affects any hand-rolled MCP server that uses the classic require.main === module idiom; servers that use @modelcontextprotocol/sdk's Server class avoid it because the SDK's setup is unconditional at module load time.

Fix: fall back to argv heuristic when require.main !== module:

const _autoStart = (() => {
  if (require.main === module) return true;
  try {
    const entry = (process.argv && process.argv[1]) || '';
    if (entry && path.basename(entry) === 'mcp-server.cjs') return true;
  } catch { /* fall through */ }
  return false;
})();

if (_autoStart) startServer();

After the fix, the same trace shows:

AUTOSTART decision=true (require.main===module: false, argv[1]_basename=mcp-server.cjs)
STARTBRIDGE entered
STDIN-DATA bytes=246 preview="...initialize..."
STDOUT-WRITE-CB ok

Worth noting in the server authoring docs -- the SDK examples don't trip this because they call await server.connect(transport) unconditionally at the bottom of the file, but anyone porting an existing CJS server with a require.main guard will hit it on Claude Desktop ≥ ~1.388 with mcpb extensions.

Diff for our project's fix is at TKasperczyk/thunderbird-mcp#81.