MCP servers typically communicate in one of two ways. Understanding the nuances of these methods is key to appreciating both the protocol's power and its potential fingerprint. The choice of transport shapes the entire interaction between an AI and a tool, defining how "chatty" a tool can be and how the AI perceives its work.

HTTP Request

The first method, and the foundation of the web, is the classic HTTP request. The client (the AI) crafts a request, packages it up with headers and a body (the JSON-RPC payload), and sends it to the server. The server receives the request, does its work, and sends a single, self-contained response back. The conversation is then over. 

This stateless, transactional nature is its greatest strength and weakness. It's incredibly simple and scalable. The server doesn't need to remember anything about the client from one request to the next. For simple, quick tool calls, this is perfect. If an AI needs to know the current price of a stock, a simple HTTP POST request to an MCP server's /messages endpoint is the clean, efficient way to do it. The tool gets the price, returns it, and the connection closes.

Server-Sent Events

The second method is Server-Sent Events (SSE). If a standard HTTP request is a letter, SSE is a live phone call where only one person, the server, is allowed to talk. The client "dials" the server by making an initial HTTP GET request, but this time it includes a crucial header: Accept: text/event-stream. This is the magic phrase that tells the server, "I'm not here for a quick chat; I'm here to listen, so keep the line open."

The server, upon seeing this header, agrees to establish a persistent, unidirectional connection. It can then push a continuous stream of updates to the client over that single, long-lived HTTP connection. Each message in the stream is a simple, standardized text block. The data: field contains the actual message payload (usually a JSON object), and optional fields like event: can be used to label the type of message being sent.

Imagine you ask an AI to book a multi-leg international trip. A tool using SSE can provide a rich, real-time "thought process" back to the AI:

event: tool_started
data: {"tool": "travel_agent", "status": "Initiating travel booking..."}

event: progress_update
data: {"status": "Searching for flights from LHR to HND..."}

event: progress_update
data: {"status": "Found 3 flights, filtering for business class..."}

event: partial_result
data: {"type": "flight", "details": {"airline": "JAL", "flight_no": "JL44", "price": 4500}}

event: progress_update
data: {"status": "Searching for hotels in Tokyo for selected dates..."}

event: tool_finished
data: {"summary": "Flight JL44 found. Ready to search for hotels."}

This fundamentally changes the user experience and the AI's capabilities. It allows for transparency, showing the user (and the AI) that work is being done. It enables the AI to react to intermediate results without waiting for the entire process to finish. It's this real-time, push-based communication that makes complex, multi-step AI agent interactions feel seamless and intelligent. 

New to the series? Start with the foundations in What is a 'Model Context Protocol' Server in GenAI 

Ready for more? Discover the four best ways to lock down traffic patterns: 4 Best Strategies to Secure Model Context Protocol