Reference
What is MCP?
The Model Context Protocol is an open standard that lets an AI assistant call tools that you run. Instead of pasting data into a chat window, the assistant asks a server you control, that server does the work, and the result comes back into the conversation.
This page is written to be useful whether or not you ever buy anything from us. The section that matters most is the one about what MCP deliberately leaves to you, because that is the part that turns a working prototype into a production problem.
Where it came from
Published by one vendor, adopted by the others.
Anthropic published MCP in November 2024 as an open specification with a reference implementation, and through 2025 the other assistant vendors shipped support for it too. That second part is what turned it from one company's integration format into something worth building a server against.
The practical consequence is that a server you write once is reachable by more than one assistant, without a separate integration for each. It is also why the governance question further down this page became urgent rather than theoretical: the connecting part got easy in a single year and the deciding part did not move at all.
The parts
Four words you need, and no more.
| Term | What it means |
|---|---|
| Host | The application the person is actually using – the assistant. It decides which servers to connect to. |
| Server | The thing you run. It advertises a set of tools and answers calls to them. This is where your business logic lives. |
| Tool | One named operation with typed arguments, e.g. "read a slice of the plan" or "search documents". The assistant chooses which to call. |
| Transport | How host and server talk. Either a local process on the person's machine, or HTTP to a server you host. |
That is genuinely most of it. The protocol is small on purpose, which is why it spread quickly and also why the hard parts are left to whoever runs the server.
Why it caught on
It replaces copying with asking.
The data stays put
A tool call reads at the moment of asking. There is no index to build and no copy to re-permission when somebody changes access.
The answer is current
Anything read through a tool is as fresh as the system behind it, which matters when the question is "what changed since last week".
You keep the logic
What a tool does is your code. The assistant decides when to call it; it does not decide what it means.
The important part
What the protocol deliberately does not solve.
MCP standardises how a tool is described and called. It says nothing about who is allowed to call it. That is not an oversight – a protocol should not embed one company's idea of permissions – but it does mean the following are yours to build.
| Left to you | What goes wrong without it |
|---|---|
| Who is calling | Most reference servers are single-user. Wire one to a shared connection and every answer is attributable to the server rather than to a person. |
| What they may reach | A server that advertises a tool will run it for anybody who can reach the server. Access control is not part of the protocol. |
| What was reached | There is no audit requirement. If nobody built one, the honest answer to "what did it read last quarter" is that nobody knows. |
| Which environment | Nothing forces an answer to say where it came from, so a production figure and a test figure look identical in the conversation. |
| Revocation | Removing somebody's access is whatever you built. If it is a config file and a restart, it is not revocation. |
This is the honest reason MCP projects stall between prototype and production. The prototype takes an afternoon precisely because none of the above is required to make it work.
Building it yourself
When you should, and when it stops being worth it.
Build your own when
- One team, one system, one environment. The governance problem is small because the blast radius is small.
- Everyone who can reach it should reach all of it. Then per-person narrowing buys nothing.
- You want to learn the protocol. It is genuinely a good afternoon's work.
It gets expensive when
- Different people should see different rows. That is an entitlement system, not a feature.
- Somebody asks what was read. Retrofitting an audit trail with stable reason codes is not a small job.
- There is more than one environment. Every answer now has to name where it came from.
- Somebody leaves. Revocation has to be immediate and provable.
We sell one of these, so treat the second column with appropriate suspicion. The test is simple and vendor-neutral: write down what your server would do if a person who left on Friday called it on Monday, and whether you could prove afterwards what they reached.