Every enterprise AI conversation eventually hits the same wall: the model is impressive, and it cannot see any of your systems. The answer to that wall increasingly has a name, MCP, and it is worth understanding precisely, because it changes what you should build and what you should refuse to build.
What MCP is
The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in November 2024, that gives AI applications a common way to connect to external systems, such as your ERP, your CRM, your file stores, and your internal APIs. Since its release it has been adopted across the major AI vendors, which is the fact that matters most for an enterprise buyer: an integration built on MCP is not a bet on one vendor's assistant. Build the connection once, and the AI tools your company has approved can all use it.
The problem it ends
Before a standard existed, connecting AI to enterprise systems meant one-off connectors: this assistant to that ERP, that copilot to this database. With N AI tools and M systems, you are staring at N × M integrations, each one bespoke, each one a separate security review, each one welded to a vendor's plugin format that may not exist in two years. Most companies responded rationally: they built one or two connectors, or none, and AI stayed disconnected from the data that would make it useful.
MCP collapses N × M into N + M. Your systems speak the protocol once, through an MCP server. Your AI tools speak it once, as MCP clients. Any compliant tool can then work with any connected system, subject to the permissions you set. That is why we say the one-off-connector era is over: not because connectors disappeared, but because they stopped being disposable.
How it works: what an MCP server does
MCP has a deliberately boring architecture, client and server, like most infrastructure that lasts.
On one side, an AI application (a chat assistant, an agent runtime, an IDE) runs an MCP client. On the other side, your systems sit behind MCP servers. A server exposes three kinds of things:
- Tools: actions the model may invoke, such as "look up this customer," "create a draft posting," "search the contract archive."
- Resources: data the model may read, such as documents, records, structured content.
- Prompts: reusable, parameterised instructions the organisation wants applied consistently.
The client connects to a server, discovers what it offers, and uses it within the permissions granted. That is the honest summary. The specification contains more, but nothing you need to understand before commissioning your first server, and any vendor who makes MCP sound complicated is selling the complication.
Why an enterprise should care
Three consequences follow from the architecture, and they are the actual business case.
Vendor mobility. Model quality leapfrogs every few months. If your integrations live inside one vendor's plugin system, switching assistants means rebuilding everything. If they live in MCP servers, switching assistants means pointing a different client at the same servers. The integration layer, usually the most expensive part, survives the churn.
Separation of concerns. Model vendors compete on models. Your integration layer is yours: it encodes what your systems are, what actions exist, and what is allowed. Keeping that layer vendor-neutral is the difference between owning your AI capability and renting it.
A single governance surface. When every AI-to-system connection passes through MCP servers you control, you get one place to enforce policy, instead of a different permissions model for every plugin in the building.
Governance patterns that hold up
The protocol standardises the connection. It does not exercise judgment for you. Governance remains your job, and a small set of patterns does most of the work:
- Read/write separation. Reads can be broad, because they carry little risk and most of the value. Writes are drafted by the agent and executed only after a human approval step, especially anything touching money or a system of record.
- Tool allowlists. Not every team gets every tool. Expose the minimum set per role, and expand deliberately.
- Scoped credentials at the server. The MCP server holds the credentials and enforces the boundary. The model never sees a password, and the blast radius of a bad prompt is capped by what the server permits.
- Log everything. Every tool call (who, what, when, with which arguments) lands in an audit trail. Done properly, AI through MCP is more auditable than humans copying data between windows, because nothing happens off the record.
If you adopt only one of these, adopt the first. "Read freely, write behind approval" is the single pattern that lets cautious organisations move fast without regretting it.
Honest trade-offs
MCP is young, and pretending otherwise helps nobody. The standard is still evolving, and early servers will need maintenance as it matures. Server quality varies enormously. An MCP server is software, and a badly written one is a badly written piece of software with access to your systems, so vet it like anything else you deploy. And a standard protocol does not make an agent smart: if a workflow does not benefit from a model's judgment, a plain integration is cheaper and more predictable. Part of our job is regularly telling clients not to put an agent somewhere.
Where to start
Not with a platform rollout. Pick one system and one process where disconnection visibly hurts; "answer questions from live ERP data" is a common first winner. Stand up one server, gate the writes, log the calls, and let a real team use it for real work. The patterns you establish there (approval flows, credential scoping, audit trails) become the template for every system that follows.
For what those patterns look like against a real ledger, see AI in ERP: what actually works. Once the layer exists, the next question is what to run on top of it, and whether to buy or build; our build vs buy framework for AI agents covers that decision. MCP servers can run on your own infrastructure or on a managed service such as our MCP platform. Either way, make sure the servers' configuration and any connector code you commissioned are yours under the contract, so changing hosts later does not mean rebuilding them.
Talk to us
If you are deciding where your first MCP server should sit, or reviewing one a vendor has proposed, talk to us. We are happy to look at a design and tell you where it would worry us.