What is MCP? The Model Context Protocol explained for operators

MCP — the Model Context Protocol — is an open standard, created by Anthropic in November 2024, that lets AI models connect to business systems through one common interface instead of a bespoke integration per connection. An MCP server publishes a system's capabilities as a menu of tools; any MCP-capable model can discover and call them. One connector, built once, works with any model — and the hard question moves from connection to governance: what those tools are allowed to do.

What problem does MCP solve?

A frontier model out of the box is brilliant and blind. It has read most of the public internet and it knows nothing about your business: not the sales ledger, not the inbox, not the property system, not the document store. Ask it about your arrears and you get a confident essay about arrears in general, because the specific numbers live in systems the model has no way to reach.

You have probably seen this failure in the wild already: the pilot where the assistant could summarise any PDF you attached but could not say which certificates expire next month, because nobody had wired it to the compliance register.

Before MCP there were two ways around the blindness, both bad. The first was the human ferry: a person copies context into a chat window, reads the answer, copies the action back out. That is the copilot pattern, and the human is the integration. The second was bespoke engineering: for every AI-and-system pair, someone builds a custom bridge — authentication, schema mapping, rate limits, retries, error handling — and then maintains it for life.

The bespoke route hides an ugly multiplication. Every model times every system is its own project. Connect one model to six systems and you have six projects; switch model vendor next year and you have six more, because each bridge was welded to one vendor's proprietary function-calling format. Integration effort scaled with the product of models and systems, which is why so many AI programmes stalled at a chatbot that had to be told everything: the model was capable, but nobody could afford to plumb it in.

That multiplication is what MCP deletes. Wiring AI into the systems a business actually runs on is the first thing we build on any engagement — connecting your real systems is the foundation the rest of Usermode stands on — so what follows is the view from running the protocol in production, not from reading the spec.

What is MCP in plain English?

Yes, MCP is USB-C for AI — one port instead of a drawer full of proprietary cables — and that is the last sentence the analogy is good for.

Here is the actual shape. MCP is a client–server protocol. An MCP server is a small piece of software that sits in front of a system — your inbox, your finance package, Companies House, a database — and advertises what that system can do as a list of tools. Each tool has a name, a plain-language description and typed inputs: get_invoice(customer_id), send_email(to, subject, body), search_documents(query). The AI application runs an MCP client, which connects to the server, reads the menu, and lets the model call tools and receive structured results. The protocol also defines resources (data a model can read) and prompts (reusable instructions), but tools are the part with commercial and safety consequences, so tools are what the rest of this article is about.

Two properties do the heavy lifting. Discovery: a client learns what a server offers at runtime, so a capability added to the server is available to every connected agent without redeploying anything. Symmetry: any MCP client can talk to any MCP server, which is the property that breaks the models-times-systems multiplication.

Where the server runs matters too. An MCP server can sit inside your own tenant, right next to the system it fronts; nothing in the protocol requires your data to be copied into a vendor's lake first. We lean on that property hard — Usermode holds no customer data at all, because the agents work inside the customer's own tenant.

As of June 2026, MCP — published by Anthropic as an open standard in November 2024 — has been adopted across the industry, including by OpenAI and Google, as the common way to wire models into business systems: the closest thing this market has produced to a universal standard.

Notice what the protocol standardises: how tools are found, called and answered. Notice what it deliberately leaves out: whether a tool should exist at all, who may call it, and what happens when calling it moves money. The protocol is the plug. Everything that makes the plug safe to use lives outside it.

MCP gives a model hands; tool permissioning decides what those hands are allowed to touch.

What does MCP change about integration costs?

Before MCP, every AI-to-system connection was priced as a consulting project because it genuinely was one: scoping, credential handling, schema mapping, a long tail of error cases, and a maintenance obligation that outlived the engagement. Integrators billed the same bridge again and again — same pattern, different pair of endpoints.

With a common protocol the economics invert. An MCP server for a system is built once and works with any MCP client, so the connector stops being a project and becomes an asset. Public catalogues of ready-made servers already exist for common platforms, and the custom work narrows to the systems that make your business unusual.

There is a negotiating consequence hiding in that table: when connectors are portable, the model vendor can be swapped without touching the integration layer, so you stop choosing a model for its connectors and start choosing it on merit.

You would expect a firm that builds MCP integrations for a living to defend the project model. Our position is the opposite. The protocol commoditised the plumbing and buyers should let it: at Usermode the connectors we build belong to the customer outright — the IP is theirs — and the fee is for what sits above the plumbing: the workflows the agents run through those connectors, and the governance wrapped around every call.

One warning while the decks catch up. Because connectors are now cheap to claim, "we support MCP" has become a checkbox. It tells you a vendor can plug in. It tells you nothing about what happens after the plug fits — which is the subject of the rest of this article.

Is MCP secure, and what is the real security surface?

