> ## Documentation Index
> Fetch the complete documentation index at: https://learn.orbexa.io/llms.txt
> Use this file to discover all available pages before exploring further.

# MCP transport layer: stdio and Streamable HTTP

> MCP transport layer explained — stdio local transport, Streamable HTTP remote transport, deprecated HTTP+SSE, and OAuth 2.1 authentication

# 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):

```json theme={null}
{
  "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

```json theme={null}
{
  "mcpServers": {
    "my-remote-server": {
      "url": "https://my-server.example.com/mcp",
      "headers": {
        "Authorization": "Bearer your-token-here"
      }
    }
  }
}
```

## 3.3 Deprecated: HTTP+SSE Transport

<Warning>
  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.
</Warning>

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](/en/book-5/ch7-security) 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
```

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](/en/book-5/ch4-build-server) — Complete development guide for TypeScript and Python