Anthropic has introduced the Model Context Protocol (MCP), aimed at standardizing the communication between large language models (LLMs) and the “external world” to enhance their capabilities through tool/function support. The idea is that if we can simplify this integration, we can focus on powerful tools rather than custom integration code. MCP is thriving, with new MCP servers emerging every hour, and even Anthropic’s competitor OpenAI has started adopting MCP.

Recently (March 2025), based on community feedback, MCP updated its specifications, adding an authorization framework, replacing HTTP+SSE transmission with Streamable HTTP, and introducing tool annotations for behavior description, as well as support for JSON-RPC batching.

◆Communicating with MCP Servers

MCP servers can be deployed to provide tools/resources/prompts and can be queried through two main transmission methods:

• Standard Input/Output (stdio)
• HTTP+SSE

I believe that in “real-world scenarios,” you are likely to communicate with MCP servers via some remote transmission method (like HTTP), but using SSE (Server-Sent Events) can be somewhat inconvenient. Let’s see why.

◆HTTP + SSE

SSE (Server-Sent Events) is a mechanism that allows servers to send events to clients. It is a unidirectional communication method. Here’s how it works in MCP:

• The client connects to the server at the “http://example.com/sse” endpoint
• The server responds with an “endpoint event,” informing the client of the URI for sending messages (e.g., http://example.com/messages)
• The client uses this URI to communicate with the server
• The server communicates with the client through streaming events/messages

On the server side, you will have these API endpoints: /sse and /messages.

This method has some limitations. First, it requires maintaining two separate connections and endpoints:

• Requires maintaining two separate connections/endpoints
• Requires persistent connections, making stateless implementations difficult
• Limited compatibility with certain infrastructures and middleware
• Cannot recover connections in the event of network issues. This poses challenges for remote MCP servers that need to be accessed over the internet, as connection interruptions may occur.

◆MCP Changes: Streamable HTTP

MCP has introduced Streamable HTTP in its recent update for remote servers. Simply put, this means we no longer need to use two separate endpoints as described above. Clients can stream responses directly from the /messages endpoint. The server can decide whether to return a streamable response or a standard HTTP response. If the server decides to return a streamable response (for example, not necessarily at the first response, but in subsequent stages of the connection), it can send notifications.

The advantages of this design include:

• Simple HTTP implementation: MCP can now be implemented in regular HTTP servers without needing separate support for SSE, simplifying server implementation
• Better infrastructure compatibility: As “regular HTTP,” it ensures compatibility with standard middleware and infrastructure
• Flexible implementation options: Supports both stateless and stateful server implementations
• Simplified client architecture: Removed the need for the MCP client to send messages to endpoints other than the initial connection; this makes it easier for “non-developers” to understand

When implemented on the server side, we will have a single /messages endpoint that can return either standard HTTP responses or streamable responses.

It is similar to HTTP+SSE but more simplified. Let’s finally compare:

In the previous HTTP+SSE transmission:

• The client would connect to a dedicated /sse endpoint to receive messages from the server.
• The server would immediately send an “endpoint event” to inform the client of the URL for sending messages.
• It required maintaining two separate connections: one for server→client (SSE) and one for client→server (HTTP POST).

In the new Streamable HTTP transmission:

• There is only one endpoint (usually /message).
• Any request from the client can receive a standard HTTP response or upgrade to an SSE stream.
• The upgrade is dynamic, based on the server’s needs in a specific interaction.
• The client initiates the connection through a standard HTTP request, and the server decides whether to make it “streamable.”

This is a significant architectural improvement because:

• It simplifies the protocol by using a single connection point.
• It allows the server to be more flexible between using streaming and one-time responses.
• It can achieve a fully stateless server implementation when appropriate (which was not possible before).
• It is closer to the standard HTTP model, making it easier to implement and deploy.

Source:

https://www.toutiao.com/article/7527098629430067721/?log_from=c81addb9dc477_1757296292792

“Open Source Experts” welcomes contributions from technical personnel. Submission email: [email protected]

Since you’re here, why not leave a comment~

Open Source Experts | About Copyright

Article originally by “Open Source Experts (ID: kaiyuandakashuo)”, please indicate the author, source, and WeChat public account when reprinting.For submissions, requests, or reprints, please add WeChat: ITDKS10 (note: submission), and Miss Jasmine will contact you promptly!

Thank you for your enthusiastic support of Open Source Experts!

Related Recommendations

Recommended Articles

• A minimalist lightweight component-based web framework built on SpringBoot3

• A free data visualization analysis platform to create any data dashboard you want

• 2025CSDI: Large models leading intelligent R&D and IT organizational transformation

• A 100% open-source, commercially supported Amazon ERP system with no user limits

• Short link generation, subdomain hosting, unlimited email service domain service (SaaS) platform

• API documentation solution aimed at making API documentation management more convenient and efficient

• Authelia: A powerful 2FA and SSO authentication server

• A traceability anti-counterfeiting system, a one-code-one-item system for commercial-grade traceability and anti-diversion

• A lightweight generative SQL Java framework based on advanced generative large models from home and abroad