skip to content

Why does an MCP Streamable HTTP server answer GET or DELETE with 405 Method Not Allowed?

level: middleimportance: should knowfreq 58%

answer

  1. one endpoint, one verb
  2. both dead verbs had a job once
  3. listening is now a request, not a verb
  4. there is no server-side thing to delete
  5. 405, not 404

basics

~20 s

Because in MCP revision 2026-07-28 the Streamable HTTP endpoint is POST-only. The GET listening stream and the DELETE termination call both belonged to earlier revisions, so a server implementing only 2026-07-28 SHOULD reject those verbs with 405 Method Not Allowed.

solid answer

~40 s

MCP's Streamable HTTP endpoint accepts `POST` and nothing else in revision 2026-07-28. Two verbs used to have meaning and no longer do. `GET` opened a standalone server-to-client listening stream; server-initiated traffic now arrives on a long-lived `subscriptions/listen` call, which is itself a POST. `DELETE` terminated a protocol session; protocol-level sessions were removed in this revision, so there is nothing left to delete. A server that implements only the modern revision SHOULD therefore answer either verb with `405 Method Not Allowed`. That response is also diagnostically useful: a `405` on `GET` is a clear signal to a client or an operator that the server is modern-only, whereas an older dual-era server will still honour the legacy verbs.

code

http · 7 lines
http
GET /mcp HTTP/1.1
Host: example.com
Accept: text/event-stream

HTTP/1.1 405 Method Not Allowed
Allow: POST
Content-Length: 0

go deeper

for a junior

Know that the MCP HTTP endpoint takes POST only, and that a GET or DELETE against it is answered with 405 Method Not Allowed.

for a middle

Explain what those verbs used to do — a GET listening stream and a DELETE session teardown — and name what replaced each in revision 2026-07-28.

for a senior

Bring the deployment consequences: health checks must not target the endpoint, HTTP caching cannot apply to a POST-only surface, and a 405 on GET is a quick era signal when debugging a fleet.

for a principal

Argue the design: collapsing to a single verb removes a whole class of connection-affinity and lifecycle bugs and makes the endpoint trivially placeable behind standard infrastructure, at the cost of giving up HTTP-native caching and browsable URLs.

## The rule One endpoint, one verb. In MCP revision 2026-07-28 the Streamable HTTP transport defines `POST` as the only method the endpoint serves. A server implementing only this revision SHOULD respond to `GET` or `DELETE` with HTTP `405 Method Not Allowed`. ## What GET used to do In revisions up to 2025-11-25, a client could issue a `GET` to the same MCP endpoint with `Accept: text/event-stream` to open a standing stream on which the server could push messages that were not the answer to any particular request — list-changed notifications, and server-initiated requests. That channel is gone in 2026-07-28. Traffic that is genuinely server-initiated now flows over a dedicated call, `subscriptions/listen`, in which the client explicitly names the change classes it wants to hear about. Because that call is an ordinary POST whose response stays open, the transport does not need a second verb to express "I want to listen": listening is just a request whose response is long. ## What DELETE used to do Earlier revisions carried a protocol-level session identified by an `Mcp-Session-Id` header, and a `DELETE` to the endpoint told the server the client was done with that session so its state could be released. Revision 2026-07-28 removed protocol-level sessions entirely — every request is self-contained — so there is no server-side session object for a `DELETE` to address, and the verb was removed with it. ## Why 405 and not 404 or 400 `405 Method Not Allowed` is the precise HTTP answer to "this resource exists, that method does not apply to it". It says the endpoint is real and the client used the wrong verb, which is exactly the situation. Contrast the neighbouring failure: an unknown *JSON-RPC* method inside a valid POST is a different thing entirely — that is JSON-RPC error `-32601`, method not found, returned with HTTP `404`. So on this endpoint, `405` is about the HTTP verb and `404` is about the JSON-RPC method name. Confusing the two produces a client that retries the wrong thing. ## The diagnostic value The deployed MCP fleet in 2026 straddles two eras, and the response to `GET` is a cheap discriminator. A `405` says the server serves the modern, POST-only transport. A dual-era server that still supports the pre-2026 handshake will typically still honour the legacy verbs, so it will not answer `405`. This does not replace proper version handling — a client's authoritative signal is what the server says about protocol revisions — but as a quick operational check, curling the endpoint with `GET` tells you a lot in one round trip. It is also a useful *server-side* check on your own deployment. If your endpoint answers `GET` with a `200` and an HTML page, or with a `502`, you have almost certainly got a proxy or a framework route in front of the MCP handler that is not doing what you think it is. ## Operational consequences of POST-only - **Health checks.** Load balancers default to `GET /` or `GET /health`. Pointing a health check at the MCP endpoint will produce a permanent `405` and mark the target unhealthy. Give the service a separate health path outside the MCP endpoint. - **Caching.** HTTP caches key on method and generally do not cache POST responses. MCP therefore expresses cacheability in the protocol instead — results that may be cached carry `ttlMs` and `cacheScope` — rather than relying on HTTP cache semantics that a POST-only design cannot reach. - **Browsers and links.** There is no such thing as "opening the MCP endpoint in a browser". Any tooling that assumes a `GET`-able URL, including many API explorers, needs configuring for POST. - **CORS preflight.** A browser-based client will send `OPTIONS` before a cross-origin POST with custom headers such as `Mcp-Method`; that is a CORS mechanic rather than an MCP method, and a server that intends to serve browser clients has to handle it deliberately. ## What an interviewer wants to hear The summary they are testing is: "POST only — GET and DELETE are 405, because the GET listening stream and the DELETE session teardown were both removed in 2026-07-28, and each has a replacement or has simply ceased to exist." The weak answer describes the old two-channel design as though it were current, which is precisely the tell these questions are built to catch.

  • How does a client receive server-pushed notifications now that GET is gone?
    It sends `subscriptions/listen` as a POST and keeps the response stream open, naming the change classes it wants through a filter — tools, prompts and resources list changes, plus specific resource URIs. Notifications arrive on that stream. Request-scoped traffic such as progress messages is unaffected: it still travels on the originating request's own response stream.
  • On this endpoint, when would a client see 404 rather than 405?
    When the POST was well-formed HTTP but named a JSON-RPC method the server does not implement. That is JSON-RPC error `-32601`, method not found, delivered with HTTP `404`. `405` is strictly about the HTTP verb. A client should react differently to each: `405` means fix the transport call, `404` means that protocol method is unavailable here.
  • What breaks if you point a load balancer health check at the MCP endpoint?
    The check sends `GET`, gets a permanent `405`, and marks every instance unhealthy — so the pool drains and the service goes dark despite being fine. Expose a separate health path that is not the MCP endpoint, or configure the check to POST a cheap MCP method such as `server/discover` and accept its 200.

saying these in an interview costs you the question

  • Describes a long-lived GET stream as the current way to receive pushes
  • Says DELETE ends an MCP session
  • Answers an unknown JSON-RPC method with 405 instead of 404 and -32601
  • Puts the load balancer health check on the MCP endpoint
  • Thinks 405 means the endpoint URL is wrong

context

resolving links…