Transports: stdio, Streamable HTTP and running at scale

0:00 Transports

How do messages actually get between an AI app and an MCP server? There are two standard ways, and choosing the right one affects security, scaling and how you deploy. In this lesson you'll learn standard I O and Streamable HTTP, what changed in twenty twenty six, and how to protect local servers from a sneaky browser attack.

0:25 Why transports matter

Why do transports deserve a whole lesson? Because the transport decides who can reach your server, how it authenticates, and how it scales. Think of standard I O as a private phone line inside your house: only the person who picked up can talk, and there's no one else on it. Streamable HTTP is a public shop front: anyone can walk up to the counter, so you need a door policy, opening hours and a queue system. Choose the wrong one, and you either can't share your tool, or you've left the shop unlocked.

1:06 stdio

With standard I O, the client launches your server as a subprocess and they swap JSON messages, one per line, over standard input and output. Your server can log to standard error, but it must never write anything else to standard output, because that channel is the protocol. This is ideal for local tools like file access, local databases and developer utilities, and credentials come from environment variables rather than OAuth.

1:37 Streamable HTTP

Streamable HTTP runs your server as a web service with a single endpoint, usually slash M C P. The client posts each message. The server replies with a JSON body, or, if it needs to send progress updates first, a server sent events stream for that one response. It's the right choice for remote, shared and multi user servers, and it uses OAuth for authorization. The older HTTP plus SSE transport, with two endpoints, is formally deprecated, so don't build on it.

2:13 HTTP in 2026-07-28

The twenty twenty six spec made HTTP much simpler to scale. There are no sessions, so every request stands alone. Posts must carry M C P method and M C P name headers, so gateways can route and authorize on headers. The old GET stream is replaced by an opt in subscriptions listen request for change notifications. Stream resumability is gone, so if a stream breaks, the client simply re issues the request, which means your tools should be idempotent. And list results carry cache hints.

2:50 Simple example: a notes-search server

A simple example. You build a server that searches your own notes folder. For yourself, standard I O is perfect: your AI app launches it, it reads your local files, and nothing listens on the network. Now your team of five wants the same thing over a shared drive. You switch to Streamable HTTP, deploy it on an internal host with company sign in, and each teammate adds the URL. Same tools, same code, different transport, and suddenly authentication and rate limits matter.

3:26 Local server security

Now a security trap. If you run an HTTP server on localhost, any web page the user visits can try to reach it through a trick called DNS rebinding. The page's domain suddenly resolves to your own machine, and the browser treats your server as same origin. Defend it: bind to one two seven dot zero dot zero dot one, not all interfaces, validate the host and origin headers, and require auth for anything non trivial. The official TypeScript Express helper turns these checks on by default. And for standard I O servers, remember the host runs your command with the user's privileges, so only install servers you trust.

4:13 Choosing a transport

How do you choose? A personal tool on a laptop touching local files: standard I O. A team or company wide service: Streamable HTTP with OAuth. A software vendor offering an integration to customers: Streamable HTTP with OAuth, listed in registries. A desktop app bundling a helper: usually standard I O. And serverless or edge deployments: Streamable HTTP, since stateless servers fit perfectly.

4:40 Example: laptop to team service

A worked example. A data analyst in Lahore builds a standard I O server with read only SQL over marketing data. Colleagues want access. Moving to HTTP takes five steps: switch the run call to Streamable HTTP, deploy behind the company's API gateway with TLS, add OAuth through the company identity provider with an analytics read scope, rate limit per user on the tool name header, and scale horizontally, which just works because there's no session state.

5:13 Hands-on: one server, two transports

The hands on section shows the same metrics server both ways. In Python, one flag switches between standard I O and Streamable HTTP on port three thousand and one. In TypeScript version two, a handler factory creates a fresh server per request, which is why it scales statelessly, and the Express helper adds host and origin validation. Keep connection pools at module scope, not inside the factory. Avoid printing to standard output, binding to all interfaces, relying on removed session features, and building on the deprecated transport.

5:51 Serverless notes

What about serverless platforms? Streamable HTTP under the twenty twenty six spec is a great fit, because every request is independent. But watch three things. Cold starts can add latency to the first request after idle time. Execution time limits can cut off long running tools, so use the tasks extension or background jobs for slow work. And keep connection pools and SDK clients outside the request handler, so warm instances reuse them.

6:23 Deeper: from 1 to 20 users (illustrative)

Let's deepen the Lahore analyst's move to a team service, with illustrative numbers. The standard I O version served one person. The HTTP version, behind the company gateway with sign in, served twenty analysts in its first month. Two replicas handled peak Monday mornings without any session affinity. The gateway's per user rate limit on the tool name header stopped one analyst's runaway script from affecting everyone else. And because every request carried its method and tool name in headers, the security team built a dashboard of who queried what, without decrypting or parsing request bodies.

7:05 Watch me do it: one server, two transports

Watch me do it. Let's run the metrics server both ways. In Python, the file defines one tool, weekly signups, and at the bottom checks for a dash dash http flag. Without it, mcp run uses standard I O. I launch the Inspector with the stdio command and call the tool with market UAE. Now I start it with the flag: the server listens on one two seven dot zero dot zero dot one, port three thousand and one, path slash mcp. In the Inspector I switch to Streamable HTTP, paste the URL and call the same tool. Same result. Now the TypeScript version: create MCP handler takes a factory that builds a fresh server and registers the same tool with a Zod schema. Create MCP Express app gives me Express with host and origin checks for localhost. I mount the node handler on slash mcp and listen on the loopback address. If I send a request with a foreign host header, it gets a four oh three.

8:18 Try this now

Try this now. Run the lesson's server both ways. First, standard I O: open the Inspector and call the tool. Then start it with the HTTP flag and connect the Inspector to the local URL. Try adding a print statement to the standard I O version and watch what breaks. Finally, write one paragraph for your team: which transport your first production server will use, who needs to reach it, how they'll authenticate, and what happens when you need three copies of it.

8:54 Recap

To recap: standard I O for local, Streamable HTTP for remote. Keep standard output clean, protect localhost servers from DNS rebinding, and enjoy stateless scaling in the twenty twenty six spec. Your next step: run the lesson's server over both transports, connect the Inspector to each, and decide which transport your first production server should use.