Problem
MCPToolProvider in both trees supports only stdio and sse transports. HTTP+SSE is the legacy transport, deprecated in the MCP spec since 2025-03-26. Streamable HTTP is the current standard HTTP transport, and everything in the new 2026-07-28 spec revision (stateless core, routing headers, caching) lands on it. Today we cannot connect to a Streamable HTTP MCP server at all — our own examples/mcp-shop-server speaks it and can only be consumed from Swift.
Proposal
Add a new accepted value "streamable-http" for MCPServerConfig.type, reusing the existing url and headers fields. No new fields, no changes to "stdio" / "sse".
- TypeScript: lazy-import
StreamableHTTPClientTransport from @modelcontextprotocol/sdk/client/streamableHttp.js — already available in the v1 SDK we target.
- Python: lazy-import
streamablehttp_client from mcp.client.streamable_http — already available in mcp 1.x.
- Tests mirroring the existing SSE transport tests in both trees.
- Docs: add the transport to the mcp-tool-provider page (TS + Python examples), note that SSE remains supported for legacy servers.
Fully additive: existing configurations behave exactly as before.
Prerequisite for 2026-07-28 protocol support (separate issues).
Problem
MCPToolProviderin both trees supports onlystdioandssetransports. HTTP+SSE is the legacy transport, deprecated in the MCP spec since 2025-03-26. Streamable HTTP is the current standard HTTP transport, and everything in the new 2026-07-28 spec revision (stateless core, routing headers, caching) lands on it. Today we cannot connect to a Streamable HTTP MCP server at all — our ownexamples/mcp-shop-serverspeaks it and can only be consumed from Swift.Proposal
Add a new accepted value
"streamable-http"forMCPServerConfig.type, reusing the existingurlandheadersfields. No new fields, no changes to"stdio"/"sse".StreamableHTTPClientTransportfrom@modelcontextprotocol/sdk/client/streamableHttp.js— already available in the v1 SDK we target.streamablehttp_clientfrommcp.client.streamable_http— already available in mcp 1.x.Fully additive: existing configurations behave exactly as before.
Prerequisite for 2026-07-28 protocol support (separate issues).