The Bottleneck Was Never the Model
Ask most companies why their AI pilot stalled, and the answer is rarely about the model.
The model could reason well enough. What it couldn't do was read the contract in the document management system, check stock in the ERP, look up the customer's history in the CRM, and write the result back — reliably, with permissions intact, every time.
Reasoning is largely a solved commodity. Access is the constraint. And access is where most agent projects quietly turn into integration projects.
The N×M Problem
Before there was a standard, every agent-to-system connection was bespoke.
If you had four agents and six internal systems, you were maintaining up to twenty-four custom integrations. Each one had its own authentication handling, its own error semantics, its own idea of how to describe what it could do. Change the ERP's API and you patched every agent that touched it.
This is the same problem the industry has solved several times before in other domains — device drivers, database connectivity, language servers in code editors. The solution always has the same shape: stop building point-to-point connections and agree on a protocol in the middle. Then N×M integrations become N+M.
The Model Context Protocol (MCP) is that protocol for AI agents. Introduced by Anthropic as an open standard and now implemented well beyond it, MCP defines how an AI application discovers and calls the capabilities that external systems expose.
What MCP Actually Standardises
MCP is a client-server protocol. Your AI application is the host, containing one or more clients. Each client connects to an MCP server — a thin adapter that sits in front of a system and describes, in a machine-readable way, what that system can do.
The server exposes three kinds of primitive:
- Tools — actions the agent can invoke: create an invoice, search contracts, check inventory. Each carries a schema describing its parameters, so the agent knows how to call it correctly rather than guessing.
- Resources — data the agent can read. A document, a database record, a file tree. Addressable and retrievable without side effects.
- Prompts — reusable instruction templates the server offers for common tasks against that system, so domain knowledge lives with the connector rather than being re-invented in every agent.
The important consequence is that capability description becomes the server's job, not the agent's. An MCP server for your ERP is written once, by whoever understands the ERP, and every agent in your organisation can use it.
Why This Changes Enterprise Architecture
The architectural shift is small to describe and significant in practice: integration becomes a reusable asset instead of a per-project cost.
A few things follow from that.
Connectors outlive agents. Agents are cheap to rewrite and will be rewritten often as models and requirements change. An MCP server for your document store is stable infrastructure. Separating the two means model churn stops threatening your integration layer.
One integration surface to secure. Instead of auditing credentials scattered across agent codebases, you have a defined boundary per system. Authentication, scoping, rate limiting, and logging live in the server.
Capability inventory becomes possible. When every system exposes itself through the same protocol, you can actually answer the question "what can our agents do?" — which is a governance question long before it is a technical one.
Vendor coupling drops. A connector written against a protocol rather than a specific agent framework survives a change of framework or model provider.
What a Good Server Looks Like
The mistake teams make on their first MCP server is mirroring the underlying API one-to-one — exposing forty endpoints as forty tools and calling it done.
That produces a technically correct server that agents use badly. A better server is designed around tasks, not endpoints.
Compare two designs for the same ERP:
| Endpoint-mirroring design | Task-oriented design |
|---|---|
| Five separate lookups for customer, orders, order lines, shipments, invoices | One tool: retrieve a customer's order history |
| Agent chains five calls and may get the sequence wrong | One call, correct joins guaranteed server-side |
| Failure modes multiply with every call | Failure handled in one place |
The task-oriented server does more work internally and gives the agent far fewer ways to go wrong. Practical guidelines:
- Name tools for intent, in the vocabulary your business already uses.
- Write descriptions for a competent newcomer. They are read by the model and are the primary determinant of whether a tool gets used correctly.
- Return errors that suggest a next action, not raw stack traces. "Customer not found — try searching by name" is actionable; a bare 404 is not.
- Keep responses lean. Every unnecessary field consumes context the agent needs for reasoning.
- Separate reads from writes. Distinct tools, distinct permissions, distinct audit treatment.
Access Control Is the Hard Part
MCP standardises how capabilities are described. It does not decide who is allowed to use them — and that is where enterprise deployments actually get difficult.
Three questions to settle before a server touches production data.
Whose permissions apply? An agent acting on behalf of a specific user should inherit that user's rights, not hold a service account that can see everything. Service-account convenience early on is the most common way agent projects acquire a permissions problem they cannot later untangle.
What is the blast radius of each tool? A read tool against a reporting replica and a write tool that issues payments belong in different risk categories, with different approval requirements. Treating them uniformly means either over-restricting the harmless or under-restricting the dangerous.
Is the trail sufficient? Every invocation needs to be attributable — which agent, on whose behalf, with what arguments, producing what result. For regulated Swiss and European environments this is not optional, and retrofitting it is considerably harder than building it in.
Data residency does not disappear because a protocol is involved, either. The MCP server is exactly where you enforce that a document never leaves a given jurisdiction — a control point worth designing deliberately rather than discovering later.
Where MCP Stops
MCP is a connection protocol. It is not an agent framework, and it is not orchestration.
It says nothing about how work is decomposed across multiple agents, how state persists through a long-running process, how retries and compensating actions are handled, or how you evaluate whether an agent did its job well. Those remain your design decisions — our AI orchestration services address the layer that sits above the connection layer.
Being clear about this boundary is useful. MCP removes a category of undifferentiated integration work. It does not remove the need to think about process design, and a team expecting otherwise will be disappointed by an otherwise sound protocol.
How to Start
The failure mode here is a six-month platform programme that connects everything and ships nothing. Invert it.
- Pick one workflow with real friction — something people currently do by copying data between two systems.
- Build the smallest server that supports it. Two or three task-oriented tools, read-only if the workflow allows.
- Run it in shadow mode. Let the agent produce output that a human compares against the current process, without acting on it.
- Add write access to one tool once shadow output is consistently correct, with an approval gate in front of it.
- Only then generalise. Your second server will be better, because the first taught you what your agents actually ask for.
Each step yields something usable, and the sequence produces working integrations rather than an integration strategy.
The organisations that get durable value from agents will not be those with the largest models. They will be the ones whose systems are cleanly reachable, properly scoped, and fully auditable — because the model tier will change again next year, and the integration layer will not.
Connecting agents to systems that were never designed for them is most of the real work. Explore our live showcase of production deployments, or talk to our team about what an agent-accessible architecture looks like for your stack.