Claude Desktop 1.24012.0: all MCP tool calls fail ("Failed to call tool") — tool_result POST returns 404 side_channel_waiting_key_absent while servers respond normally

Likely the same incident as #79926 (Windows, same onset ~18:29 UTC 2026-07-21, same "Failed to call tool" symptom, remote connectors + Claude Code unaffected there too). Difference: there tools/call never reaches the server's stdin; here it reaches the server and a result comes back, but the tool_result POST fails with side_channel_waiting_key_absent. Both point at a server-side change in the tool-call side-channel rather than a client regression — my failures also predate and survive the client update to 1.24012.0.

This error pattern (tool_result POST returns 404 side_channel_waiting_key_absent) usually means the server is responding correctly to the tool call, but the response delivery mechanism fails — Claude expects the result on a side channel that doesn't exist or timed out.

First, confirm the server itself works by wrapping it with a debug proxy:

ash
pip install mcp-debug-proxy
mcp-debug --out debug_session.json -- python your_server.py


Then trigger the failing tool call. When it fails, check:


mcp-debug --report debug_session.json


This will show you:

• Whether the server actually received and processed the tool call
• What it returned (status, content, timing)
• Whether the response came back after Claude's timeout window

If the report shows the server returned successfully but Claude still shows failure, the issue is in the transport layer (stdio → HTTP bridging issue in 1.24012.0). If the server never got the request, it's a connection/routing issue.

The 1.24012.0 release had some MCP transport changes — check if rolling back to a previous version resolves it, which would confirm a regression.

@ZachDreamZ Thanks, but that diagnostic is already done and reported above: I drove the exact installed server directly over stdio JSON-RPC — it receives tools/call and returns valid results in <1s, and Desktop's own mcp-server-*.log confirms the same during failing sessions. The failure is strictly between the Desktop web layer and the backend (POST /tool_result → 404 side_channel_waiting_key_absent).

Rollback is also ruled out as a fix: per #79926 the failure survives a client update and hit machines that hadn't updated at all — onset was simultaneous (~18:29 UTC 2026-07-21), consistent with a server-side change, not a 1.24012.0 transport regression.

Heads-up: pip install mcp-debug-proxy — that package doesn't exist on PyPI (404), so others shouldn't go looking for it.

New finding (2026-07-22, Desktop 1.24012.1): a second, deterministic trigger — any tool declaring outputSchema is rejected client-side before dispatch

Follow-up to the original report. On 1.24012.1 we isolated a minimal repro:

• Our server (calibre-mcp, 19 tools) has exactly one tool with no outputSchema (calibre_ping) — it is the only tool that works. Every other tool shows "Tool execution failed", and the server's MCP transport log shows the tools/call for those tools never reaches the server (zero JSON-RPC traffic — pre-dispatch rejection, not a server error and not the result-submission failure from the original report).
• Controlled experiment: we built the same server with outputSchema removed from exactly one previously-failing tool (calibre_list_libraries), leaving an identical-shape tool (calibre_list_categories) unchanged as control. Fresh conversation: probe tool works, control fails 3/3. Server log for the session (init 2026-07-22T13:25:47Z): two tools/call arrive (ping, probe — both answered result(1 blocks) in <1s), zero traffic for the three control attempts.
• This also explains the bundled Filesystem server failing identically (list_allowed_directories, list_directory): current @modelcontextprotocol/server-filesystem declares outputSchema on its tools.

Minimal repro: any stdio server with two no-arg tools, identical except one declares outputSchema — the one with it fails, the one without works.

This makes every schema-conforming MCP server (per spec, outputSchema is a standard optional field) unusable in Desktop 1.24012.x.

Root cause isolated: the $schema meta-key in outputSchema triggers the pre-dispatch rejection

Follow-up to my previous comment. Bisected with a dependency-free stdio server exposing 7 no-arg tools with graduated outputSchema variants (Desktop 1.24012.1, macOS):

