The value of the Allow header a 405 Method Not Allowed response must carry
at the MCP endpoint. Per RFC 9110 §10.2.1 the Allow header MUST enumerate
the set of methods the resource actually supports. On the stable revisions
(2025-03-26 / 2025-06-18 / 2025-11-25) the single MCP endpoint "supports both
POST and GET methods" (basic/transports §Streamable HTTP) — the standalone
server->client SSE stream is mounted on GET (getOpensSseStream is true) — so a
405 (e.g. to a DELETE the server does not honour) MUST advertise GET, POST.
On the draft the standalone GET stream and protocol-level DELETE are both
dropped, leaving POST as the only supported method, so the header is POST.
The GET stream is, however, only actually mounted on a stateful server: a
stateless server answers GET with 405 Allow: POST (handleGet) regardless of
version. getSupported carries that mode gate so the DELETE 405 cannot
advertise a GET the same endpoint provably rejects with its own 405.
The value of the Allow header a 405 Method Not Allowed response must carry at the MCP endpoint. Per RFC 9110 §10.2.1 the Allow header MUST enumerate the set of methods the resource actually supports. On the stable revisions (2025-03-26 / 2025-06-18 / 2025-11-25) the single MCP endpoint "supports both POST and GET methods" (basic/transports §Streamable HTTP) — the standalone server->client SSE stream is mounted on GET (getOpensSseStream is true) — so a 405 (e.g. to a DELETE the server does not honour) MUST advertise GET, POST. On the draft the standalone GET stream and protocol-level DELETE are both dropped, leaving POST as the only supported method, so the header is POST.
The GET stream is, however, only actually mounted on a stateful server: a stateless server answers GET with 405 Allow: POST (handleGet) regardless of version. getSupported carries that mode gate so the DELETE 405 cannot advertise a GET the same endpoint provably rejects with its own 405.