An agent can only use what it can discover.
MCP is a discovery protocol. Most of the work is writing descriptions a model can route on.
The tool description is the interface — the model routes on prose, not on your schema
An MCP server advertises a catalogue: each tool has a name, a description and a JSON schema. When a request arrives, the model decides which tool to call by reading those descriptions, so the description is not documentation sitting beside the interface — it *is* the interface. This is where most servers underperform. A description that says what a tool does ("searches records") gives the model no basis for deciding *when* to reach for it, and the common result is a tool that exists and is never called. Descriptions that state the trigger condition — when to call this, and when not to — measurably improve selection. The schema then constrains the arguments, but it never influences the choice.
- What the server advertises
- Tool name, description, JSON schema. The client fetches the catalogue on connect.
- What the model routes on
- The description. The schema validates arguments; it does not drive selection.
- Good description
- States when to call it, not just what it does. Include the non-obvious cases.
- Common failure
- A tool nobody calls because nothing in its description names a trigger.
- Tool count
- Past a few dozen, prefer deferred loading or search over always-loading every schema.
- Transport
- Local stdio for a dev machine; HTTP for a hosted server the client connects out to.
FAQ
Almost always the description. If it explains what the tool does but never says when to reach for it, the model has no basis for choosing it over answering directly. Rewriting a description to lead with the trigger condition — "call this when the user asks about X" — is usually the entire fix.
Every tool schema occupies context on every request, so the cost is continuous rather than at call time. Past a few dozen it is generally better to defer loading and let the model search the catalogue than to hold every schema in context permanently.
They solve different problems. A REST API is something you write code against; MCP is how a model discovers, at runtime, that a capability exists and how to invoke it. If you want an assistant to use your service without someone writing an integration first, that discovery layer is the part you are missing.
That it does something the model cannot do by reasoning alone — reach a system, perform a side effect, return data it has no other access to. Tools that wrap something the model can already do add latency and selection ambiguity without adding capability.