Every agent we ship has two halves. One is the model, which reasons. The other is the set of connections that let it read from and act in the systems the business runs on: the ERP, the ticket queue, the ledger, the document store. Until recently the second half was the expensive one, because each connection had to be built from scratch. The Model Context Protocol, MCP for short, is the open standard that makes that half repeatable.
This is the version we give operators: enough engineering to make decisions, no more.
What the standard defines
MCP describes a conversation between two pieces of software. On one side is the host: the application the agent lives in, whether that is a chat interface, a coding tool, or a service that runs on a schedule. On the other side is a server: a small program that sits in front of one business system and describes, in a fixed format, what that system can offer.
A server can publish three kinds of things.
- Tools. Actions the agent may call, each with a name, a plain-language description and a typed schema for its inputs. “Look up an order by number.” “Create a draft invoice.” The schema is what keeps the model honest about arguments.
- Resources. Data the agent can read, addressed by a URI the way a page is addressed by a link: a document, a database view, a configuration file.
- Prompts. Ready-made instructions for common jobs with that system, which the host can offer to the user.
The protocol also fixes the dull parts that used to be reinvented every time: how the two sides introduce themselves and agree on what each supports, how a server runs locally as a process or remotely over HTTP, and, for remote servers, how a user signs in with a standard OAuth flow instead of a pasted API key. Every message is a small, structured request with a structured reply.
Notice what is not on the list. MCP has no opinion on which tools an agent should be permitted to call, on whose behalf it is acting, what happens when a call fails halfway through, or whether the data on the other end is any good. Those stay with you.
Why a shared contract changes the economics
Before a standard existed, each link between an agent and a company system was a custom build. It was written by whoever needed it first, maintained by whoever was left, and usually tied to the model vendor of the month. Changing the model meant rebuilding every integration. Changing the system meant finding out which agents broke.
With MCP the shape flips. The team that owns a system writes one server for it and maintains that. Every agent that implements the protocol, this year’s and next year’s, connects to the same server. That changes three things.
First, the description of a system lives in one place, with the people who understand it. Your finance team can own the finance server. That is where the knowledge of which field is the real due date belongs.
Second, the agent layer becomes replaceable: you can change models, or run several, without touching the integrations. We build model-agnostic for exactly this reason. The specification is public, the large model vendors all implement it, and no single company controls it any more. What you are committing to is a contract, not a supplier.
Third, every action is a discrete, typed call, so every action can be logged: which tool, which arguments, which result, when. That record is what lets you supervise the work rather than take it on faith.
One task, end to end
Take a support agent handling “where is my order?” Through one server it looks up the order. Through another it checks the carrier. It drafts a reply that points to both records. So far every call was a read, and a read-only agent can be allowed to run on its own.
Now the customer wants a replacement shipped. That is a write: it creates a shipment and spends money. The tool is marked as one that changes state, so the host pauses, asks a person to approve, and records the approval alongside the call. The agent did the legwork, a person made the decision that cost money, and the log shows both.
MCP made the systems reachable. The rule about which calls need a person is not in the protocol; it is yours to write.
Where the standard stops and your decisions begin
This is the part that gets skipped in vendor demos.
Identity. A server runs as somebody. A shared service account with broad access means every agent inherits that access and the audit trail says “the bot did it”. Prefer servers that act as the signed-in user, or scope service accounts per agent and per job.
Scope. You decide which tools a given agent can see at all. Fewer is better. An agent that summarises tickets does not need the tool that closes them.
Untrusted content. When an agent reads a document, an email or a web page through a server, the text may contain instructions aimed at the model. The protocol does not filter them. Treat everything that comes back from a tool as data, never as instructions, and keep anything that changes state behind a person’s approval.
Operations. A server is software. Someone hosts it, patches it and rotates its credentials. Decide who before it goes live, not after.
Tool quality. The model chooses tools by reading their descriptions. A vague description produces vague use. Reviewing a server’s tool list is a thirty-minute job that pays for itself.
Questions to ask a vendor
The phrase “MCP support” now appears on a lot of pricing pages. Ask the following and listen for specifics.
- Is it a server or a label? Which revision of the protocol? Remote over HTTP, or a local process we run ourselves? Which host applications have they tested it with?
- What exactly is exposed? Ask for the full list of tools and resources with their descriptions. If they will not show it, they do not have it.
- Which tools change data? Are they marked read-only, destructive or idempotent, as the specification allows, so a host can treat them accordingly? Can write tools be switched off?
- Who does it act as? OAuth for the signed-in user, or a long-lived key shared by everyone? Can permissions be scoped per agent, and what happens when an employee leaves?
- What gets logged, and where? Every call, with arguments and results, exportable to the audit system you already run.
- What data passes through their infrastructure? Retention, region, and whether tool results are used to train anything.
- What are the limits? Rate limits, pagination, and the size of a single result. Large results consume the agent’s working memory; good servers summarise or page.
- How are changes announced? Renaming a tool or altering its schema can silently break an agent. Ask for a versioning and deprecation policy.
- Is it priced as a feature or a tier? MCP access gated behind an enterprise plan is a cost line, not a checkbox.
Ask the AI platform vendors the mirror image. Can their agents connect to any compliant server, or only to a curated catalogue? How do they handle approvals and tool allowlists? And what happens when a document the agent reads tries to give it orders?
The first build
List the systems the company runs on and mark the ones whose vendors already publish a server. From that list, choose a job that exists only because two systems do not talk to each other: the weekly export, the figures copied from one screen into another. Give the agent read access and nothing else, set its permissions explicitly before the first run, and log every call. When the read-only version has earned some trust, add one write action, behind approval. Then widen the scope.
Mistakes at that stage are cheap, and the habits the team forms there (reading the log, questioning a tool’s scope, declining a write) are the ones that carry into larger deployments. It is also the order we build in: data and connections first, agents on top, and nothing the client cannot see and own.
If you would like a second pair of eyes on a vendor’s answers, talk to us.