What are MCP Transports?

So, you’ve built your first MCP server – you’ve defined some tools, exposed a few resources, and maybe even wired up prompts – but how do you actually connect to it? That’s where transports come in.

MCP Transports define how messages move between clients and servers. While MCP is a model-agnostic, JSON-RPC-based protocol, the transport layer handles the real-world details of sending and receiving data – whether you’re embedding the server in a local CLI, streaming updates to a browser, or wiring it into a desktop agent.

MCP currently supports two standard forms of transport: stdio and SSE. Custom transports that conform to the standard input and output (stdio) and message-handling semantics are also supported.

Request, response, and notification formats

All communication follows the JSON-RPC 2.0 wire protocol. Every message sent between the client and the server falls into one of these categories:

Request

The client sends the following payload to invoke a method on the server:

Response

The server returns the following data after handling a request:

Notification

A notification is a one-way message that does not expect a response.

Built-in MCP Transports

MCP servers can be exposed over two built-in transport mechanisms:

stdio

Standard input and output (stdio) is the simplest and most universal transport for MCP. It allows a server to read from stdin and write to stdout, which is ideal for local use, CLIs, and agent plugins.

Other use cases are:

• CLI tools
• Local development
• Agent plugins (like the Claude desktop app or LangGraph steps)

Here is a Python implementation of an MCP transport with stdio:

In the example above, we:

• Register an empty list of tools via @list_tools, which could later be populated with callable server-side functions.
• Use stdio_server() as the transport, which opens standard input and output streams for communication and is ideal for local processes and CLI integrations.
• Run the server with app.run(...), passing the opened streams and initialization options to handle incoming JSON-RPC messages and serve responses.

SSE

Server-sent events (SSE) provide a persistent connection for server-to-client streaming, while client-to-server messages are sent using HTTP POST. It’s useful for interactive UIs, dashboards, or environments where long-lived connections are preferred.

Here is an implementation of an MCP server serving via SSE:

In the example above, we:

• Initialize the SSE transport using SseServerTransport("/messages"), which defines the internal POST message endpoint that the server will listen to for client inputs.
• Define a /sse endpoint via sse_handler, which establishes a persistent SSE connection. Inside it, we call app.run() with the input and output streams from the connected client.
• Define a /messages POST route with post_handler, allowing the client to send messages back to the server via HTTP POST, which is how the client communicates with the server.
• Wrap the handlers in a Starlette app using route definitions, making it ready to be served by any ASGI server (for example, Uvicorn).

Custom transport implementations

MCP does not require servers to use stdio or SSE. Any transport can be used, as long as it:

1. Supports bidirectional messaging via JSON-RPC 2.0.
2. Can be hooked into the server’s run(read_stream, write_stream, initialization_options) method.
3. Implements proper connection lifecycle and error handling.

So, you can use:

• WebSockets
• gRPC
• Shared memory channels
• Named pipes
• Custom browser bridges

You must ensure that the messages follow the JSON-RPC structure and that your transport yields the appropriate async streams.

Connection lifecycle and control

Regardless of the transport used, all MCP connections follow the same lifecycle:

Initialization

1. The client connects and sends an initialize request with its capabilities.
2. The server responds with its capabilities and protocol version.
3. The client acknowledges with notifications/initialized.

Active session

During an active session, both clients and servers can:

• Make requests that expect responses.
• Send notifications that don’t expect responses.
• Cancel in-flight requests with notifications/cancelled.
• Send progress updates with notifications/progress (although this is not yet implemented by the Python MCP SDK).

Termination

Either side can terminate the connection by:

• Closing the transport.
• Sending a protocol-specific termination message.
• Disconnecting without notification (although clean termination is preferred).

Final thoughts

Transports should be secured according to their communication layers:

• For SSE, validate Origin headers, enforce authentication, and bind to localhost during local development to avoid DNS rebinding vulnerabilities.
• For custom transports, ensure that authentication, rate limiting, and input sanitization are enforced. Always follow the JSON-RPC security best practices  and sanitize all payloads.

The transport may be low-level but it defines the perimeter of your server, so treat it as a security boundary.

An MCP server can support multiple transport mechanisms simultaneously, but it must implement at least one transport to be operational. Each client connection uses one specific transport, but the server itself can expose its functionality through different transport interfaces based on various client needs.