MCP Server Errors: Timeout, 406, CORS and -32601
What an MCP timeout, 406 Not Acceptable, CORS failure and -32601 Method not found each mean, which side causes them, and how often 1,100 real servers produced them.
These four errors fill a lot of "my MCP server is broken" threads, and none of them usually means the server is down. A timeout is mostly a tool that runs longer than the client will wait. A 406 is the client's Accept header. A CORS failure only happens in a browser. A -32601 is a method the server does not have.
We can say "usually" with a number behind it. On 20 August 2026 we called 1,100 remote MCP servers from the official registry, once each, for our registry census. Not one of them timed out, and not one answered with a 406. One answered with a -32601. The failures that did happen were HTTP 404s (36), 402s (10), 5xx errors (11) and refused connections (17).
TL;DR:
| Error | Usually caused by | First thing to check |
|---|---|---|
| Timeout | A slow tool call, or a server the client cannot reach | Whether initialize answers quickly; if it does, the tool is the slow part |
| 406 Not Acceptable | The client's Accept header |
It must list both application/json and text/event-stream |
| CORS error | A browser-based client calling the server directly | The server's Access-Control-* headers |
| -32601 Method not found | A method the server does not implement | Which method was called, and which protocol revision each side speaks |
Timeout
There are two different timeouts and they need different fixes.
A connect timeout means the client never got an answer to its first request. The server is unreachable from where the client runs: a private address, a firewall, a hostname that does not resolve, or a process that is not listening. This is the one worth testing from outside your network, because a server that answers your laptop may not answer anything else.
A tool-call timeout means the connection worked and a tool took longer than the client was willing to wait. One OpenAI API user hit this as "Timed out while waiting for response to ClientRequest. Waited 60.0 seconds." while their server was still working [1]. The server is not broken. The tool is slow, and each client sets its own limit.
How to tell which one you have: run the handshake on its own. If initialize and tools/list come back in under a second, the server is fine and the problem is one slow tool. Our census bears this out from the other side: with a 10-second limit per request, none of the 1,100 servers ran out of time answering the handshake. The ones that failed answered with an HTTP status or refused the connection.
Fixes for a slow tool:
- Return early and poll. Start the work, return an ID straight away, and give the client a second tool that reports status. This is the only fix that works across every client.
- Send progress. A server can send
notifications/progresson the request's SSE stream while it works [2]. Whether that resets a client's timer is up to the client. - Check the proxy. A reverse proxy that buffers responses can hold back a stream until it times out. The spec recommends sending
X-Accel-Buffering: noon SSE responses for exactly this [2].
406 Not Acceptable
A 406 says the server will not answer in any format the client said it accepts. On Streamable HTTP the cause is almost always the Accept header, because the spec requires the client to list both formats on every POST [2]:
Accept: application/json, text/event-stream
The server may answer either way, so a client that only accepts one has not met the requirement, and a server that enforces it answers with a 406 rather than guess. Typical sources are a hand-written curl with -H "Accept: application/json", an HTTP client library that sets its own default, or a proxy that rewrites the header.
Our tester sends the correct header, and across 1,100 servers it never got a 406 back. So if you see one, look at the client first. To check the server by hand, send the header exactly as above: testing an MCP server with curl has the full request.
CORS errors
CORS only applies when the client is a web page running in a browser and calls your MCP endpoint directly. Desktop clients, command-line tools and hosted clients such as ChatGPT or Claude's connectors make server-to-server requests, which CORS does not touch. If you only see the error in a browser console, that is why.
For a browser client to work, the server has to answer the preflight OPTIONS request and allow what MCP sends:
Access-Control-Allow-Origin: https://your-app.example
Access-Control-Allow-Methods: POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Accept, Authorization, MCP-Protocol-Version, Mcp-Method, Mcp-Name
Access-Control-Expose-Headers: WWW-Authenticate
Mcp-Method and Mcp-Name are request headers the 2026-07-28 revision requires on every POST [2], so a server that allowed only the older header set will start failing preflight for new clients. Expose WWW-Authenticate so a browser client can read where to sign in after a 401. A server still on the 2025 revisions, which used sessions, also needs Mcp-Session-Id in both the allowed and the exposed list, or the client can never read the session it was given (what Mcp-Session-Id is).
Do not answer with * and call it done. The spec requires servers to validate the Origin header and to answer 403 Forbidden when it is present and not allowed, to stop DNS rebinding attacks on local servers [2]. Allow the origins you serve.
Our census cannot measure this one: the tester is a server, so it sends no Origin header and never triggers CORS.
-32601 Method not found
-32601 is the standard JSON-RPC code for "this method does not exist here" [3]. In MCP it comes up in three ways:
- A capability the server never declared. Calling
resources/listorprompts/liston a server that only offers tools. Check thecapabilitiesthe server returned before calling anything else (what capabilities are). - A typo or an old method name in a hand-written request.
- The two sides speak different protocol revisions. The 2026-07-28 revision removed the
initializehandshake, and a server that does not implement a requested method must now answer404 Not Foundwith a-32601body [2]. So an older client callinginitializeon a server that only speaks the newest revision can get exactly this.
That last case is the one we saw. Of the 1,100 census servers, one answered our initialize with -32601: Unknown method: initialize. Its address worked and its server was running. The two sides simply did not share a method to start with. The protocol revision page covers how clients negotiate a version.
A bare 404 with an empty body is different: that is usually the wrong URL. It was the most common HTTP error in our census, 36 servers, and the connection failed guide walks through it.
Check the server from outside first
Three of these four errors start with the same question: is the server answering at all, from a network other than yours? Our MCP connection test sends the handshake from our server with the correct Accept header, then calls tools/list, and tells you which of these it got: a full answer with the tool list, a 401 from a server guarding itself, a 404 or 5xx, a page that is not an MCP endpoint, a hostname that does not resolve, or a refused connection. If that comes back clean, the problem is in the client or in one slow tool, and the sections above say where to look.