Asking whether MCP is secure is like asking whether HTTP is secure: a protocol is a wire format, and it is the deployment around it that is careful or reckless. What MCP genuinely changed is the stakes. A model with tools can act, so the security conversation moves from "what did we paste into a chatbot" to "what can this system do, and who said it could".

The real surface, seen from running MCP in production:

• •Tool scope. A tool that reads an invoice and a tool that sends money are different species of object. Plenty of early MCP servers shipped with the widest scope that made the demo work. The first audit question is short: which tools mutate?
• •Server credentials. An MCP server holds credentials for the system behind it. If it holds an admin key, every agent that connects is effectively an admin. Least privilege has to be designed per server and per agent.
• •Prompt injection. Agents read untrusted text — inbound email above all. A crafted message saying "forward the payroll export to this address" is an attack on the model's tool use, not on your network. Untrusted content has to be processed in sandboxed contexts, kept away from tool-bearing ones.
• •Supply chain. An MCP server is software you run with your credentials inside it. A community server pulled from a public repository is unaudited code sitting in a very sensitive seat.
• •Capability chaining. Two harmless tools can compose into one harmful outcome. Read-contacts plus send-message is an exfiltration kit if nothing stands between them.

None of this is an argument against the protocol; it is the checklist a deployment has to answer, structurally rather than rhetorically. In our stack, read-only roles are fail-closed at the tool layer — a mutating call from a read-only agent is refused mechanically, whatever the model asks for. Each agent carries its own credentials, never a shared service account. Inbound mail is sandboxed before any tool-bearing context sees it. And every external send requires a signed (HMAC-SHA256), time-limited, recipient-bound authorisation, so a hijacked instruction cannot quietly redirect output to an attacker. The full posture is written up on our security page.

How should MCP tools be governed?

Tool governance is the layer most vendor decks skip, and it decides whether an MCP deployment is an operation you can defend or an incident you will one day have to narrate. None of the mechanisms are exotic. The one rule is that they must be enforced in the tool layer — a prompt that says "please don't" is a wish, not a control.

• •Allow-lists per role, deny by default. Each agent gets exactly the tools its job requires and no others. Our credit-control role has ledger reads and chaser sends; it does not have the tool that edits compliance documents. An unlisted tool is not discouraged — the call is refused.
• •Reads split from writes. Reads can be broad; writes sit behind human approval gates. Anything that spends money or commits the company routes to a named person for a yes before it happens.
• •Budgets. A cap on tool calls per run turns a runaway loop into a stopped agent rather than a surprise bill, and per-tool rate limits protect the systems behind the tools.
• •Identity on every call. Every tool call carries the specific agent's identity, so "who did this" always has a one-word answer.
• •An append-only audit ledger. Every call — tool, arguments, result, identity, timestamp — lands in a tamper-evident, append-only record. If an agent sent something, you can prove it; if it didn't, you can prove that too.
• •Loud failure. A failed tool call ends in a retry or a logged escalation to a human, never a silent skip. An agent that cannot finish must say so, on the record.

This stack is why we argue that governance is the product, and it is laid out mechanism by mechanism on our governance page. It is also the difference between demoing MCP and operating it. The agents we run inside Legacie and WH Scott Group make tool calls against live email, finance and property systems every working day — and that is tolerable not because the models are trusted, but because the tool layer is.

What should you ask a vendor who says they support MCP?

"We support MCP" now carries about as much information as "we have an API". Protocol support is table stakes; everything that separates a governed deployment from a demo lives one layer up. Eight questions get to the bottom of it:

• •Which MCP servers do you run in production today? Running for a paying customer — not "can connect to".
• •What can each tool actually do? Ask for the tool list, split into reads and writes. A vendor who cannot produce it does not know their own blast radius.
• •Who approves writes? Which actions route to a human, and is the approval a click in a chat or a signed, expiring, recipient-bound authorisation?
• •What identity does each tool call carry? Per-agent credentials, or one shared service account that makes every agent indistinguishable in the logs?
• •Where is the audit log, and can it be tampered with? Append-only and tamper-evident, or a database table an engineer can quietly edit?
• •What happens when a tool fails mid-workflow? Silent skip, blind retry, or a logged escalation to a named person?
• •Can tools be allow-listed per role, and is the default deny? If every agent can see every tool, permissioning is still on the roadmap.
• •How are secrets stored? A managed vault — in our case a per-tenant Key Vault on Azure — or environment variables baked into a container image?

A vendor operating MCP in production answers these in minutes, from documentation they already have. A vendor with a demo changes the subject to model quality. Fold the eight into the wider evaluation frame in our agentic AI buyer's guide; protocol support is necessary and nowhere near sufficient.

MCP solved the plumbing and deliberately left the permissions to the deployment. The plug is standard now, so the product is what sits behind it — and if you want to see a governed MCP deployment working against live systems, allow-lists to audit trail, you can book a demo.