[Bug] Claude Desktop: MCP Filesystem tools/call never reaches server after starting new conversation

[andresjsc]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

Environment

• OS: Windows 11
• Claude Desktop App (native, NOT browser)
• MCP Filesystem server status: running
• Claude Pro account
• Configured directories: C:\Users\GUSA CAPITAL\Documents, C:\Users\GUSA CAPITAL\source\repos, C:\Users\GUSA CAPITAL\Documents\excel

What happened

The Filesystem MCP tools worked correctly two days ago. After starting a new conversation today, all tool calls fail with "Failed to call tool" error. The server shows as "running" in Settings > Developer. No configuration changes were made.

What the logs show

I checked %APPDATA%\Claude\Logs\mcp-server-Filesystem.log (3,331 lines, 1.2MB — months of working history).

Every new conversation today shows this exact pattern:

2026-07-22T15:21:24.733Z [Filesystem] [info] Server started and connected successfully
2026-07-22T15:21:24.894Z [Filesystem] [info] Message from client: method="initialize" id=0
2026-07-22T15:21:25.991Z [Filesystem] [info] Message from server: id=0 result
2026-07-22T15:21:30.399Z [Filesystem] [info] Message from client: method="notifications/initialized"
2026-07-22T15:21:30.405Z [Filesystem] [info] Message from client: method="tools/list" id=1
2026-07-22T15:21:30.411Z [Filesystem] [info] Message from server: id=1 result

There is NO tools/call entry anywhere. The server initializes correctly and lists tools, but when Claude attempts to execute a tool (list_directory, list_allowed_directories), the call never reaches the server.

Root cause hypothesis

The app successfully completes the MCP handshake and lists available tools, but tool call messages are not being forwarded to the MCP server when a new conversation starts. This is a routing bug in Claude Desktop.

Reproduction steps

1. Have a working Filesystem MCP server configured in Claude Desktop
2. Start a NEW conversation
3. Ask Claude to use any Filesystem tool
4. Result: "Failed to call tool" error — tool call never appears in mcp-server-Filesystem.log

What I already tried

• Full restart of Claude Desktop (confirmed no background processes)
• Single instance only (no multiple windows)
• Both backslash and forward-slash path formats
• Multiple new conversations — same result every time

This is a regression. The same setup worked in a previous conversation two days ago.

[SebTardif]

@andresjsc

There is NO tools/call entry anywhere. The server initializes correctly and lists tools, but when Claude attempts to execute a tool (list_directory, list_allowed_directories), the call never reaches the server.

If mcp-server-Filesystem.log shows initialize and tools/list but never tools/call, the Filesystem process is fine. Claude Desktop is dropping the invocation on the client side before it writes to the server's stdio.

That matches a new conversation more than a dead server: handshake is per window, tool execution is gated again when the thread starts.

Check these in the failing chat

1. Open the connectors / hammer control in that conversation (not only Settings > Developer). filesystem can show "running" globally and still be disabled or not approved for the new thread.
2. When Claude tries list_allowed_directories, you should get an Allow / Deny prompt. If you never see it, or you dismissed it once, Desktop reports Failed to call tool and sends nothing. There will be no tools/call line.
3. Read %APPDATA%\Claude\logs\mcp.log (the app log, not mcp-server-Filesystem.log) around the same timestamp. The client-side reject is usually only there.

Windows-specific footgun in your allowlist

The profile is C:\Users\GUSA CAPITAL\... (space in the account name). A working older conversation can keep using an already-approved session while a new one re-parses the config and fails the allowlist check inside Desktop. Test with a directory that has no spaces:

"args": [
  "-y",
  "@modelcontextprotocol/server-filesystem",
  "C:\\mcp-allow"
]

Create C:\mcp-allow, fully quit Claude (tray icon too), restart, start a new chat, enable the connector there, and ask it to list that folder.

If handshake works and the new chat still never prompts

That is a Desktop routing bug, not an MCP server bug. Useful evidence for Anthropic / the Desktop repo:

• mcp-server-Filesystem.log excerpt with initialize + tools/list and no tools/call
• matching mcp.log lines
• whether an Allow prompt appeared

There is no Filesystem server flag that will invent a tools/call the host never sent. Until Desktop forwards the method, the workaround is: re-enable the connector in the new thread, approve the first tool prompt, and avoid spaces in the allowlist paths while you confirm the client is actually sending calls.