Model Context Protocol

A large language model (LLM) is a program that has read an enormous amount of text in advance and picks what word plausibly comes next. It knows nothing outside what it was trained on, so if you want it to work with your company's documents or today's schedule, someone has to fetch those and hand them over.

Fetching them was never the hard part. The hard part was that every connection got written from scratch. Code to reach the document store, code to reach the calendar, code to reach the customer records — and if four applications needed those tools, the same work happened four times. Five tools and four applications produce twenty separate connections, and when one tool changed its response format, all four places wired to it had to be fixed.

Theo hit exactly that at Pagedeck. The document-search connection he built for the internal question-answering feature got rewritten almost verbatim two months later for the meeting-notes summarizer. The two copies drifted apart, one got patched and the other didn't, and the same question started producing two different answers depending on which feature you asked.

The Model Context Protocol (MCP) fixes the shape of that connection. Anthropic published it as an open specification in late 2024, deliberately not bound to any one model or any one application.

It replaces connections that each looked different with a single agreed shape, which turns a multiplication into an addition. Five tools and four applications used to mean twenty implementations; when both sides follow one specification it's five on the tool side plus four on the application side.

The specification splits the work into roles.

1. Server — the side that holds a tool or a dataset advertises what it can do in the agreed format. A document store announces search, read and write, each with a name and an input shape.
2. Client — the side with the model in it. It connects to a server, pulls the list of what's available, executes whatever the model picks, and hands the result back to the model.
3. A fixed conversation format — asking for the list, requesting an execution, returning a result all have a defined shape. The application asks the same way no matter what it's talking to.

What matters in that split is that the application never needs to know the tool's internals. If the document store changes its API endpoints or its authentication scheme, the fix happens in that one server, and the four applications attached to it are left alone.

Being able to connect doesn't remove the underlying constraints. The tool list a server advertises is delivered to the model as text, so it consumes tokens — the smallest chunks a model breaks text into — and the context window, the amount it can hold at once, is fixed. Attach ten servers at once and reach a hundred tools, and the descriptions alone fill a large share of the window, leaving less room for the user's actual question and the material needed to answer it.

This isn't the only way to wire things up, and depending on what you need one of the following three is often enough.

1. Writing it into the application — with one or two tools used by a single application there's little reason to adopt a specification. A few functions described to the model, plus code that returns the call results, is a day's work. The specification starts paying off once the number of places to attach grows.
2. Supplying the material up front — if the job is answering from your own documents rather than calling a tool, retrieval-augmented generation (RAG) covers it. A question comes in, the relevant passages are pulled from internal documents and pasted into the prompt. Read-only features usually stop here.
3. A vendor's own integration — some tool vendors ship a proprietary way to connect that works inside their own application. It fits well within that boundary and has to be rewritten entirely to move anywhere else.

Against those three, the specification earns its cost when three conditions overlap: several tools to attach, several applications that need them, and a clear expectation that more tools are coming. Pagedeck wrote the first document-search connection by hand, then moved to the specification once the calendar and the customer records joined.

"Let's not wire that in directly — let's stand up an MCP server for it."

Publish it to the specification so other features can use it too, rather than attaching it to this one application.

"How many servers are attached? The tool descriptions alone must be filling half the window."

Too many connections are open and they're eating the space the model has to work in.

"That's not a protocol problem, it's a permissions problem. Block it on the server side."

What the tool is allowed to do has to be decided by the tool, not by the way it's connected.

The first server Theo stood up at Pagedeck was for the document store. He exposed search and read and left write out. Three features attached to that one server, and the search code that had been written twice two months earlier collapsed into a single copy that only one team maintains.

The discussion snagged when Mia asked for the calendar next. Exposing event creation would let the model book meetings on its own judgment, so they decided creation would only execute after a person pressed a confirm button, with a guardrail on the application side. A guardrail is a limit written in code that an output or an action is not allowed to cross.

The most common reading is that attaching the specification makes the model smarter, because afterwards the model visibly does things it couldn't do before. What changed is not the model but the material placed in front of it. The specification decides what gets fetched and how, not how the fetched thing gets judged. Try to fix wrong answers this way and you end up with more servers and the same wrong answers, now spread across more features than before.

The second is that following the specification makes a connection safe. "Conforming to a standard" sounds like "passed a review." But what the specification fixes is the shape of the exchange, not the content of it. Attach a server that exposes write and delete and the model can delete. What to expose, who to open it to, and whether an action waits for human confirmation are decisions the server and the application still have to make separately.