A client works with a Streamable HTTP server until the server answers a slow tools/call with Content-Type text/event-stream instead of application/json; from then on the client fails. What is the root cause?
Select an answer to reveal the explanation.
Short Explanation
On Streamable HTTP the server gets to choose: plain JSON or an SSE stream, call by call. Your client has to handle both. If it only speaks JSON, it'll break the first time the server streams.
Full Explanation
In the Streamable HTTP transport, each JSON-RPC request is its own POST to the MCP endpoint, and the client MUST include an Accept header listing both application/json and text/event-stream. For a request, the server MUST return either Content-Type application/json with a single JSON object or Content-Type text/event-stream with an SSE stream scoped to that request, and the specification states plainly that the client MUST support both. A server choosing SSE for a slow call, often to send progress notifications before the final response, is fully conformant, so the defect is in the client. Requiring application/json from the server reverses the obligation; the choice is the server's, made per request. Opening a GET stream first describes revisions before 2026-07-28; the GET stream endpoint was removed, and a server supporting only this revision answers GET with 405 Method Not Allowed. SSE is not reserved for subscriptions/listen; that request simply produces a long-lived stream, while ordinary requests may also receive request-scoped SSE responses. Exam caveat: closing an SSE response stream is treated as cancellation of that request, so a client that drops the stream mid-call cancels the work. Operational check: send a request the server answers with SSE and confirm the client parses each event, handles any notifications, and completes on the final response.