One protocol, every
tool.
MCP turns N times M custom integrations into N plus M. That part is genuinely settled. What is not settled is everything that happens after you connect the second server: whose identity the tool acts under, how much of your context window the tool definitions eat, and what a compromised server can reach. This is the operations half.
The integration math is the whole point.
Every enterprise that has wired a language model into real systems has met the same wall. You write a connector for the CRM, then the model changes and you write it again. You add a second model for a different team and now you have two connectors per system. With N models and M systems you are maintaining something close to N times M integrations, each with its own auth, its own error handling, and its own quiet decay. This is the actual reason internal AI projects stall at the demo, and it has nothing to do with model quality.
The Model Context Protocol, an open standard Anthropic published in November 2024 and since adopted well beyond it, collapses that to N plus M. Each system gets one MCP server. Each model or agent host gets one MCP client. Any client can talk to any server, because the protocol standardises how tools are described, invoked, and returned. The comparison to a universal port is overused but structurally correct: the value is not the cable, it is that everyone agreed on the shape of the socket.
That much is settled and is covered from the architecture side in our piece on how MCP, RAG and agentic systems fit together. This piece is about what happens next, in production, once the diagram is real: the context cost of every tool you expose, the identity question that decides your entire security model, and the failure modes that only appear at the third or fourth connected server.
Three roles and two transports.
The architecture is deliberately small. A host application, your agent, your IDE, your internal copilot, embeds one or more MCP clients. Each client maintains a single connection to a single MCP server, and each server fronts one system and exposes three kinds of capability: tools the model can call, resources it can read, and prompts it can reuse. The one client to one server rule is what keeps isolation possible; a compromised server sees its own session and nothing else.
The transport choice is the first real deployment decision, and it is a security decision disguised as a plumbing one. Stdio runs the server as a local subprocess on the same machine as the host, which is simple, fast, and inherits the trust of whoever is logged in. Streamable HTTP runs the server remotely over the network, which is what you need for anything shared across a team, and immediately raises the questions stdio let you ignore: who authenticated, what are they allowed to do, and how do you know. Most enterprise pain traces back to teams prototyping over stdio and deploying over HTTP without revisiting a single assumption.
Every connected server rents space in the context window.
Here is the failure mode that surprises teams at the third server. Tool definitions are not free and they are not lazy. Every tool from every connected server is serialised into the request, on every single call, before the user's question is even read. A realistic enterprise MCP server exposes something like eight tools, and a well-written tool definition with a clear description and a typed schema runs several hundred tokens. Connect ten servers and you are shipping roughly fifty-six thousand tokens of preamble on every request.
Two honest qualifications, because the naive version of this argument is wrong. First, tool definitions render before the system prompt and the messages, which makes them the most cacheable thing in the request: with prompt caching a stable tool list costs a fraction of its face value on repeat calls, so the dollar figure is far smaller than the token figure suggests. Keep the tool list byte-stable and ordered deterministically or you will invalidate the cache on every request and pay full price for the privilege.
Second, and this is the part caching does not fix: the real cost is attention, not money. A model choosing between eighty tools chooses worse than one choosing between eight, and the degradation is quiet. You do not get an error, you get a slightly wrong tool picked slightly more often. The mitigation is deferred loading, where tools are marked so their definitions are not sent up front and the model retrieves the ones it needs through a tool-search tool. The context stays flat as you add servers, and selection accuracy stops decaying. Two rules if you turn it on: the search tool itself must never be deferred, and at least one real tool must stay loaded, or the request is rejected outright.
Whose permissions is the tool acting with?
This is the question that decides whether your MCP deployment is an integration layer or a privilege-escalation engine, and it is routinely answered by accident. When the agent calls read_customer, the server has to act as somebody. There are three ways it can go, and only one of them survives an audit.
Service account for everything
The server holds one broad credential and every user's request runs with it. It works on day one and it is the classic confused deputy: a junior employee's agent can now read anything the service account can read, and your logs show one identity doing everything. Fine for a read-only public data source, disqualifying for anything with row-level permissions.
Passing the user's token through
Tempting, and explicitly called out as an anti-pattern in the protocol's own security guidance. A token minted for your application should not be forwarded to a downstream service that was never its audience. It defeats audience validation, it makes revocation meaningless, and it turns any server you connect into a credential relay.
Per-user authorisation at the server
The remote server acts as a proper OAuth resource server: the user authorises it directly, it holds its own token bound to that user, and it enforces that user's real permissions on every call. More work, and the only model where the answer to "who did this" is a person rather than a robot. This is the one to build.
The practical test is simple and worth running before anything ships. Have two users with genuinely different permissions ask the agent the same question through the same server. If they get the same answer, your MCP layer has quietly become the most over-privileged service in the company, and it is now sitting between a language model and your production data.
Separate what reads from what writes.
- ·Failures are wrong answers, not wrong actions
- ·Safe to expose broadly once per-user permissions are real
- ·Main risk is data leaving through the answer, not the tool
- ·Scope by row and column, not by endpoint
- ·Log the query, sample the results
- ·Failures are refunds issued, records overwritten, emails sent
- ·Every write tool needs an explicit approval gate or a hard precondition
- ·Make writes idempotent and reversible, and give each one a request id
- ·Never expose a general-purpose write when a specific one will do
- ·Log the intent, the diff, and the approver
The single most useful design constraint we apply is that a write tool should be narrow enough to name honestly. Not execute_sql, which is unbounded and unreviewable, but issue_refund with an amount ceiling and an order id. A narrow tool is easier for the model to select correctly, easier for a human to approve, and bounded in the worst case. The generality that feels efficient when you are building the server is precisely the generality that makes an incident unbounded.
Servers change. Agents fail silently.
A conventional API breaks loudly: the client fails to compile, the contract test goes red, somebody gets paged. An MCP tool breaks quietly. Rename a parameter, tighten an enum, or reword a description, and nothing errors. The model simply starts calling the tool slightly less well, or stops choosing it, and the first signal is a support ticket weeks later saying the assistant has got worse. The tool description is load-bearing production code, and almost nobody treats it that way.
Pin the server version the agent connects to, and treat a description change as a version change. The description is the interface as far as the model is concerned.
Keep a fixed set of prompts with a known correct tool call for each, and run it on every server change. This is a tool-selection eval, and it catches description rot that unit tests cannot see.
Record which tool was selected, with what arguments, under whose identity, and what came back. Without this, debugging an agent is guesswork and an audit is impossible.
Watch the mix of tools chosen over time. A tool that quietly drops from twelve percent of calls to two percent has usually been broken by an edit, not abandoned by users.
The connective point with our evaluation work is direct: tool selection is a model behaviour, so it belongs in an eval suite, not in a smoke test. Everything we have written about evaluating LLM output applies here with more force, because a wrong tool call has side effects that a wrong sentence does not. Build the eval suite step by step.
Adopt for commodity systems, build for your own.
There is a growing supply of ready-made MCP servers for common systems, and using one is often correct. The judgement is about accountability and permission granularity rather than build effort.
Adopt when the system is standard and the server is first-party
A server published and maintained by the vendor of the system it fronts is usually better than what you would write, because it tracks that vendor's API changes. Read its auth model before you trust it, and confirm it supports per-user authorisation rather than a single shared key.
Build when permissions are yours to enforce
If who may see what is defined by your own business rules, no third-party server can enforce it. This is the common case for internal systems, and it is where a thin custom server that wraps your existing authorisation layer is both safer and simpler than it looks.
Build when the useful tool is narrower than the API
Wrapping a whole REST API as tools produces dozens of generic, badly-named tools that a model selects poorly. The better server exposes a handful of task-shaped tools that map to what people actually ask for, which is a design exercise, not a translation exercise.
Be careful with community servers on the write path
A third-party server you did not audit, holding a credential to your production system, with a description the model obeys, is a supply-chain question. Read the source, pin the version, and start it on the read surface.
Connecting a server from the model side is two halves, and the first time you do it the missing half is the usual error: declaring the server is not enough, you also have to declare the toolset that exposes its tools to the model, and a request with only one of the two is rejected as invalid. It is a small thing, and it is where most first integrations stop for an afternoon.
We start at the identity question, not the tool list.
Every MCP engagement we take begins by deciding whose permissions each server acts under, because that answer determines the transport, the auth model, and which tools can exist at all. Then the read surface ships before the write surface, write tools are narrow and gated, tool selection goes into an eval suite rather than a smoke test, and every call is traced to a person. We have been building on the protocol since it was published, connecting agents to ERP, CRM and internal tools.
→ See the MCP implementation serviceThe honest limits.
MCP standardises the connection, not the judgement. It does not make a model choose the right tool, it does not make your data model coherent, and it does not turn a system with no permission model into one that has permissions. If access control in the underlying system is weak, MCP will faithfully expose that weakness to an agent at machine speed, which is worse than the status quo rather than better.
The specification is also still moving. Transports, authorisation and tool discovery have all changed since the first release and will change again, so anything you build should treat the protocol layer as a dependency to be pinned and reviewed, not as bedrock. Concretely, that means versioning your servers, keeping the client library current on purpose rather than by accident, and not spreading protocol details through your application code.
And the honest scoping note: for one system with one model, MCP is overhead. Its value is the N plus M arithmetic, which only pays back when there is genuinely more than one of each, or when you know there will be. Adopting it for a single integration because it is the current standard is a real cost with a deferred benefit, and it is fine to say so.
Questions, answered.
01What is the Model Context Protocol (MCP)?+
MCP is an open standard, published by Anthropic in November 2024 and now adopted well beyond it, that defines how AI applications connect to external tools and data. A host application embeds MCP clients, each client connects to one MCP server, and each server fronts one system and exposes tools the model can call, resources it can read, and prompts it can reuse. The point is arithmetic: instead of building a custom integration for every model and system pair, you build one server per system and one client per model, turning N times M integrations into N plus M.
02How is MCP different from just calling an API?+
MCP does not replace your API, it standardises how a model discovers and invokes it. The differences that matter in production are that tool descriptions are consumed by a model rather than a developer, so wording is load-bearing; that every tool definition occupies context on every request, so the surface has a running cost; and that the caller is a probabilistic system, so a tool needs to be narrow enough that a wrong selection is survivable. A REST endpoint has none of those properties.
03Is MCP secure enough for enterprise use?+
The protocol is secure enough; most deployments are not, and the gap is almost always identity. The failure pattern is a server holding one broad service-account credential that every user's request runs under, which is a classic confused-deputy setup: a low-privilege user's agent inherits high-privilege reach and your audit log shows a robot rather than a person. Forwarding the end user's own token downstream is worse and is named as an anti-pattern in the protocol's security guidance. The model that holds up is per-user authorisation at the server, with the server acting as a proper OAuth resource server enforcing that user's real permissions.
04How many MCP servers can I connect before performance suffers?+
Watch tool count rather than server count. Every tool definition from every connected server is sent on every request before the user's question is read, so ten servers at eight tools each is roughly fifty-six thousand tokens of preamble. Prompt caching absorbs most of the dollar cost if the tool list is byte-stable, but it does not fix the real problem: a model selecting among eighty tools selects worse than one choosing among eight, and it degrades quietly rather than erroring. Past roughly twenty to thirty tools, use deferred loading with a tool-search tool so definitions are retrieved on demand and context stays flat.
05Should we build our own MCP server or use an existing one?+
Adopt for commodity systems where the vendor publishes and maintains a first-party server, since it will track their API changes better than you will. Build when the permissions are defined by your own business rules, because no third-party server can enforce authorisation logic it does not know about, and build when the useful tool is much narrower than the underlying API. Be most careful with unaudited community servers on the write path: a third-party server holding a production credential, with a description the model obeys, is a supply-chain decision.
06What is the difference between stdio and remote MCP transport?+
Stdio runs the server as a local subprocess on the same machine as the host, which is fast, simple, and inherits the trust of whoever is logged in, making it right for local developer tooling. Remote transport over streamable HTTP is what you need for anything shared across a team, and it introduces the authentication and authorisation questions stdio let you skip. The most common enterprise mistake is prototyping over stdio and deploying over HTTP without revisiting the trust assumptions that the local case made invisible.
07How do we stop an MCP tool from doing damage?+
Split the read surface from the write surface and treat them differently. Reads fail as wrong answers; writes fail as refunds issued and records overwritten. Every write tool should have an explicit approval gate or a hard precondition, should be idempotent and reversible, and should be narrow enough to name honestly: issue_refund with an amount ceiling rather than execute_sql. Narrow tools are selected more accurately by the model, reviewed more easily by a person, and bounded in the worst case.
08Why did our AI assistant get worse after we changed an MCP server?+
Almost certainly description drift. Unlike an API contract, an MCP tool has no compiler between it and its caller, so renaming a parameter or rewording a description produces no error. The model simply starts choosing the tool less accurately, and the first signal is usually a support ticket weeks later. Treat descriptions as production code: version the server, keep a fixed set of prompts with known-correct tool calls and run it on every change, and alarm on shifts in the tool-selection distribution.
Standardise the connection, then earn the trust.
Bring the systems you want an agent to reach and the permission rules that govern them. In one conversation we can usually tell you which need a custom server, which have one already, and where the identity model breaks.
Start a conversation →