OfflineCreator Studio
AI Router · CLI · MCPCheapest eligible quotes before you create
troubleshooting · retention

Understand GET 405 on Streamable HTTP MCP

Distinguish an intentional POST-only endpoint from a wrong route or unsupported client probe.

Treat a GET response as evidence about GET only. In the 2026-07-28 transport, every client JSON-RPC message must be a new POST to the MCP endpoint; a server that supports only that revision should return 405 to GET. In the 2025-11-25 transport, client JSON-RPC messages also use POST, while GET is limited to requesting an optional standalone SSE listening stream. A GET 405 therefore cannot establish whether a valid POST request would succeed.

Evaluate the POST against the rules for its pinned revision. A 2026-07-28 request must advertise application/json and text/event-stream, carry the required request metadata headers, and send an MCP-Protocol-Version value matching the version in the JSON-RPC request metadata. A 2025-11-25 request also advertises both response content types, but follows that revision's initialization, session, optional GET-stream, and protocol-version rules.

Sources
Connect OfflineCreator with OAuth
Freshness marker

A GET 405 can be the correct MCP response

Do not diagnose the status from the number alone. First record the HTTP method, exact path, response headers, response body, and negotiated MCP protocol version. Under MCP revision 2026-07-28, standalone GET streaming and protocol-level sessions were removed. A server that implements only that revision should answer GET or DELETE at its MCP endpoint with 405 Method Not Allowed. JSON-RPC traffic goes to that endpoint with POST.

The meaning is different in the 2025-11-25 Streamable HTTP revision. That revision lets a client issue GET with Accept: text/event-stream to open an optional server-to-client SSE stream. A conforming server could either return that stream or return 405 to say it did not offer a standalone SSE stream. Under either pinned revision discussed here, therefore, a GET 405 can be intentional rather than proof that the MCP endpoint is broken.

Sources
Evidence rail

Pin the transport behavior to the protocol revision

MCP 2026-07-28
GET 405 is expected on a modern-only endpointThis revision uses a fresh POST for each JSON-RPC message, removes the standalone GET stream, and removes protocol-level sessions. A modern-only server should reject older GET and DELETE traffic with 405.
MCP 2025-11-25
GET was an optional SSE listening pathA client could request text/event-stream with GET. The server had to return an SSE response or 405, so 405 specifically meant that no standalone SSE stream was offered at that endpoint.
HTTP+SSE 2024-11-05
GET can be transport discovery, not a tool callA compatibility client may try GET after a failed POST to detect the older transport and wait for its endpoint event. Treat that fallback as version negotiation, not as the normal modern request path.
Sources
Transport switch

Choose the next check from the failing method

GET is 405, POST succeeds
Treat the endpoint as usableOn 2026-07-28 this is expected modern-only behavior. On 2025-11-25 it means the server declined the optional standalone SSE stream; POST request-response traffic can still work. Keep the GET and POST outcomes separate even if a client UI still shows a fatal toast or unreachable card: an open Claude Code and Claude Desktop report describes capability-refresh failures around a GET 405 on a host toolbox/SSE path while reporters also recorded successful POST tool calls. Treat that thread as unresolved client or proxy behavior, not as proof that the origin MCP endpoint is down.
GET is 405, POST is never attempted
Correct the client transport or probeConfirm that the client is configured for Streamable HTTP and sends JSON-RPC messages by POST. Pin the client's protocol era before changing the server.
POST is 405
Verify the endpoint path and transport eraThe 2026-07-28 and 2025-11-25 Streamable HTTP revisions use POST for JSON-RPC messages. A 405 on POST is therefore different from the permitted GET-only case. Check the Allow header, response body, and whether the configured URL belongs to an older HTTP+SSE server.
POST fails and compatibility is required
Use a client's defined fallback, not repeated blind retriesThe 2026-07-28 compatibility procedure permits legacy fallback after POST returns 400, 404, or 405 only when the body is not a recognized modern JSON-RPC error. The client then tries GET and expects an endpoint event from an old HTTP+SSE server.
Sources
Compatibility stamp

Read the 405 as an HTTP response before changing MCP code

RFC 9110 defines 405 as a known method that the target resource does not support. The origin server must include an Allow header listing the methods currently supported by that resource. If POST appears in Allow, the response supports the diagnosis that the path exists but the GET probe is not accepted. If the header is absent, record that standards mismatch; do not infer the allowed method from the status alone.

Also preserve the response body and Content-Type. Current MCP compatibility logic allows legacy fallback after specified HTTP failures only when the body is not a recognized modern JSON-RPC error. An empty or unrecognized failure body and a recognized modern JSON-RPC error therefore lead to different compatibility decisions even when the HTTP status number matches.

Sources
Related circuit

Use the troubleshooting directory when POST, initialization, or tool discovery also fails. Use the token-exchange guide when the 404 belongs to the OAuth token endpoint rather than the MCP path. Use the JSON-RPC parse guide when HTTP succeeds but the response cannot be decoded as protocol data.

Canonical plate

Editorial ownership boundary

This page owns GET 405 interpretation for Streamable HTTP MCP and the revision-specific split between an intentional rejection and a wrong route or client probe. Authentication failures, OAuth endpoint 404s, session recovery, JSON-RPC parsing, and broad connection triage remain with their narrower guides.