Practical MCP with FastMCP & LangChain

The Standard MCP Communication Protocol

The MCP communication protocol is built on top of JSON-RPC 2.0. This means that every message exchanged between the client and the server is a JSON object that follows the JSON-RPC 2.0 structure.

JSON-RPC is a lightweight remote procedure call protocol encoded in JSON. It defines how requests and responses must be structured, how methods are invoked, how results are returned, and how errors are reported.

MCP does not replace JSON-RPC. Instead, it uses it as the transport format and defines its own set of methods and message types on top of it. In other words:

• JSON-RPC defines the message envelope.
• MCP defines the meaning of the messages inside that envelope.

One of the key advantages of using JSON-RPC as the underlying protocol for MCP is that it abstracts away the programming language. If your MCP server is implemented in Python and your Host application is implemented in JavaScript, they can still communicate perfectly as long as they both understand JSON-RPC.

Another advantage is that it abstracts away the underlying transport protocol. Whether the client and server communicate over STDIO, HTTP, WebSockets, or any other protocol, they can still use the same JSON-RPC message format. This makes MCP flexible and adaptable to different use cases.

In the context of MCP, there are 2 main transport protocols that are commonly used:

• Streamable HTTP
• STDIO

Streamable HTTP Transport

Streamable HTTP is the standard remote transport mechanism of MCP. It replaced the older HTTP+SSE transport, where SSE was a permanent, always-on connection. In Streamable HTTP, SSE is still used — but only optionally, when the server decides streaming is useful for a specific response.

SSE (Server-Sent Events) is a web technology that allows a server to push real-time updates to a client over a single, persistent HTTP connection.

In this transport:

• The client sends JSON-RPC messages using HTTP POST requests to a single MCP endpoint. The client must indicate via an Accept header that it supports both application/json and text/event-stream responses.

• The server decides how to respond:

• For simple operations, it returns a standard application/json response immediately.
• For operations that benefit from streaming (e.g., long-running tasks or progress updates), it responds with a text/event-stream (SSE) instead. This allows the server to send multiple JSON-RPC messages — including progress notifications — over time on that same connection.

The client can also open a persistent SSE stream proactively by sending an HTTP GET request to the same endpoint. This allows the server to push messages at any time, without waiting for a client POST first. This is useful for server-initiated notifications and real-time updates.

Streamable HTTP is designed for remote servers, cloud-hosted services, and AI agents. It supports both stateless interactions and long-running operations.

Example: if a client calls a tool to analyze a 2GB dataset, the server does not have to block for 20 seconds and return everything at once. Instead, it can switch the response to an SSE stream and send progress notifications (e.g., 10%, 50%, 90%) as the analysis progresses, followed by the final result.

Here is how the client would see the stream of messages:

# First notification
event: message
data: {"jsonrpc":"2.0","method"