Repository navigation
Inconsistency between [Transports: Backwards Compatibility] and SDKs #1519
Description
Describe the bug
Spec explains under Transports: Backwards Compatibility that clients wanting to support older servers (i.e. using HTTP+SSE transport) should attempt to connect to a remote MCP server assuming the Streaming HTTP transport (via POST request), and if that fails with a response code of 4xx, then try the HTTP+SSE transport path (via GET request).
The client implementations in the various SDKs seem to expect status code 405 specifically in response to a GET request when SSE is not supported (see example from TypeScript SDK). The client SDKs may also be following an SSE-first approach instead of trying the Streamable HTTP transport type first.
To Reproduce
Discovered this in a client using the Kotlin SDK working against an MCP server that was returning a 400 status code for GET requests to the /mcp endpoint.
Steps to reproduce the behavior:
- Create an MCP server that 400s for GET requests to the MCP endpoint, but does support Streamable HTTP
- Use one of the SDK's client implementations to connect to the MCP server
Expected behavior
Client connects to MCP server via Streamable HTTP and POST request(s).
OR perhaps the phrasing of the specification can be revised.
OR this subtlety in the relationship between Streamable HTTP and HTTP+SSE came in a revision that is not yet reflected in the SDKs.
Activity
jonathanhefner commentedon Oct 2, 2025
Git indicates that currently defined behavior has been in place since the introduction of Streamable HTTP.
My understanding of the spec: HTTP+SSE-only servers should reject the
initializePOST if the client has not first opened an SSE connection (and received anendpointevent) per the HTTP+SSE diagram. Based on that rejection, the client determines whether it should fall back to HTTP+SSE or continue with Streamable HTTP.Spec phrasing aside, I don't think the behavior is underspecified, but I might be misunderstanding.
Perhaps some servers are overly permissive, making the determination mechanism unreliable, leading to the current SDK behavior? Would you mind opening an issue in the affected SDK repositories to ascertain the cause?
nathan-williams commentedon Oct 8, 2025
Thanks for the reply @jonathanhefner. I could have been less verbose in my original post.
I think you're right that the issue is likely better taken up in the SDK repos. Agreed that the spec is clear about the expected behavior.