[BUG] Claude Desktop macOS: filesystem MCP server unusable in both package generations - new schema never dispatched, old schema dropped at registration

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Related: #79986 (same symptom, Windows), modelcontextprotocol/servers#4545, modelcontextprotocol/servers#4543

Since Desktop auto-updated (~19–21 July window), all tool calls to @modelcontextprotocol/server-filesystem servers configured via classic mcpServers in claude_desktop_config.json fail on macOS. Reproduces identically on two machines - Desktop 1.24012.0 (Mac mini M4) and 1.22209.3 (MacBook Air M1) - both macOS 26.5.2, node v20.18.0 via nvm, absolute-path config. Worked reliably for months before.

Tested both package generations:

1. server-filesystem ≥2025.11.25 (tested 2026.1.14 and 2026.7.10, outputSchema/structuredContent shape): server completes initialize + tools/list, tools appear in chat, but every call fails instantly with "Tool execution failed". Per-server log shows no tools/call ever arrives; mcp.log has zero tools/call entries for these servers while other servers log them normally in the same session. No error logged anywhere.

1. server-filesystem 2025.8.21 (pre-rewrite shape, which per servers#4545 works on Windows): server connects, answers tools/list correctly (verified by piping initialize/tools/list JSON-RPC directly at the binary over stdio - full tools array returned), but Desktop shows "This connector has no tools available" - tools silently dropped at registration. Renaming the server entry to rule out cached definitions changed nothing. macOS diverges from Windows here.

Control case isolating the trigger: a minimal custom stdio server built on the current @modelcontextprotocol/sdk using registerTool with inputSchema only - no outputSchema - executes flawlessly in the same session and turn, on the same directory the filesystem server fails on. Same node runtime, same transport. The client appears to choke specifically on outputSchema/structuredContent in tool definitions (dispatch refused), while also rejecting the pre-outputSchema shape at registration on macOS.

Ruled out by direct testing: package version (both generations), config (2-server minimal repro), PATH (logs show correct binary resolution, clean spawn), Full Disk Access restore + reboot, permission-gate bypass pref, re-auth, server count/name collisions. Claude Code with the identical config and binaries: unaffected.

Impact: local filesystem access - the main reason to run Desktop - is fully broken with the official server; only custom no-outputSchema servers work.

What Should Happen?

Filesystem server tools should register and dispatch normally on current-SDK tool schemas (outputSchema/structuredContent), as they did before the 19–21 July Desktop updates and as they still do in Claude Code with the identical config. Dispatch failures should surface a real error instead of a bare "Tool execution failed", and registration drops should be visible somewhere other than a silent "no tools available".

Error Messages/Logs

Tool call in chat: bare "Tool execution failed" toast + failed tool block. No error anywhere in logs.

mcp-server log for a filesystem server (every session since breakage — note nothing after tools/list):
[user-local] Server started and connected successfully
[user-local] Message from client: method="initialize" id=0
[user-local] Message from server: id=0 result
[user-local] Message from client: method="notifications/initialized"
Client does not support MCP Roots, using allowed directories set from server args: [ '/Users/USER/code/user-master' ]
[user-local] Message from client: method="tools/list" id=1
[user-local] Message from server: id=1 result
// No tools/call ever arrives.

grep "tools/call" mcp.log since 21 July: entries exist ONLY for custom stdio servers; zero for any filesystem server. Last filesystem tools/call: 20 July 09:39 UTC.

With package 2025.8.21: Connectors UI shows "This connector has no tools available" despite the binary returning a full tools array when driven directly over stdio.

Steps to Reproduce

1. macOS 26.5.2, Claude Desktop 1.24012.0, node v20 via nvm, npm i -g @modelcontextprotocol/server-filesystem (2026.7.10)
2. claude_desktop_config.json mcpServers entry: {"command": "mcp-server-filesystem", "args": ["/Users/USER/code/somedir"]}
3. Launch Desktop — server connects, tools appear in chat
4. In any chat, invoke any tool from it, e.g. list_allowed_directories (takes no arguments)
5. Fails instantly: "Tool execution failed". Per-server log shows no tools/call received
6. Control: add a second config entry for a minimal custom SDK server (registerTool, inputSchema only, no outputSchema) doing fs.readdir on the same directory — its calls dispatch and succeed in the same chat
7. Variant: npm i -g @modelcontextprotocol/server-filesystem@2025.8.21, relaunch — connector now shows "no tools available" despite binary answering tools/list correctly over raw stdio

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown exact build - Mac mini's pre-20-July build worked (last successful filesystem tools/call logged 20 July

Claude Code Version

0.2.86

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Related: #79986 (identical symptom, Windows MSIX), modelcontextprotocol/servers#4545 (identifies the ≥2025.11.25 outputSchema rewrite as the version boundary on Windows), modelcontextprotocol/servers#4543.

macOS diverges from the Windows findings: the pre-rewrite 2025.8.21 package, which works on Windows per #4545's dist-swap test, is dropped at registration on macOS ("no tools available"). So neither package generation works here.

Custom-SDK control server (no outputSchema) working in the same session/turn suggests the dispatch refusal keys on outputSchema/structuredContent in tool definitions specifically.

Reproduces on two machines, two Desktop builds (1.24012.0 M4 mini / 1.22209.3 M1 Air), same macOS 26.5.2, broke in the 19–21 July auto-update window with no local changes.