Transport Layer
MCP supports two official transport methods and also allows custom transport implementations.
3.1 stdio Transport
Principle: Communication via standard input (stdin) and standard output (stdout) streams. The Host launches the Server as a child process and exchanges JSON-RPC messages through pipes. Each message is delimited by a newline character.
Use case: Server and Client are running on the same machine.
Advantages:
- Zero network overhead, lowest latency
- No need to configure ports or certificates
- Secure (no network interface exposed)
- Simple to implement
Disadvantages:
- Local use only
- One Server process serves only one Client
Configuration example (Claude Desktop):
{
"mcpServers": {
"my-local-server": {
"command": "node",
"args": ["/path/to/my-server/index.js"],
"env": { "DB_URL": "postgresql://..." }
}
}
}
node /path/to/my-server/index.js as a child process and communicates via stdin/stdout. The Server’s stderr can be used for log output without interfering with the protocol.
3.2 Streamable HTTP Transport
Status: The currently recommended remote transport method (protocol version 2025-11-25).
Principle: Client and Server communicate through a single HTTP endpoint. The Client sends JSON-RPC requests via POST, and the Server can use Server-Sent Events (SSE) for streaming responses and proactive pushes.
Use case: Server is deployed remotely (cloud servers, SaaS services, etc.).
Core Mechanism
Single MCP endpoint: The Server exposes one endpoint (e.g., /mcp) that handles two HTTP methods:
- POST: The Client sends JSON-RPC requests. The Server can return a single JSON response or stream multiple messages via SSE.
- GET: The Client establishes an SSE connection to receive proactive pushes from the Server (notifications, requests, etc.).
Session management: Stateful sessions are managed via the Mcp-Session-Id HTTP header:
// Server returns Session ID in the initialize response
Mcp-Session-Id: session-abc123
// Client includes it in all subsequent requests
Mcp-Session-Id: session-abc123
MCP-Protocol-Version header:
MCP-Protocol-Version: 2025-11-25
Last-Event-ID mechanism for reconnection. The Client sends the ID of the last received event when reconnecting, and the Server continues pushing from that point:
// SSE event contains an ID
id: evt-42
event: message
data: {"jsonrpc":"2.0","method":"notifications/tools/list_changed"}
// Client sends this on reconnection
Last-Event-ID: evt-42
Advantages
- Supports remote access
- One Server can serve multiple Clients (distinguished by Session ID)
- Supports standard HTTP authentication (OAuth 2.1, API Keys, etc.)
- Supports load balancing and horizontal scaling
- Supports reconnection and message recovery
Disadvantages
- Network latency
- Requires HTTPS and authentication configuration
Configuration Example
{
"mcpServers": {
"my-remote-server": {
"url": "https://my-server.example.com/mcp",
"headers": {
"Authorization": "Bearer your-token-here"
}
}
}
}
3.3 Deprecated: HTTP+SSE Transport
The HTTP+SSE transport defined in protocol version 2024-11-05 has been deprecated. That approach used two separate endpoints (one SSE endpoint for Server pushes and one POST endpoint for Client requests), was more complex in design, and did not support session recovery. All new implementations should use Streamable HTTP.
| Feature | HTTP+SSE (Deprecated) | Streamable HTTP (Current) |
|---|
| Endpoints | 2 (SSE + POST) | 1 (unified endpoint) |
| Session management | No standardized approach | Mcp-Session-Id header |
| Reconnection recovery | Not supported | Supported (Last-Event-ID) |
| Protocol version | 2024-11-05 | 2025-11-25 |
| Status | Deprecated | Recommended |
3.4 Custom Transports
MCP allows custom transport layer implementations as long as they meet the basic requirements for JSON-RPC 2.0 message exchange: bidirectional message passing, request-response matching, and notification pushing. For example, you could implement a transport based on WebSocket, gRPC, or a custom TCP protocol.
3.5 Selection Guide
| Scenario | Recommended Transport | Reason |
|---|
| Development and testing | stdio | Simple, no deployment needed |
| Personal tools | stdio | Only used on your own machine |
| Team internal tools | Streamable HTTP | Shared by multiple people |
| SaaS products | Streamable HTTP | Serves external users |
| Commerce MCP Server | Streamable HTTP | Requires remote invocation by AI agents |
| High security requirements | stdio | No network interface exposed |
| Horizontal scaling needed | Streamable HTTP | Supports multiple instances and load balancing |
3.6 OAuth 2.1 Authentication
Authentication for remote MCP Servers is based on OAuth 2.1 (draft-ietf-oauth-v2-1-13), which is the standard authentication mechanism recommended by the MCP specification. See Chapter 7: Security and Authentication for details.
Authentication flow overview:
1. Client sends request to Server MCP endpoint
2. Server returns 401 with Protected Resource Metadata (RFC 9728)
3. Client fetches Authorization Server Metadata (RFC 8414)
4. Client performs Dynamic Client Registration (RFC 7591, if needed)
5. Client guides user through OAuth authorization (PKCE required, S256 method)
6. Client obtains access_token (Bearer token)
7. Subsequent requests carry the token in the Authorization header
Next Chapter: Building an MCP Server — Complete development guide for TypeScript and Python
