Lesson 5: Local and Remote Servers (Transports)

In this lesson you will:

• Learn the two standard ways MCP messages travel: stdio and Streamable HTTP.
• See why a "local" server and a "remote" server behave so differently in practice.
• Learn the basic security rules each transport carries.

In earlier lessons you followed messages like tools/list and tools/call. This lesson looks at the road those messages travel on. In MCP, that road is called a transport.

1. What a transport is

The MCP architecture overview splits MCP into two layers. The data layer is the JSON-RPC messages themselves. The transport layer is "the communication mechanisms and channels" that carry those messages, including connection setup, message framing and authorization.

The transports page of the 2026-07-28 spec says it plainly: "Protocol semantics are identical on every transport." A transport defines how messages are framed and delivered. It does not define what they mean.

That is good news for you. A tools/call request looks the same whether the server sits on your laptop or in a vendor's cloud. Only the delivery changes. For a deeper reference, see MCP transports explained.

2. stdio: the local transport

In the stdio transport, "the client launches the MCP server as a subprocess." Your AI app starts the server program itself. The two then talk through the program's standard input (stdin) and standard output (stdout).

The rules are short:

• Each message is one JSON-RPC message on one line, separated by newlines.
• The server must not write anything to stdout that is not a valid MCP message.
• The server may write logs to stderr, and the client should not assume stderr output means an error.
• To cancel a request, the client sends a notifications/cancelled notification.
• To shut down, the client closes the server's input stream and waits for it to exit.

This is why local servers appear in config files as a command to run. In the Claude Desktop local server guide, the filesystem server is defined with "command": "npx" and a list of arguments. Claude Desktop runs that command when it starts.

The architecture overview notes that a local stdio server "typically" serves a single client. It runs with your user account's permissions, so it can reach what you can reach. Read the stdio transport reference for the full rules.

3. Streamable HTTP: the remote transport

Remote servers use Streamable HTTP. The server runs as its own process, often on a vendor's infrastructure, and can handle many clients.

Here is how it works, per the spec:

• The server exposes one HTTP address, called the MCP endpoint, such as https://example.com/mcp.
• The client sends every JSON-RPC request as its own HTTP POST to that endpoint.
• The server answers each request with a single JSON object or a Server-Sent Events (SSE) stream scoped to that request.
• Change notifications, like "the tool list changed," arrive on a long-lived stream the client opens with subscriptions/listen.

Each POST also carries headers such as MCP-Protocol-Version: 2026-07-28, Mcp-Method and, for tool calls, Mcp-Name. These mirror values from the message body so gateways and load balancers can route traffic without reading the body.

For sign-in, the architecture overview says Streamable HTTP supports bearer tokens, API keys and custom headers, and that "MCP recommends using OAuth to obtain authentication tokens." Lesson 22 and our guide to MCP authentication and OAuth cover that in depth.

4. Security rules built into the transports

The Streamable HTTP page lists three rules:

1. Servers must validate the Origin header on all incoming connections to prevent DNS rebinding attacks. An invalid Origin gets an HTTP 403.
2. When running locally, servers should bind only to localhost (127.0.0.1), not all network interfaces (0.0.0.0).
3. Servers should implement proper authentication for all connections.

The spec warns that without these protections, "attackers could use DNS rebinding to interact with local MCP servers from remote websites." In plain terms, a web page you visit could try to reach a server running on your own machine. See DNS rebinding and local MCP servers for how that attack works.

The security best practices page adds advice for local servers. Servers meant to run locally should use stdio "to limit access to just the MCP client." If they use HTTP, they should require an authorization token or use a restricted channel such as a Unix domain socket.

5. What changed in the July 2026 spec

If you read older tutorials, you will see features that no longer exist. The Streamable HTTP page says revision 2026-07-28 made two changes:

• Removal of the GET stream endpoint. Clients used to open a standalone stream with HTTP GET to receive server messages.
• Removal of protocol-level sessions. Servers used to assign a session with the Mcp-Session-Id header.

Streamable HTTP itself arrived in protocol version 2025-03-26. It replaced the HTTP+SSE transport from 2024-11-05. The spec classifies HTTP+SSE as deprecated: new implementations should not adopt it, and existing ones should migrate.

Some apps still let you pick it. The Claude Code MCP docs recommend HTTP for remote servers and mark SSE as deprecated. If a vendor only offers an SSE address, treat that as a sign the server may be out of date. Our legacy HTTP+SSE guide explains migration.

6. Custom transports

The spec also lets clients and servers build their own transports. Custom transports must keep the JSON-RPC format, the message patterns and the per-request metadata. Those that run over a byte stream, like a Unix socket or TCP, should reuse the stdio framing.

You will rarely meet a custom transport as a business user. Just know the two standard ones cover almost every server you will connect.

Try it

Open the MCP configuration file for an app you use. Lesson 6 shows where Claude Desktop keeps it; Cursor uses .cursor/mcp.json or ~/.cursor/mcp.json.

For each server in the file, sort it into one of two columns:

1. Local (stdio): the entry has a "command" and "args", such as "command": "npx". Your app runs this program on your computer.
2. Remote (HTTP): the entry has a "url", such as "url": "https://example.com/mcp". Your app sends requests over the internet.

For each local server, write down which folders or accounts it can reach. For each remote server, write down who runs it and how you signed in. If you have no config file yet, do this exercise with the two examples from Cursor's MCP docs: one command entry and one url entry.

Recap

• A transport is the delivery channel; the messages are the same on every transport.
• stdio means your app launches the server locally and talks through standard input and output.
• Streamable HTTP means one HTTPS endpoint, one POST per message, and replies as JSON or a short event stream.
• Local HTTP servers must guard against DNS rebinding, and remote servers should require authentication, usually OAuth.
• HTTP+SSE is deprecated, and the July 2026 spec removed sessions and the GET stream.

You can find every lesson on the Learn MCP course page and the spec references in the MCP Guide.

Course navigation

Previous lesson: Lesson 4: Follow One Request From Prompt to Result.

Next lesson: Lesson 6: Connect Your First MCP Server.

Back to the Learn MCP course outline.

Frequently asked questions