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://..." }
    }
  }
}

The Host launches 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

Protocol version header: Requests must include the MCP-Protocol-Version header:

MCP-Protocol-Version: 2025-11-25

Resumability: Supports SSE’s 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.

Differences between the deprecated HTTP+SSE and the current 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:

Client sends request to Server MCP endpoint
Server returns 401 with Protected Resource Metadata (RFC 9728)
Client fetches Authorization Server Metadata (RFC 8414)
Client performs Dynamic Client Registration (RFC 7591, if needed)
Client guides user through OAuth authorization (PKCE required, S256 method)
Client obtains access_token (Bearer token)
Subsequent requests carry the token in the Authorization header

The MCP specification does not invent new authentication mechanisms; it relies entirely on existing OAuth standards and RFC specifications.

Next Chapter: Building an MCP Server — Complete development guide for TypeScript and Python

MCP data layer and JSON-RPC 2.0 messages Building an MCP Server in TypeScript or Python

Start

Learning Paths

Getting Started with AI Commerce

OTR Open Trust Registry

UCP Universal Commerce Protocol

ACP Agentic Commerce Protocol

MCP Model Context Protocol

SEO for the AI Era

ORBEXA Integrated Solution

Templates & Prompts

Glossary

MCP transport layer: stdio and Streamable HTTP

Transport Layer

3.1 stdio Transport

3.2 Streamable HTTP Transport

Core Mechanism

Advantages

Disadvantages

Configuration Example

3.3 Deprecated: HTTP+SSE Transport

3.4 Custom Transports

3.5 Selection Guide

3.6 OAuth 2.1 Authentication

​Transport Layer

​3.1 stdio Transport

​3.2 Streamable HTTP Transport

​Core Mechanism

​Advantages

​Disadvantages

​Configuration Example

​3.3 Deprecated: HTTP+SSE Transport

​3.4 Custom Transports

​3.5 Selection Guide

​3.6 OAuth 2.1 Authentication

Transport Layer

3.1 stdio Transport

3.2 Streamable HTTP Transport

Core Mechanism

Advantages

Disadvantages

Configuration Example

3.3 Deprecated: HTTP+SSE Transport

3.4 Custom Transports

3.5 Selection Guide

3.6 OAuth 2.1 Authentication