Connecting a language model to an external system was, for a period, a bespoke exercise. Each assistant defined its own way of describing a tool, its own calling convention, and its own way of returning results. Each integration had to be written against a specific assistant.
With a handful of assistants and a handful of tools that is tolerable. With many of each it is not, because the work grows with the product of the two rather than the sum. The Model Context Protocol exists to convert that product into a sum.
The shape of the problem
The argument is the same one that produced every other integration protocol. If every consumer speaks a common language and every provider speaks it too, then a new provider becomes usable by every existing consumer without either side knowing about the other.
The value is not technical elegance. It is that the tool author writes one implementation rather than one per assistant, and the assistant author supports one protocol rather than one per tool.
Hosts, clients, and servers
Three roles are worth keeping distinct, because they are easily confused.
The host is the application the person is using, and it owns the conversation and the model. The client is the component inside the host that speaks the protocol, with one client per connected server. The server is the process exposing a capability, such as a filesystem, a database, or an external service.
The server is not part of the model and is not part of the assistant. It is an ordinary program that happens to speak a defined protocol, and it runs wherever it is deployed, with whatever credentials it was given.
How they talk
Communication is a structured request and response exchange. A server running locally is typically spoken to over its standard input and output, which is convenient because it requires no network exposure at all. A remote server is reached over HTTP, which introduces transport security and authentication as real concerns.
Three primitives, distinguished by who decides
The protocol exposes capability in three forms, and the distinction between them is about control rather than data.
| Primitive | Who decides to use it | Typical purpose |
|---|---|---|
| Tools | The model | Actions it may choose to invoke |
| Resources | The application | Data the host chooses to supply |
| Prompts | The person | Workflows invoked deliberately |
Reading those three as a spectrum of control, running from the model to the application to the person, explains why all three exist rather than only the first.
Discovery, and why it is not free
A client connects and asks what the server offers, and the server responds with its available tools, their descriptions, and their argument schemas. Those descriptions are then placed in the model's context so it can choose among them.
This has a cost that is easy to overlook. Every connected server consumes context budget merely by being available, before any tool is called. Connect enough servers and a meaningful fraction of the window is occupied by descriptions of capabilities that will not be used in this conversation, which reduces the space available for the actual work and gives the model more options to choose incorrectly between.
Where the security question actually sits
The protocol standardises how capability is described and invoked. It does not decide whether an invocation should be allowed, and that distinction is the whole of the security discussion.
A server runs with real credentials. A server exposing a database holds database access, and a server exposing a filesystem holds filesystem access. The model requests an action and the server performs it with its own authority, which is the classic arrangement in which a privileged component acts on instructions from a less trusted one.
Two consequences
Two consequences follow. Scope matters more than authentication, so a server should hold the narrowest credentials that permit its purpose, because the model will eventually request something unintended and the server's permissions are the only thing that prevents it. And tool output is untrusted input, because anything a server returns enters the context as text, and a model does not reliably separate data it retrieved from instructions it was given. Content fetched from an external source can carry instructions, and those instructions arrive inside the reasoning loop.
The practical position is that connecting a server is a grant of authority, and it should be reviewed the way any other grant of authority is reviewed. A protocol makes connection easy, and easy grants of authority accumulate quietly.
What to check before connecting one
Because connecting a server is a grant of authority, a short review is worth doing every time, and it is largely the same review you would apply to any dependency that runs with credentials.
Establish what credentials the server holds and whether they can be narrowed, since read only access is sufficient for a great many uses and is a much smaller problem when something goes wrong. Establish which of its tools perform writes or irreversible actions, and whether those need to be exposed at all. Consider where it runs, because a local server communicating over standard input and output has no network exposure, while a remote one needs transport security and authentication handled properly.
Then consider what it returns. A server that fetches arbitrary external content is delivering untrusted text into the reasoning loop, which is a materially different risk from a server that returns structured records from a database you control.
What it does not do
It is worth stating the limits plainly. The protocol does not make a model competent at choosing tools, and a poorly described tool will be misused regardless. It does not provide authorisation, which remains the server's responsibility. It does not manage context budget on the host's behalf. And it does not verify that a tool did what it claimed.
What it does is remove the integration tax, which was a genuine obstacle. Everything above that layer is still ordinary system design.
Note: the useful mental model is that a server is a deputy acting with its own credentials on instructions from something that can be manipulated by the content it reads. Design the permissions on that basis rather than on the assumption that the instructions are trustworthy.