STDIO vs SSE in MCP Servers

Contenido del curso

Introducción a MCP

Conceptos basicos de MCP

MCP avanzado

Integrando tu MCP con un agente

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:005:44

STDIO vs SSE in MCP Servers

Curso de MCP con Microsoft Azure

Clase 8 de 22

Clase 8 / 22

Recursos

Switching from STDIO to Server-Sent Events (SSE) in your MCP server changes how data flows between client and server, making your agent faster and lighter without altering its behavior. If you are building MCP tools and want streaming over HTTP, this is the connection type you need to know.

What is SSE and why does it matter for MCP?

SSE stands for Server-Sent Events, and it is the transport that lets your MCP server push information to the client over HTTP in a continuous, lightweight stream.

Until now, the default transport in most MCP examples has been STDIO, which works fine for local processes but is not ideal when you need constant, efficient communication. SSE solves that by enabling streaming, similar to how Netflix delivers a movie in chunks instead of forcing you to download the full file before watching.

What is SSE in MCP? It is a transport that streams data from server to client over HTTP, making the exchange faster and lighter than STDIO.

The practical impact is real: as a conversation grows, an agent tends to slow down because it carries more context. With SSE, that context flows in parts, keeping the interaction responsive.

How do you set up an SSE server with FastMCP and Starlette?

The setup relies on three imports working together: Starlette applications, Starlette routing, and the usual MCP import you already use. Starlette is the lightweight ASGI framework that handles the HTTP layer where SSE lives.

Here is the flow shown in the demo:

Create a folder named clase7 and inside it a file called server.py.
Add the three imports: Starlette applications, Starlette routing, and MCP.
Initialize the server using FastMCP, naming it sse de Platzi to distinguish it from previous servers.
Define the same tool used before, a function that sums two integers.
Enable the SSE layer in the middle section of the file, which exposes the app over HTTP.

The tool itself does not change. What changes is the wrapper that publishes it through an SSE endpoint instead of standard input/output.

How do you run the server with Uvicorn?

Once the file is ready, you launch it with Uvicorn, an ASGI server inside Python used to deploy applications [02:00]. From the clase7 folder you run uvicorn server:app, which boots the app on port 8000 by default.

This is a different way of starting an MCP server compared to running it directly, but it is the practical path when you want HTTP streaming.

How do you connect the MCP Inspector to an SSE endpoint?

With the server running on port 8000, open a new terminal so you do not kill the process, and launch the inspector with the usual npx command pointing to mcp run server.py [02:30]. The inspector opens with a control-click on the URL it prints.

Inside the inspector, locate the transport type selector. By default it shows STDIO, the option used in earlier exercises. Change it to SSE and enter the URL:

Transport: SSE.
URL: http://localhost:8000/sse.
Action: press Connect.

That is the only visible difference in the inspector. Everything else, including how you call tools, stays identical.

What URL do you use for an SSE MCP server? Use http://localhost:8000/sse, where 8000 is the port Uvicorn exposes and /sse is the streaming endpoint.

How do you test the tool over SSE?

Once connected, go to Tools in the inspector, pick the add function, and pass two integers. In the demo, passing 25 and 25 returns 50, the same result you would get over STDIO.

Visually there is no difference, and that is the point. SSE optimizes the channel underneath without forcing you to rewrite your tools.

Does SSE change how MCP tools behave? No. Tools return the same results. SSE only makes the transport between client and server lighter and continuous.

When should you choose SSE over STDIO in a real project?

STDIO is convenient for local experiments and quick prototypes. SSE shines when your agent runs over the network, when conversations are long, or when latency starts to hurt the experience.

Think of it this way: with STDIO, every exchange feels like sending a full package. With SSE, the server delivers information in parts, the same way a streaming platform sends video frames as they are needed. That makes the agent feel faster as context accumulates, and it reduces the cost of processing everything in one shot.

Key takeaways from the implementation:

FastMCP still hosts your tools, no rewrite needed.
Starlette provides the HTTP layer for the SSE endpoint.
Uvicorn runs the ASGI app on a chosen port, typically 8000.
The MCP Inspector lets you switch transport type to SSE and connect via URL.

If you are scaling an MCP agent toward production, moving from STDIO to SSE is one of the simplest changes with the highest payoff in responsiveness.

Have you already migrated one of your MCP servers to SSE? Share in the comments which port and framework you are using.

William Schnaider Torres Bermon

Hace un año

SSE (Server Sent Events) is a standard for server-to-client streaming, allowing servers to push real-time updates to clients over HTTP. This is particularly useful for applications that require live updates, such as chat applications, notifications, or real-time data feeds. Also, your server can be used by multiple clients at the same time as it lives on a server that can be run somewhere in the cloud for example.

from starlette.applications import Starlette
from starlette.routing import Mount, Host
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("My App")

@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers"""
    return a + b

# Mount the SSE server to the existing ASGI server
app = Starlette(
    routes=[
        Mount('/', app=mcp.sse_app()),
    ]
)

In the preceding code we:

Imported the libraries we're going to need with Starlette (an ASGI framework) being pulled in.
Create an instance of an ASGI server (using Starletter specifically) and mount the default route /

What happens behind the scenes is that the routes /sse and /messages are setup to handle connections and messages respectively. The rest of the app, like adding features like tools, happens like with stdio servers.

Comentarios (14)14 comentarios

David Herrera

sebastián García

Carlos Enrique Ramírez Flores

Favio Náquira

Gerardo Matias Ferreira

Cristian Pisco Intriago

Diego del Cid

Hace 15 días•editado

Tomas Dale

Hace 2 meses•editado

Nery Alberto Cano Ortigoza

Hace 6 meses

Juan Sebastian Ramirez Leyva

Hace 7 meses

andres reyes

Kevin Guzman

Kevin Fiorentino

Jair Israel Avilés Eusebio

Introducción a MCP

Introducción a MCP

MCP Core Architecture: Server, Client, and Host

MCP Dev Environment Setup for Python

MCP Server Setup With Python and Inspector

Conceptos basicos de MCP

Four Core Blocks of Every MCP Server

Building an MCP Client That Talks to Your Server

Adding an LLM to Your MCP Client

STDIO vs SSE in MCP Servers

LLM Connected to a Local MCP Server

Testing MCP Servers Without a Browser

Deploying an MCP Server to Azure Container Apps

Using MCP Servers in VS Code Agent Mode

MCP avanzado

Query Azure Resources Directly From VS Code

Herramientas avanzadas de MCP para optimizar servidores y seguridad

GPT-4 Reading Local Files via MCP Server

Image Brightness Analysis with MCP and NumPy

How MCP Agents Remember Conversations

Enrutamiento de herramientas con MCP Server

Integrando tu MCP con un agente

Building a Web Search MCP Server with SERP API

Adding News, Products and Q&A Tools to MCP

Why MCP Docs Already Feel Outdated

MCP as the New Standard for AI Systems

STDIO vs SSE in MCP Servers

Progreso del curso

Introducción a MCP

Conceptos basicos de MCP

MCP avanzado

Integrando tu MCP con un agente

Recursos

Recursos