You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update transports documentation from specification
Updates the transports concept documentation to align with the source of truth specification:
- Replace SSE transport with Streamable HTTP as the primary HTTP-based transport
- Add comprehensive documentation for Streamable HTTP including session management, resumability, and security
- Mark SSE as deprecated with backwards compatibility guidance
- Add security considerations for DNS rebinding attacks
- Include code examples for both TypeScript and Python implementations
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <[email protected]>
asyncwith http_client("http://localhost:8000/mcp") as transport:
253
+
asyncwith ClientSession(transport[0], transport[1]) as session:
254
+
await session.initialize()
255
+
```
149
256
150
-
SSE transports can be vulnerable to DNS rebinding attacks if not properly secured. To prevent this:
257
+
</Tab>
151
258
152
-
1.**Always validate Origin headers** on incoming SSE connections to ensure they come from expected sources
153
-
2.**Avoid binding servers to all network interfaces** (0.0.0.0) when running locally - bind only to localhost (127.0.0.1) instead
154
-
3.**Implement proper authentication** for all SSE connections
259
+
</Tabs>
260
+
261
+
#### Session Management
262
+
263
+
Streamable HTTP supports stateful sessions to maintain context across multiple requests:
264
+
265
+
1.**Session Initialization**: Servers may assign a session ID during initialization by including it in an `Mcp-Session-Id` header
266
+
2.**Session Persistence**: Clients must include the session ID in all subsequent requests using the `Mcp-Session-Id` header
267
+
3.**Session Termination**: Sessions can be explicitly terminated by sending an HTTP DELETE request with the session ID
268
+
269
+
Example session flow:
270
+
271
+
```typescript
272
+
// Server assigns session ID during initialization
273
+
app.post("/mcp", (req, res) => {
274
+
if (req.body.method==="initialize") {
275
+
const sessionId =generateSecureId();
276
+
res.setHeader("Mcp-Session-Id", sessionId);
277
+
// Store session state...
278
+
}
279
+
// Handle request...
280
+
});
281
+
282
+
// Client includes session ID in subsequent requests
283
+
fetch("/mcp", {
284
+
method: "POST",
285
+
headers: {
286
+
"Content-Type": "application/json",
287
+
"Mcp-Session-Id": sessionId
288
+
},
289
+
body: JSON.stringify(request)
290
+
});
291
+
```
292
+
293
+
#### Resumability and Redelivery
294
+
295
+
To support resuming broken connections, Streamable HTTP provides:
296
+
297
+
1.**Event IDs**: Servers can attach unique IDs to SSE events for tracking
298
+
2.**Resume from Last Event**: Clients can resume by sending the `Last-Event-ID` header
299
+
3.**Message Replay**: Servers can replay missed messages from the disconnection point
300
+
301
+
This ensures reliable message delivery even with unstable network connections.
302
+
303
+
#### Security Considerations
304
+
305
+
When implementing Streamable HTTP transport, follow these security best practices:
306
+
307
+
1.**Validate Origin Headers**: Always validate the `Origin` header on all incoming connections to prevent DNS rebinding attacks
308
+
2.**Bind to Localhost**: When running locally, bind only to localhost (127.0.0.1) rather than all network interfaces (0.0.0.0)
309
+
3.**Implement Authentication**: Use proper authentication for all connections
310
+
4.**Use HTTPS**: Always use TLS/HTTPS for production deployments
311
+
5.**Validate Session IDs**: Ensure session IDs are cryptographically secure and properly validated
155
312
156
313
Without these protections, attackers could use DNS rebinding to interact with local MCP servers from remote websites.
157
314
315
+
### Server-Sent Events (SSE) - Deprecated
316
+
317
+
<Note>
318
+
SSE as a standalone transport is deprecated as of protocol version 2024-11-05. It has been replaced by Streamable HTTP, which incorporates SSE as an optional streaming mechanism. For backwards compatibility information, see the [backwards compatibility](#backwards-compatibility) section below.
319
+
</Note>
320
+
321
+
The legacy SSE transport enabled server-to-client streaming with HTTP POST requests for client-to-server communication.
322
+
323
+
Previously used when:
324
+
325
+
- Only server-to-client streaming is needed
326
+
- Working with restricted networks
327
+
- Implementing simple updates
328
+
329
+
#### Legacy Security Considerations
330
+
331
+
The deprecated SSE transport had similar security considerations to Streamable HTTP, particularly regarding DNS rebinding attacks. These same protections should be applied when using SSE streams within the Streamable HTTP transport.
332
+
158
333
<Tabs>
159
334
<Tabtitle="TypeScript (Server)">
160
335
@@ -437,8 +612,8 @@ When implementing transport:
437
612
- Handle denial of service scenarios
438
613
- Monitor for unusual patterns
439
614
- Implement proper firewall rules
440
-
- For SSE transports, validate Origin headers to prevent DNS rebinding attacks
441
-
- For local SSE servers, bind only to localhost (127.0.0.1) instead of all interfaces (0.0.0.0)
615
+
- For HTTP-based transports (including Streamable HTTP), validate Origin headers to prevent DNS rebinding attacks
616
+
- For local servers, bind only to localhost (127.0.0.1) instead of all interfaces (0.0.0.0)
442
617
443
618
## Debugging Transport
444
619
@@ -454,3 +629,63 @@ Tips for debugging transport issues:
454
629
8. Monitor resource usage
455
630
9. Test edge cases
456
631
10. Use proper error tracking
632
+
633
+
## Backwards Compatibility
634
+
635
+
To maintain compatibility between different protocol versions:
636
+
637
+
### For Servers Supporting Older Clients
638
+
639
+
Servers wanting to support clients using the deprecated HTTP+SSE transport should:
640
+
641
+
1. Host both the old SSE and POST endpoints alongside the new MCP endpoint
642
+
2. Handle initialization requests on both endpoints
643
+
3. Maintain separate handling logic for each transport type
644
+
645
+
### For Clients Supporting Older Servers
646
+
647
+
Clients wanting to support servers using the deprecated transport should:
648
+
649
+
1. Accept server URLs that may use either transport
650
+
2. Attempt to POST an `InitializeRequest` with proper `Accept` headers:
651
+
- If successful, use Streamable HTTP transport
652
+
- If it fails with 4xx status, fall back to legacy SSE transport
653
+
3. Issue a GET request expecting an SSE stream with `endpoint` event for legacy servers
0 commit comments