An MCP, short for Model Context Protocol, is a standard way for an AI agent to use software you already run: Gmail, Slack, your CRM. Anthropic published it. A chatbot tells you what to write to the tenant about the lease renewal; an agent with an MCP sends the email. The tool provider builds one MCP, and after that any AI model can use that tool without a custom integration.
How does an MCP work?
For an agent to act inside a tool, two things have to be true.
- Authentication. The agent has the right to use the tool.
- Tool calls. The agent knows how to instruct the tool once it is in.
Before MCP, the model had to work both of those out for every tool it touched. Every tool authenticates its own way, every tool exposes its own set of actions, and there was no universal way for the model to talk to any of them.
MCP splits that into two halves, and both halves have names you will meet in the docs. The MCP server is the tool side: Google runs one for Gmail, and it lists every action Gmail offers and how to call each one. The MCP client is the model side, built once by whoever builds the agent, and it talks to every MCP server in the same shape.
Is an MCP just an API?
No. An API is one machine speaking to another through a uniform pattern. Models do not work like two machines calling each other, and a tool needs to hand over more than an API does: which actions exist, when each one applies, and what has to happen before it. The MCP server is the middle layer that carries all of that, and the tool owner writes it once.
The analogy we use is the USB port. Before USB, your mouse, your monitor and your charger each plugged into their own input. USB did not make the devices better, it made them interchangeable.
Why MCP exists: the connector maths
Say four AI models each need to reach five tools: Gmail, Slack, your CRM and two more. Built by hand that is four times five, twenty connectors, every one of them custom.
| Setup | Connectors you build |
|---|---|
| 4 models × 5 tools, hand-built | 20 |
| 4 models + 5 MCPs | 9 |
Nine, because each model builds one MCP client and each tool exposes one MCP server. Four plus five. Nothing in that nine is custom to a particular pairing.
A lot of the agents we build run 15, 20, 30 MCPs. Hand-built, that is over a hundred connectors. Standardised, it is 15.
How the agent picks which tool to call
When a session starts, before you have typed anything, a document for every connected MCP is loaded into the initial system prompt: the list of tools it offers, and a description of how to use each one. The tool provider writes that document. Google built the Gmail MCP server, so Google wrote its instructions. When a request needs one of those tools, the agent calls it and uses what comes back for the next step.
That loading is also where it goes wrong. Run 30 MCPs and 30 of those documents sit in the context window before the first request, most of them describing actions this particular job will never call. And the agent chooses between them on the wording alone. Give it a search contacts tool and a search inbox tool whose descriptions read almost the same, and neither document says which one wins. It will pick one, and it will sound certain either way. The fix is never in the agent. It is rewriting one of the two descriptions so they stop competing.
How to build an MCP server for your own product
This runs the other way too. If you sell the software, if you are a CRM or a scheduling system, you build an MCP server and expose it, and agents integrate through that. The actions might be:
- Search contacts
- Send email
- Get calendar
Agents usually work out how to use those on their own, as long as the docs are written that way.
The part that gets missed is how the tools work together. To email a tenant about a lease renewal, the agent needs the email address first, and it does not magically know it. Your docs have to say: use the search tool to find the person’s email, then use the send email tool. Working through those chains, and every case the MCP will be asked to cover, is most of the job before anyone writes the MCP server itself.