MCP Server Types: STDIO, SSE, and OAuth

Updated November 2, 2026 — Le Chat is now Vibe. As of May 28, 2026, Le Chat has been rebranded as Vibe (still at chat.mistral.ai): a single agent for work and code, carrying over your conversations, settings, and subscriptions. The legacy Le Chat experience remains accessible in Chat mode; in Work mode, agents have become skills (invoked with @), memories have become the knowledge base, and deep search has become the Deep Research skill. The plans are now called Mistral Free, Pro, Team, and Enterprise. This lesson uses the name Vibe; some menus described here may have changed names or locations.

Two transport modes, two architectures

An MCP server communicates with its client in two fundamentally different ways, depending on whether it runs on the same machine or on a remote host. This distinction isn’t an implementation detail: it determines who can consume your server, how you deploy it, and what data it can access. Making this choice early will save you from rewriting your project halfway through.

STDIO: the server that lives on your machine

STDIO (Standard Input/Output) is the local transport. The MCP server runs on the same machine as the client, and communication flows through the operating system’s standard streams: stdin and stdout. The mechanism is direct: the client launches the server process, sends requests via stdin, reads responses from stdout, and terminates the process when the conversation ends. No ports, no URLs, no certificates.

This transport is the natural fit whenever a tool needs to touch the local environment. A server that reads your files, calls git, drives Docker, or inspects a SQLite database sitting on your disk only makes sense in STDIO mode. It’s also the preferred mode for integrations in editors like VS Code or Cursor, and the obvious companion for the development phase, where you want to restart your server every thirty seconds.

from mcp import StdioServerParameters

server_params = StdioServerParameters(
    command="python",
    args=["my_mcp_server.py"],
    env=None,  # Optional environment variables
)

The trade-off is strict: server and client must coexist. You cannot connect a STDIO server to Mistral Vibe, since Vibe runs on Mistral’s infrastructure and has no way to launch a process on your machine.

SSE and Streamable HTTP: remote servers

To move beyond the local machine, MCP uses HTTP. Two variants have succeeded each other, and it helps to know which one you’re looking at when reading existing code.

SSE (Server-Sent Events) was the protocol’s first remote transport. It allowed the server to stream events to the client, which in turn had to make separate POST requests to talk back to the server. Its structural flaw: it required a persistent connection between the two, complicating serverless hosting and scaling. It is now deprecated—the Mistral SDK still provides MCPClientSSE for existing /sse endpoints, but new servers should no longer be built on this basis.

Streamable HTTP has replaced it as the standard remote transport. It removes the requirement for a persistent connection: the client sends standard HTTP requests, and the server responds via streaming or in a single block, as needed. In practice, your remote server exposes an /mcp endpoint that the client connects to.

from mistralai.extra.mcp.streamable_http import (
    MCPClientStreamableHTTP,
    StreamableHTTPServerParams,
)

# Connect to a remote MCP server
server_url = "https://my-server.example.com/mcp"
mcp_client = MCPClientStreamableHTTP(
    params=StreamableHTTPServerParams(url=server_url, timeout=100)
)

Three levels of authentication

Transport tells you where the server lives; authentication tells you who is allowed to call it. These are independent questions, and the protocol supports three answers.

The simplest is no authentication: anyone who knows the URL can use your tools. This choice is defensible only for public tools with no sensitive data—a unit converter, a web scraper, a calculator.

Next comes the token, or API key. You generate a token with specific permissions and pass it to the client, which includes it in its requests. GitHub illustrates this model well: you create a Personal Access Token by checking only the scopes your agent actually needs, and nothing more.

The third level is OAuth 2.0, the full flow with a consent screen. The user explicitly authorizes the application to act on their account, and the server receives a token tied to that person. This is what Gmail, Linear, or Google Calendar do when you connect them in Vibe—and it’s the only acceptable model once a server handles personal data for multiple users.

How to decide in practice

The decision comes down to two questions asked in order. Does the server run on the same machine as the client? If yes, choose STDIO. If no, choose Streamable HTTP, with or without authentication depending on the sensitivity of the data being handled.

Keep the client-side constraint in mind: Mistral Vibe and hosted chatbots in general consume only remote servers. An IDE like VS Code or Cursor, however, accepts both modes—hence the comfortable habit of developing in STDIO, then switching to HTTP when it’s time to share the server.

Key takeaways

• STDIO = local server, same machine, perfect for development
• Streamable HTTP = remote server, current standard, replaces SSE
• Three auth levels: none, token, OAuth 2.0
• Mistral Vibe supports only remote servers
• Your transport choice depends on your deployment architecture