SSE vs WebSocket for Agent Readiness: Why Server-Sent Events Are the Agent-Preferred Transport
MCP uses Server-Sent Events (SSE) as its primary transport protocol — not WebSocket. This was not an arbitrary choice. SSE is HTTP-native, works through every proxy and CDN, auto-reconnects on failure, and uses standard HTTP authentication. For agent readiness, the transport you choose directly impacts your D2 API Quality and D8 Reliability scores.
Why Transport Protocol Matters for Agent Readiness
When an AI agent connects to your MCP server, it needs a persistent channel to receive tool responses, streaming results, and progress updates. The transport protocol determines how reliable, compatible, and secure that channel is. A protocol that drops connections behind corporate proxies, requires custom authentication schemes, or needs manual reconnection logic directly lowers your agent readiness.
The two main contenders are Server-Sent Events (SSE) and WebSocket. Both support real-time server-to-client data. But they differ fundamentally in how they integrate with HTTP infrastructure, and those differences determine how well agents can connect to your service in the real world.
SSE vs WebSocket: Head-to-Head Comparison
Eight dimensions where the two transport protocols differ, and what each means for agent connectivity.
Bottom line for agent readiness: SSE wins on six of eight dimensions for agent communication. WebSocket's advantage — full duplex — is unnecessary for the MCP request/response pattern. Agents send requests via POST and receive responses via SSE. Bidirectional streaming on a single connection adds complexity without adding value for this use case.
How MCP Uses SSE in Practice
The MCP protocol uses a split transport model: HTTP POST for agent-to-server requests and SSE for server-to-agent responses. This gives you the simplicity of REST for sending commands with the real-time streaming of SSE for receiving results.
Agent Sends Request
The agent sends a standard HTTP POST to the MCP server with the method name and parameters as JSON. This is a regular REST-like request — no special protocol needed.
Server Pushes Response via SSE
The server responds on the SSE channel using text/event-stream. Each event has an ID, type, and JSON data payload. Long-running operations can stream progress updates before the final result.
Auto-Reconnect on Failure
If the connection drops, the SSE client automatically reconnects and sends the Last-Event-ID header. The server resumes from where it left off — no agent logic required for recovery.
This architecture means your MCP server is just an HTTP server with one SSE endpoint. No WebSocket upgrade handling, no custom protocol parsing, no connection state management beyond what SSE handles automatically. Every web framework supports this out of the box. Express, Next.js, FastAPI, Go net/http, Ruby on Rails — all can serve SSE without additional dependencies.
How Transport Choice Affects Your Score
AgentHermes checks for SSE support when scanning MCP endpoints. The transport protocol impacts three scoring dimensions directly.
D2 API Quality
SSE on MCP endpoints signals agent-native infrastructure. Proper text/event-stream content type, event IDs, and JSON data formatting all contribute to API quality scoring.
D8 Reliability
Auto-reconnect with Last-Event-ID means agents recover from network interruptions without data loss. This directly improves reliability scoring compared to WebSocket, which requires manual reconnect logic.
D7 Security
Standard HTTP auth headers on every SSE request means existing security infrastructure (API gateways, rate limiters, WAFs) works without modification. WebSocket auth-at-connect-time only creates a larger attack window.
Combined, these three dimensions represent 40% of the total agent readiness score. Choosing SSE for your MCP transport does not guarantee a high score — you still need good API design, documentation, and agent-native files. But choosing the wrong transport creates a reliability and compatibility ceiling that caps your score regardless of how good your tools are.
When WebSocket Still Makes Sense
WebSocket is not wrong — it is wrong for agent communication specifically. There are legitimate use cases where WebSocket remains the better choice.
Real-time collaboration
Google Docs, Figma, and multiplayer games need true bidirectional streaming where both client and server push data continuously. SSE cannot handle this pattern efficiently.
High-frequency data
Trading platforms, live sports scores, and IoT sensor feeds pushing hundreds of messages per second benefit from the lower overhead of WebSocket binary frames versus SSE text encoding.
Chat and messaging
Human-to-human chat applications where both sides type simultaneously benefit from full duplex. The typing indicator and message sending happen in parallel on both directions.
Binary streaming
Audio/video streaming, file transfers, and screen sharing need binary data transmission. SSE is text-only (you would need Base64 encoding, adding 33% overhead for binary payloads).
The pattern is clear: WebSocket wins when humans interact in real-time or when binary data flows in both directions. SSE wins when machines send requests and receive structured responses — which is exactly what AI agents do. Use both where appropriate. Just ensure your MCP endpoint uses SSE.
Adding SSE Support for Agent Readiness
If you already have webhook infrastructure, adding SSE is straightforward. The key requirements for an agent-compatible SSE endpoint:
Content-Type: text/event-stream
The response must set this header. Without it, clients and intermediaries cannot identify the stream as SSE and may buffer or close the connection.
Event ID on every message
Each SSE event should include an id: field with a monotonically increasing value. This enables Last-Event-ID reconnection — the single most important reliability feature for agent communication.
JSON data payloads
Each data: line should contain valid JSON that the agent can parse. MCP defines specific JSON-RPC 2.0 message formats for tool calls, resource reads, and error responses.
Keep-alive comments
Send SSE comments (lines starting with :) every 15-30 seconds to prevent proxy timeouts. Most HTTP proxies close idle connections after 60 seconds. Keep-alive comments prevent this.
CORS headers for browser-based agents
If agents connect from browser environments, include Access-Control-Allow-Origin and Access-Control-Allow-Headers. SSE uses standard HTTP, so standard CORS configuration applies.
Frequently Asked Questions
Why did MCP choose SSE instead of WebSocket?
MCP chose SSE because agent-to-server communication is fundamentally asymmetric. Agents send discrete requests (call a tool, read a resource) and servers stream back responses. SSE handles the server-to-agent direction natively over HTTP, and regular POST handles the agent-to-server direction. This avoids the complexity of WebSocket while working through every HTTP proxy, CDN, and firewall without special configuration.
Does AgentHermes check for SSE support?
Yes. When AgentHermes scans an MCP endpoint, it checks for text/event-stream content type, proper SSE event formatting, and Last-Event-ID support for reconnection. SSE support on MCP endpoints contributes to D2 API Quality and D8 Reliability scores. Endpoints that only offer WebSocket score lower because agent compatibility is reduced.
Should I remove my WebSocket endpoints?
No. WebSocket is still valuable for human-facing features like live chat, collaborative editing, and gaming. The recommendation is to add SSE support for agent-facing interfaces — specifically MCP endpoints. Your existing WebSocket infrastructure can continue serving its current purpose. Just ensure your agent integration layer uses SSE so every MCP-compatible agent can connect.
What about HTTP streaming (chunked transfer)?
Chunked transfer encoding sends data in pieces but has no built-in event structure, reconnection, or event IDs. SSE adds all of these on top of HTTP streaming. For agent communication, raw chunked transfer is insufficient — you need the event framing and reconnection semantics that SSE provides. MCP specifically requires SSE formatting, not raw chunked transfer.
Can I use both SSE and WebSocket on the same server?
Absolutely. Many production services expose WebSocket for real-time human interfaces and SSE for agent/MCP interfaces on the same server. The key is that your MCP endpoint specifically must support SSE transport. Agents will connect via SSE. Human users can continue using WebSocket for features that benefit from bidirectional communication.
Check if your endpoints are agent-ready
AgentHermes scans your MCP endpoints for SSE support, proper event formatting, and reconnection capability. See your score across all 9 dimensions in 60 seconds.