MCP: why your next AI integration will not be a bespoke API
The Model Context Protocol has become the standard way to connect agents to systems. What changes, and what to govern before opening it up.
For two years, connecting an AI assistant to an internal system meant writing a bespoke integration for every pairing: this model with that ERP, that assistant with this CRM. The Model Context Protocol turned that work into a reusable connector.
What it is, in one sentence
MCP is an open standard defining how an assistant discovers and uses external tools — databases, APIs, file systems — without that connection having to be programmed for each model. You write the server once and it serves any client that speaks the protocol.
Adoption is not theoretical: the SDK passed 400 million monthly downloads, four times more than a year ago. When a standard grows like that, the question stops being whether to adopt it.
What changed in the 2026 revision
The 28 July 2026 version moved the protocol from a stateful model to stateless request-response. It sounds technical and has a very practical consequence: a stateless server scales like any ordinary web service. It goes behind a load balancer, replicates, and restarts without ceremony.
If you evaluated MCP a year ago and dismissed it on operational complexity, that evaluation has expired.
The part almost nobody plans for
An MCP server is a door into an internal system. Being standard does not make it safe, any more than HTTP makes a website safe. Before opening one in production:
- Centralised authentication. Who uses the server and under which identity, managed where you already manage everything else — Entra ID in a Microsoft shop — not with a key in a config file.
- An audit trail. Which tool was invoked, with which parameters, on whose behalf. Without this, the day somebody asks what the agent looked at, there will be no answer.
- Permissions per tool, not per server. An agent being able to read orders does not mean it should be able to cancel them. Granularity is designed up front, not after the scare.
- Rate limits. An agent in a loop can fire thousands of calls in minutes. Your internal system is not sized for that.
An MCP server on a developer's laptop is an experiment. One in production is another interface to your system, and it deserves the same governance as any API you publish.
Where to start
Do not start by exposing your ERP. Start with something read-only and obviously valuable: checking an order status, searching technical documentation, reading indicators. That teaches you the authentication and audit pattern without risking anything. Writing comes later.
And an architectural recommendation: do not build one giant MCP server that does everything. Build several small ones per domain. They version, deploy and retire independently, which is exactly what you will want a year from now.
