What MCP actually changes about tool integration
The Model Context Protocol is often described as USB-C for AI tools. The more useful framing is that it moves the integration boundary.
The stock explanation of the Model Context Protocol is that it standardises how models talk to tools: USB-C for AI, as the analogy usually goes. True, and not very illuminating. The part that changed how I build things is subtler: MCP moves where the integration boundary sits.
Before: the boundary was inside your application
Wire a model to five internal systems without a protocol and the schemas, authentication, retries and error mapping all live in your agent code. Each new system means editing the agent. The agent accumulates knowledge of every service it touches, and the blast radius of any change grows with it.
That works fine for two tools. At a dozen, the agent has become an integration layer wearing a trench coat.
After: the boundary is a server you can deploy separately
With MCP the tool surface moves behind a server that advertises its own capabilities. The agent discovers what exists at runtime rather than being recompiled with the knowledge. Adding a capability means deploying a server, not editing the thing that reasons.
The immediate practical consequence is that tool ownership can follow team ownership. The team who owns the service owns the server that exposes it, which is the same reason we stopped putting every service’s client library into one shared monolith.
Where it gets genuinely hard: tenancy
Here is the part the protocol does not solve for you.
The moment a server is multi-tenant, every tool call needs to resolve which tenant’s data it may touch, and that identity has to survive the whole path: user, through agent, through protocol, into the server, into the query.
The tempting shortcut is to let the model pass a tenant identifier as a tool argument. Do not do this. A tool argument is model output, and model output is attacker-influencable. Tenant identity belongs in the authenticated session (an OAuth2 access token the server validates itself), never in the arguments.
Concretely, the split I keep coming back to:
- Arguments carry what the user is asking for
- The token carries who is asking and what they may see
- The server decides, every call, without consulting the model
Once identity is server-side, a whole class of failures stops being possible. The remaining errors tend to be honest ones: expired credentials, missing scopes, a service that is down. Those are much better problems to have than a model that talked itself into another tenant’s records.
What I would tell someone starting
Do not begin by exposing everything. Begin with the two or three capabilities that an agent actually needs, get authentication and tenancy right on those, and let the surface grow. A small correct tool surface beats a large one you cannot reason about.