Control as a classification

Why sort what a server offers by who is allowed to invoke it rather than by what it does?

Suppose you are designing the vocabulary a server uses to describe what it offers to an AI assistant. The natural instinct is to sort by function: reads over here, writes over there, searches in a third pile. That is how we classify almost everything else in software.

Yet the Model Context Protocol sorts its primitives a different way. It offers tools, resources and prompts — and the line between them is not what they do. A tool can read; a resource is read. What separates them is who decides to invoke them. That is an odd axis to build a type system on, so it is worth asking what it buys.

Start with a concrete awkwardness. A server can expose a database query. Should the assistant fire it whenever it judges the query useful? Should the host application load it as background context before the conversation starts? Should it wait until a person picks it from a menu? Notice that the function is identical in all three cases — same SQL, same rows — and yet the three arrangements have completely different consequences. If classification by function cannot tell them apart, classification by function is not capturing the thing that matters.

What does matter? Ask what could go wrong in each arrangement. If the model decides, the risk is autonomous action: something happens that no human chose. If the application decides, the risk is context bloat and staleness — material loaded that nobody asked for. If the person decides, the risk is only that they choose badly, which is the ordinary condition of using software. These are different failure modes with different mitigations, and they track the controller, not the operation.

So push the thought further: is "who invokes this" a property of the operation at all, or a property of the arrangement around it? It is the arrangement — and that is exactly why it deserves to be declared rather than inferred. If the protocol does not say, then every host application must guess, and two hosts will guess differently. Making control explicit turns an implicit deployment assumption into part of the contract.

Now watch how the three MCP primitives fall out of that. Tools are model-controlled: the assistant may decide, within a conversation, to call one, which is why a tool carries a machine-readable input schema and a description written for the model to read. Resources are application-controlled: the host decides what to load into context, which is why resources are addressed by URI and can be listed and read without the model choosing anything. Prompts are user-controlled: a person invokes them deliberately, which is why they surface as templates a client can present in a menu or as a slash command.

Do you see that the shape of each primitive follows from its controller rather than from its function? A tool needs a schema because a model must construct arguments unaided. A prompt needs a human-readable title because a person must recognise it in a list. A resource needs a stable address because an application must fetch it on its own schedule. Sorting by function would have produced none of those differences — three read operations would have looked the same.

And there is a security consequence that falls out for free. The review question a security engineer actually asks is not "does this read or write?" but "can this happen without a human in the loop?" A classification keyed on control answers that question by construction. A classification keyed on function requires you to reconstruct it, case by case, from documentation that may be wrong.

One honest limit before we go on: these are conventions in the specification, not enforcement. Nothing in the wire format stops a host from auto-invoking a prompt or exposing a resource to the model as if it were a tool. The primitive tells you the intended controller; the host is what makes it true.

Two clarifications keep this from being over-read.

First, this is not a claim that function does not matter. It matters enormously — inside a category. Among tools, whether one is read-only or destructive is the central question, and the protocol has room for annotations that say so. The point is only about the top level of the taxonomy: control is the split that determines the shape of the primitive and the shape of the review, so it goes first, and function refines it underneath.

Second, "model-controlled" does not mean unsupervised. A host is free to require confirmation before every tool call, and most do for anything consequential. The classification says who selects the operation, not who authorises it. Conflating selection with authorisation is the common misreading, and it makes tools sound more dangerous than they are and prompts sound safer than they are — a user-invoked prompt can, after all, expand into text that leads the model to call several tools.

The deeper idea generalizes past this one protocol. Whenever a system has an autonomous component, the interesting boundary is rarely the data boundary. It is the initiative boundary: which side of the interface may begin an action. Naming that boundary in the type system means every later question about safety, auditing and user experience has somewhere to attach.

• Whether tool annotations such as read-only or destructive hints are load-bearing or merely advisory, and what a host should do when they are absent.
• How a user-invoked prompt that expands into several tool calls should be audited, given that the initiator changes mid-flight.
• What a fourth control class would look like if one existed — for instance, operations initiated by the server itself.

Every term the collection defines is gathered in the glossary.