MCP servers

The page on sidecars contains a sentence it leaves unpaid. MCP is the socket, the sidecar is the appliance. Here it gets settled. A sidecar can be built perfectly and still stay out of reach for an agent, because nobody told it that this service exists, what it is called, which fields it expects and what comes back. The protocol fills that gap.

Why a protocol at all?

Hanging a tool into the loop is manual work, and how that works sits one station earlier. Write the schema, send it along, take the call, run it, hand back the result. For one tool that is a manageable hour. And for ten tools across three harnesses? The trouble starts with the second harness.

Because a binding like that is never general. It depends on how a tool gets described, on how the call comes back, on the language all of it is written in. Anyone with ten capabilities who wants them available in three harnesses has to write the same binding thirty times, each time with slightly different corners. That is not a theoretical calculation. It is what the field looked like until the end of 2024: every tool was taught to every harness individually, and whoever switched harnesses got to do the work again.

In November 2024 Anthropic published the Model Context Protocol and put it into the open. The idea behind it is unspectacular and effective for exactly that reason. If both sides speak the same language, the number of bindings drops from capabilities times harnesses to capabilities plus harnesses. A server you build once can afterwards be used by every client that speaks the protocol, and a harness that has learned it once reaches everything ever published as an MCP server, without anyone ever introducing the two sides to each other.

How far does the socket comparison carry? Further than it looks at first. A socket knows nothing about hairdryers. It fixes how wide the holes are, which voltage is present and what should happen when too much current flows. Everything beyond that is the appliance's business. MCP knows just as little about what parse_pdf does. It fixes how a tool introduces itself, how it gets called and in which shape the answer comes back, and whatever happens inside the sidecar afterwards remains its own affair.

Client and server: who calls whom?

Two roles, and for once the names explain themselves.

The server offers capabilities. It is the piece of software that sits in front of your sidecar, your database or your API and describes it. The client sits inside the harness and connects to one or more servers. A harness may speak to five servers at once. They know nothing about each other.

The exchange has three beats. Why should you know them? Because the first one holds most of the errors, and because a client that trips over a protocol version during the handshake leaves you with exactly one line of error message afterwards, one that mentions no tools at all.

1. Connect and initialize. Client and server tell each other which protocol version they speak and what they can do. Only after that is the connection a session.
2. tools/list. The client asks what is on offer. Back comes a list of names, descriptions and JSON schemas for the arguments. That list then travels into the model's context. It is the reason the model knows at all that it may call parse_pdf.
3. tools/call. The model settles on a tool, the harness sends name and arguments, the server does the work and answers.

Underneath sits JSON-RPC 2.0, a format older than any agent and here for exactly that reason. It is boring, widespread and available in every language.

Three things a server offers

Tools are the best-known part. The only one they are not. The protocol knows three kinds of offering. That is not cosmetics, because who holds control hangs on it.

Tools are model-controlled. The model decides when it wants to call send_invoice, and the harness runs it. Everything that changes something belongs here.

Resources are application-controlled. A server offers data under a URI, a file for instance, a database extract or a log. What of it travels into the context is for the harness to decide. The difference to a tool lies in the direction. A resource gets read and has no effect. Anyone who mixes the two and offers reading as a tool lets the model decide what it looks at. Sometimes that goes well. Mostly it gets expensive, because a model that is handed reading as a tool calls it the moment a word in the assignment remotely sounds like it, and the answer then sits in the history in full.

Prompts are user-controlled. The server delivers prepared text blocks that a surface can offer as a command. The user picks, the model receives the finished text. In practice this is the rarest of the three, and mostly rightly so.

On top of that comes a small thing with consequences. A server may report that its tool list has changed, and a client that listens to that message fetches it again. Sounds convenient. How far do you trust a tool whose description may change after the first successful call? In operation that is an attack surface, and the deep dive talks about it.

Two transports, and the choice is usually easy

The protocol fixes what gets spoken. What it gets spoken over is a second decision, and there are exactly two answers to it.

stdio means: the client starts the server as its own process and talks to it over standard input and output. No ports. No network. No login. Whoever was allowed to start the process is authorised. You take this transport for everything that runs on the same machine as the agent. File system access. A local git. A tool that reads the clipboard.

Streamable HTTP means: the server is a service with an address, the client sends POST requests, and answers may come back as an event stream when one of them takes longer. You take this transport for everything that does not sit on the user's machine: a shared service on the company network, a server behind a web surface, or an endpoint that ten people hang off at once and where none of them may see anyone else's session. It replaced the older arrangement of HTTP plus a permanently open event channel, which needed a standing connection per client and was correspondingly unpopular behind proxies.

The rule of thumb fits into one line. If it runs at the user, take stdio. If it runs for several, take Streamable HTTP.

One calculation gets made wrong again and again here. stdio is not the simpler way to build, it is the simpler way to operate. The code underneath stays the same. What falls away is everything a service needs the moment it should be reachable over the network. Who gets in. Who clears out old sessions. What happens under overload. And how the rest of the plant tells it is still alive. Need one of those and you will typically need all of them, and then the transport is no longer the interesting question. What that looks like is shown by the pro tier, on this project's own MCP server.

What MCP explicitly cannot do

Three mix-ups come up regularly. Each one costs time.

MCP does not replace tool calling. The model still calls tools the way it always has, and the loop inside the harness stays the same. MCP stands next to that loop and supplies it with the tool list, instead of that list sitting in the code.

MCP improves nothing that sits behind it. A server describing a bad PDF tool still describes a bad PDF tool. What actually happens behind the tool is not in the protocol. That is where the sidecar sits, and whether it is any good gets decided there.

An MCP server is not an agent. It decides nothing, it calls no model, it has no loop. It waits for requests and answers them. Once your server starts thinking for itself, you have built an agent and called it a server.

MCP is an open protocol through which a harness finds and calls capabilities without having each one taught to it. That drops the number of bindings from capabilities times harnesses to capabilities plus harnesses.

A server offers tools (model-controlled, with effect), resources (application-controlled, read-only) and prompts (user-controlled). The client inside the harness connects, fetches the list and calls.

Two transports. stdio for everything running on the user's machine, Streamable HTTP for everything several people share. The second is no harder to program, but harder to operate.