[v0.9 → v1.0 Migration] streamable_http transport returns 405 on /mcp endpoint

[ahujayogesh2003-maker]

After migrating from v0.9 to v1.0 (RC1), our MCP tool calls are failing when using streamable_http as the transport. We are getting:

ExceptionGroup('unhandled errors in a TaskGroup', [HTTPStatusError("Client error '405 Method Not Allowed' for url '.../servers/{id}/mcp'")])

Here's the code that worked fine on v0.9 but fails on v1.0:

client = MultiServerMCPClient(
    {
        "gateway": {
            "transport": "streamable_http",
            "url": f"{mcpgw_url}/servers/{mcp_virtual_server}/mcp",
            "headers": {"Authorization": f"Bearer {mcpgw_token}"},
        }
    }
)
tools = await client.get_tools()

We believe the issue is that langchain_mcp_adapters sends a GET request to /mcp first when using streamable_http, and the v1.0 gateway now rejects it with 405.

When we switch to sse transport, it does work, but we are getting a flood of Pydantic validation warnings:

Failed to validate notification: Input should be 'notifications/cancelled' 
[type=literal_error, input_value='notifications/initialized']

Two questions:

1. Is streamable_http transport still supported in v1.0? If so, what is the correct configuration?
2. Are the notifications/initialized Pydantic validation warnings expected with sse transport, or is there a version of langchain-mcp-adapters / mcp SDK that handles them cleanly?

[crivetimihai]

Hi @ahujayogesh2003-maker, thanks for the detailed report.

1. Yes, streamable_http is fully supported in v1.0. In fact, the default Docker Compose configuration sets TRANSPORT_TYPE=streamablehttp.

The 405 you're seeing is most likely caused by langchain_mcp_adapters not sending the required Accept header. In v1.0, the streamable HTTP transport (per the MCP spec) requires:

• POST requests must include Accept: application/json (or Accept: text/event-stream for streaming responses)
• GET requests must include Accept: text/event-stream (for SSE-based session streaming)
• DELETE requests are used for explicit session termination

If a request arrives without a proper Accept header, the gateway returns 406 Not Acceptable (not 405). A true 405 would mean the HTTP method itself isn't routed — which could happen if langchain_mcp_adapters is sending a request to a path without the trailing slash. The gateway redirects /servers/{id}/mcp to /servers/{id}/mcp/ (307), and some HTTP clients don't follow redirects on POST requests, which can surface as unexpected errors.

I verified this against a running v1.0 instance:

POST /servers/{id}/mcp  with Accept: application/json  → 200 ✅
GET  /servers/{id}/mcp  with Accept: text/event-stream  → 200 ✅
GET  /servers/{id}/mcp  without Accept header             → 406

Recommended fix:

client = MultiServerMCPClient(
    {
        "gateway": {
            "transport": "streamable_http",
            "url": f"{mcpgw_url}/servers/{mcp_virtual_server}/mcp",
            "headers": {
                "Authorization": f"Bearer {mcpgw_token}",
                "Accept": "application/json, text/event-stream",
            },
        }
    }
)

Also ensure your langchain-mcp-adapters and mcp SDK are updated to the latest versions, as earlier versions may not properly negotiate the streamable HTTP protocol.

2. The notifications/initialized Pydantic warnings are a known issue in older versions of the mcp Python SDK. The SDK's JSONRPCMessage validator was strict about notification method names and didn't recognize notifications/initialized. This has been fixed in recent SDK releases. Upgrading to mcp >= 1.26.0 should resolve these warnings. They're cosmetic and don't affect functionality.

If issues persist after these changes, please share the exact versions of langchain-mcp-adapters and mcp SDK you're using and I can investigate further.

[ahujayogesh2003-maker]

