Exact error
Match the message before using the fix
side_channel_waiting_key_absentTool result could not be submittedFailed to call toolQuick answer
Start here
Do not reinstall every MCP server first. Compare the MCP server log with `claude.ai-web.log`: if the server returns the tool result normally but Desktop's `tool_result` POST receives 404 with `side_channel_waiting_key_absent`, the failure is after the server has finished. Update Desktop and test a new conversation, but the primary report says a full restart and fresh conversations did not recover it. Preserve the request ID and report the client/backend failure; no confirmed durable user fix is published.
Diagnosis
Why it happens
- The MCP server successfully handles `tools/call` and returns a result, so process launch, tool execution, and stdio transport are healthy in the source report.
- Claude Desktop's web layer then fails to submit the result to the conversation backend because the expected side-channel key is absent.
- A generic `Failed to call tool` can also come from a crashing or timing-out server; the web-log error code is what distinguishes this branch.
Safest first
Fixes, in order
Prove the MCP server returned successfully
Applies when: When every server and tool fails with the same empty UI message
The upstream report spent time debugging healthy servers because the UI hid the client/backend error.
- Call one harmless tool from a bundled server and one from a local server.
- Open each MCP server log and find the matching `tools/call` request and result.
- Record whether the result returned in normal time without a server crash or stderr error.
- If the server itself fails, diagnose that server instead.
Expected: Multiple healthy servers return results while Desktop still renders `Failed to call tool`.
Confirm the tool_result side-channel error
Applies when: Healthy server results that never reach the conversation
The exact branch appears in the Desktop web log as an HTTP 404 on the tool_result request.
- Open `claude.ai-web.log` for the same timestamp as the failed tool call.
- Find the `tool_result` POST response and its error code.
- Record `side_channel_waiting_key_absent`, the request ID, Desktop version, and conversation scope.
- Do not publish authentication headers, organization identifiers, or conversation contents.
Expected: The log names `side_channel_waiting_key_absent` and proves the failure is after MCP execution.
Update Desktop and preserve a minimal diagnostic report
Applies when: The confirmed client/backend branch
No local configuration repair is confirmed; the useful action is to test the current build and give the upstream team traceable evidence.
- Update Claude Desktop through its official channel and fully quit the app.
- Start a new conversation and call one harmless bundled tool.
- If the same error returns, submit the Desktop version, timestamp, redacted request ID, and paired server/web-log result through official feedback.
- Leave healthy MCP packages and their configuration unchanged while the client issue is investigated.
Expected: A newer build resolves the client state, or you produce a minimal reproducible report without damaging working servers.
Verification
Prove the fix worked
- Call a harmless tool from two different MCP servers in a new conversation.
- Confirm the results appear in chat and the tool_result POST no longer returns the side-channel error.
- Verify server logs and Desktop logs agree on a successful end-to-end call.
Escalation
If it still fails
- Do not rotate server tokens, reinstall all MCP packages, or rewrite stdio configuration when server logs show successful results.
- Redact organization, conversation, request content, and authentication data before sharing logs.
- Record whether the error affects all servers and all new conversations; a single-tool failure is a different branch.
Scope
Environment and version notes
- The primary report used Claude Desktop 1.24012.0 on macOS 26.2 and affected both a local extension and the bundled Filesystem extension.
- The issue remained open on August 20, 2026 and did not include a confirmed durable workaround.
- Sources rechecked August 20, 2026.
Evidence
Sources
Source labels describe the evidence available on the checked date. A closed issue is not automatically a shipped fix.