Fonctionnement du transport stdio

Before you wire your server into anything, you need to know how it actually communicates. The default channel is stdio. 🔌

The name stdio is just standard input plus standard output: two text streams every program already has from the moment it starts.

With stdio, the host launches your server as a child process. There is no port and no network call, just a local program it owns.

The client writes JSON-RPC messages to your server’s stdin, and your server writes its replies back out through stdout.

You almost never start the script yourself. You tell the host a command, and it runs that command to bring your server to life.

Because replies travel on stdout, that stream is reserved for the protocol. Any stray print there will scramble the JSON the client expects.

Need to leave yourself notes? Send them to stderr. The host treats stderr as logs, so your debugging never touches the message stream.

Each stdio connection is a private link: one client, one process. Close the client and your server process shuts down with it.

stdio shines for local work. It needs no auth, no firewall, and no URL, which makes it the perfect transport while you develop. 💻

The catch: the server must live on the same machine as the host. To reach a server remotely, you will later switch to HTTP transport.

Each JSON-RPC message is a single line ending in a newline. That framing lets both sides split the stream into clean, separate messages.

Where does a stdio server send its JSON-RPC replies?

You saw how stdio works: the host spawns your process, talks over stdin and stdout, and keeps logs on stderr. Now let’s plug it into Claude. ✅