By the Knostic Research Team
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.
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. Job done.
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.
Read more about how attackers can use this information to find MCP servers on the Internet here.
Understanding traffic patterns is only half the battle. Discover the four best ways to lock them down in “4 Best Strategies to Secure Model Context Protocol.”
New to the series? Start with the foundations in What is a 'Model Context Protocol' Server in GenAI, then learn to uncover live instances in How to Find an MCP Server with Shodan.
Tags:
research findings