@crivetimihai , Thank you for the detailed response. I tried both suggested fixes — adding the Accept header and testing with and without the trailing slash — but I am still getting 405 Method Not Allowed.
Error:
ExceptionGroup('unhandled errors in a TaskGroup', [HTTPStatusError("Client error
'405 Method Not Allowed' for url
'http://mcpgw.cs-energyhub.com/servers/fe3bb35efa9c403896d5501fde6b5f63/mcp/'")])

Code used:

pythonclient = MultiServerMCPClient(
    {
        "gateway": {
            "transport": "streamable_http",
            "url": f"{mcpgw_url}/servers/{mcp_virtual_server}/mcp/",
            "headers": {
                "Authorization": f"Bearer {mcpgw_token}",
                "Accept": "application/json, text/event-stream",
            },
        }
    }
)

Package versions (latest):

langchain-mcp-adapters==0.2.1
mcp==1.26.0

Our gateway configuration:

1. Deployed on EKS as a single pod (no horizontal scaling, no multiple replicas)
2. CACHE_TYPE=database (PostgreSQL, no Redis)
3. MCPGATEWAY_SESSION_AFFINITY_ENABLED=false
4. USE_STATEFUL_SESSIONS=false

We noticed that v1.0 Beta and RC1 introduced session persistence and session affinity support, which requires additional configuration including Redis. However, in our deployment we are running a single pod on EKS with MCPGATEWAY_SESSION_AFFINITY_ENABLED=false, USE_STATEFUL_SESSIONS=false, and CACHE_TYPE=database (PostgreSQL, no Redis). I hope this configuration is not cause of this issue

[omni-front]

for the 405 error, make sure your server endpoint supports the method you're trying to use with streamable_http. might need to check server-side config. as for the sse transport, those Pydantic warnings suggest a mismatch in expected event types. i'd check the versions of langchain-mcp-adapters and the SDK to ensure compatibility.

[crivetimihai]

Hi @ahujayogesh2003-maker, thanks for confirming the fix didn't work. After investigating both the code and the running instance, I have a strong hypothesis.

Root cause: TRANSPORT_TYPE configuration mismatch after migration.

The response header allow: GET is the key clue. It means the SSE transport handler is catching your request, not the streamable HTTP handler. The SSE handler only accepts GET (for SSE event streams), so it rejects POST with 405.

In v1.0, the Docker Compose default changed to TRANSPORT_TYPE=streamablehttp. If your deployment carried over a v0.9 config with TRANSPORT_TYPE=sse (or left it unset, inheriting a different default), the streamable HTTP handler is simply not mounted — and POST requests to /servers/{id}/mcp hit the SSE handler instead.

Fix: Set your environment variable:

TRANSPORT_TYPE=streamablehttp    # For streamable HTTP only
# or
TRANSPORT_TYPE=all               # For both SSE and streamable HTTP

I verified against the current codebase that with TRANSPORT_TYPE=streamablehttp, POST to /servers/{id}/mcp (both with and without trailing slash) returns 200 with a valid JSON-RPC response.

For the Pydantic validation warnings with SSE transport:

The notifications/initialized warnings are a version mismatch between langchain-mcp-adapters and the MCP SDK. The MCP 2025-03-26 spec uses notifications/initialized but older Pydantic models only accept notifications/cancelled. Updating mcp SDK to >= 1.8.0 should resolve these.

This issue is tracked as #3559. Could you confirm your TRANSPORT_TYPE setting? That would help us verify this is the root cause.

[ahujayogesh2003-maker]

Hi @crivetimihai
Thank you for your response . For our set up ,
TRANSPORT_TYPE: all
Please let me know if we should update this value to streamablehttp

[crivetimihai]

Hi @ahujayogesh2003-maker,

TRANSPORT_TYPE=all is fine — you do not need to change it to streamablehttp. When set to all, both SSE and streamable HTTP are enabled simultaneously on completely separate code paths, so they don't conflict:

• Streamable HTTP: POST /servers/{server_id}/mcp → rewritten internally by MCPPathRewriteMiddleware to /mcp/ → handled by the streamable HTTP ASGI app
• SSE: GET /servers/{server_id}/sse → handled by the SSE endpoint

Since the 405 persists with TRANSPORT_TYPE=all, the issue is elsewhere. Most likely causes:

1. Client library not sending required headers. The streamable HTTP transport requires Accept: application/json or Accept: text/event-stream on POST. Can you verify what langchain_mcp_adapters is sending? Quick test:

   curl -X POST "https://your-gateway/servers/{server_id}/mcp" \
     -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json" \
     -H "Accept: application/json" \
     -d '{ "jsonrpc": "2.0", "method": "initialize", "id": 1, "params": { "protocolVersion": "2025-03-26", "capabilities": {}, "clientInfo": { "name": "test", "version": "1.0" } } }' 

2. Reverse proxy or load balancer in front of the gateway stripping headers or blocking POST to /servers/*/mcp.

3. langchain_mcp_adapters version — older releases may not fully support the streamable HTTP spec.

Could you share the full response headers from the 405? That will help narrow it down.

[itxashancode]

The 405 issue is almost certainly a routing problem, not a config problem. Here's what I'd check:

Your client uses transport: "streamable_http" but the server config key is TRANSPORT_TYPE=streamablehttp (no underscore). That's a potential mismatch right there. More likely though - with TRANSPORT_TYPE=all, the server exposes streamable HTTP on /servers/{id}/mcp but it's a POST-only endpoint. If langchain_mcp_adapters is sending GET first (which it does for some versions), you get 405. The fix is usually to ensure your client library version matches what the server expects, or explicitly set transport: "streamablehttp" (no underscore) in your client config.