| outputSchema variant | Result |
|---|---|
| none | ✅ |
| {"type":"object"} | ✅ |
| + properties/required | ✅ |
| + additionalProperties:false | ✅ |
| + "$schema":"http://json-schema.org/draft-07/schema#" | ❌ never dispatched |
| full zod-like schema WITH $schema | ❌ never dispatched |
| same full schema WITHOUT $schema | ✅ |

The failing pairs differ by exactly the one $schema key; server stderr confirms those tools/call never arrive. inputSchema (which also carries $schema from zod) is unaffected — only outputSchema trips it.

This explains the blast radius: zod-to-json-schema inside the official MCP TypeScript SDK always emits $schema, so effectively every TS-SDK server declaring outputSchema is unusable in Desktop 1.24012.x, including the bundled Filesystem server.

Server-side workaround (verified, fully restores operation): strip the $schema key from each outputSchema in outgoing tools/list results — it's pure metadata, so this is semantics-free.

Corroborating this on Windows — same build family, same day, same umbrella symptom (all MCP tool calls fail, global, survives restart and new conversations). Cross-platform, so it's the 1.24012 build, not OS-specific.

Environment

• Claude Desktop 1.24012.1 (0adcae), built 2026-07-21T20:59:53Z
• Windows 11 Pro, Hyper-V enabled
• Anthropic direct MSIX (SignatureKind: Developer, not Store)
• Affects a local stdio filesystem server (@modelcontextprotocol/server-filesystem, launched via node directly). Onset: right after the auto-update to 1.24012.1 on 2026-07-21.

**One difference worth flagging — my failure looks like it happens earlier in the pipeline than yours:**

1. My MCP server log shows a clean handshake on every session — initialize → result, tools/list → result — and then zero tools/call entries. Unlike your macOS logs, the tool call never reaches the local server at all:

2026-07-22T13:51:07.641Z [github-projects] [info] Server started and connected successfully
2026-07-22T13:51:07.711Z [github-projects] [info] Message from client: method="initialize" id=0 params
                          Secure MCP Filesystem Server running on stdio
2026-07-22T13:51:08.099Z [github-projects] [info] Message from server: id=0 result
2026-07-22T13:51:08.144Z [github-projects] [info] Message from client: method="tools/list" id=1 params
2026-07-22T13:51:08.149Z [github-projects] [info] Message from server: id=1 result
                          (no tools/call ever follows)

For contrast, the same server on 2026-07-13 (pre-update) logged tool calls normally:

2026-07-13T17:01:49.895Z [github-projects] [info] Message from client: method="tools/call" id=2 params
2026-07-13T17:01:49.961Z [github-projects] [info] Message from server: id=2 result(1 blocks)

1. I searched claude.ai-web.log and the other logs and found no side_channel_waiting_key_absent and no tool_result 404. So on Windows the client appears to fail before the tool-result submission stage you captured — the call isn't being dispatched to the server in the first place.

Net: likely the same 1.24012 client regression, but manifesting one step earlier on Windows (no dispatch) vs the tool-result submit 404 on macOS. Might be two faces of the same broken tool-call side channel.

Ruled out on my side: server health (clean handshake every launch), launch method (node directly, no cmd/npx), config correctness, enterprise policy (no HKLM/HKCU Policies\Claude keys; isLocalDevMcpEnabled at default), and multiple-instance/split install (single MSIX). Happy to provide request IDs or full logs if useful for backend tracing.

@bfgmaster i fixed my problem here https://github.com/anthropics/claude-code/issues/79933#issuecomment-5047036349

Corroborating on Windows, with an important caveat: the server-side outputSchema/$schema workaround that restores operation on macOS is not sufficient on Windows 1.24012.1 — the tools still never surface.

Environment

• Claude Desktop 1.24012.1 (0adcae), built 2026-07-21T20:59:53Z
• Windows 11 Pro; Anthropic direct MSIX (SignatureKind: Developer, not Store); single install
• Node.js v24.13.0
• Local stdio server: @modelcontextprotocol/server-filesystem, launched via node directly (no npx/cmd wrapper). Onset: right after the auto-update to 1.24012.1 on 2026-07-21.

Confirms @caelum29's root cause, plus the exact npm version boundary

The $schema key inside outputSchema is the trigger. Checking the published tarballs of @modelcontextprotocol/server-filesystem:

• 2025.8.21 and earlier — no outputSchema at all → clean
• 2025.11.25 and later, through 2026.7.10 (current latest) — emit outputSchema (with $schema via zod-to-json-schema) → affected

So the newest unaffected published version is 2025.8.21.

But on Windows 1.24012.1 the server-side fix does NOT restore operation

After downgrading to 2025.8.21 (verified npm ls -g → 2025.8.21; confirmed the tarball has zero outputSchema references), the filesystem tools still can't be used:

• The server log shows a clean handshake on every launch — initialize → result, tools/list → result, no EPIPE — and zero tools/call ever arrive. (Same server logged tools/call normally pre-update, through 2026-07-13.)
• Tried a fresh connector key (renamed the config key github-projects → github-projects-fs) to rule out cached client state — no change.
• In the UI the connector shows as added/active in Settings but has no enable toggle in a chat's + menu, and the model reports the server's tools as unavailable. The client registers the server but will not expose its tools.

Representative server log — 2025.8.21, fresh key, clean handshake, no dispatch:

[github-projects-fs] Server started and connected successfully
[github-projects-fs] method="initialize" id=0
                     Secure MCP Filesystem Server running on stdio
[github-projects-fs] Message from server: id=0 result
[github-projects-fs] method="tools/list" id=1
                     using allowed directories set from server args: [ 'D:\Github' ]
[github-projects-fs] Message from server: id=1 result
                     (no tools/call ever follows)

Interpretation

On Windows 1.24012.1 the regression looks broader than the outputSchema pre-dispatch rejection isolated on macOS. Even a fully clean tools/list (no outputSchema) under a brand-new connector key does not restore tool availability — the client ingests the server but won't surface its tools, so no tools/call is ever attempted. Stripping $schema fixes the macOS case but is insufficient here, which points to an additional client-side fault in the Windows 1.24012.x build.

Ruled out on my side

Server health (clean handshake every launch), launch method (node directly), config correctness, EPIPE (separately worked around via node-direct launch), enterprise policy (no HKLM/HKCU Policies\Claude keys; isLocalDevMcpEnabled at default), and multiple-instance/split install (single MSIX package).

Net: this needs a client-side fix — the server-side outputSchema mitigation is not a complete workaround on Windows 1.24012.x. Happy to provide full logs or request IDs for backend tracing.

Resolved for me as of 2026-07-23 — on an unchanged client build, with the current outputSchema-emitting server.

Environment: Claude Desktop 1.24012.1 (0adcae, built 2026-07-21), Windows 11 Pro. No client update since my earlier Windows report — the build string is identical to when it was broken — and no local config changes.

Crucially, I'm on @modelcontextprotocol/server-filesystem@2026.7.10 (current latest), which does emit outputSchema ($schema via zod-to-json-schema) — the exact payload that was triggering the pre-dispatch rejection. I've been on this version for ~19h; it was broken yesterday and works today. Filesystem tool calls now dispatch and return results, read and write both confirmed, and the normal "Claude wants to use \<tool\>" permission prompt now appears (it never got that far before).

Server log — tools/call reaching the server and returning results, the step that was silently missing on every prior session:

2026-07-23T13:58:48.189Z  method="tools/call" id=2
2026-07-23T13:58:48.191Z  Message from server: id=2 result(1 blocks)
2026-07-23T14:00:21.864Z  method="tools/call" id=3
2026-07-23T14:00:21.866Z  Message from server: id=3 result(1 blocks)

Same client build + same outputSchema-bearing server that failed yesterday, now working with no local change → this is a server-side / backend fix, and it covers the actual $schema-in-outputSchema case, not just a stripped-down schema. So on Windows 1.24012.x the resolution came without a client update.