MCP quietly fixed the worst part of building agents
Before the Model Context Protocol, every agent-to-tool integration was a bespoke adapter. Notes from moving production systems onto MCP.
The least glamorous part of agent engineering was always the adapters. Every tool an agent could touch — ticketing, CRM, database, internal API — meant hand-writing a schema, a wrapper, auth handling, and error mapping. Then doing it again, slightly differently, for the next system. I have written more glue code in my career than I care to total up, and agent glue was the most repetitive of all of it.
MCP is the first thing that’s actually made a dent in that.
What it changes in practice
The Model Context Protocol standardizes how a model-side client discovers and calls tools on a server. The pitch sounds dry until you feel the consequence: integrations stop being your code.
When we added MCP client support to promptev, the integration surface flipped. Instead of us building and maintaining connectors for every system a customer might use, customers point their agents at whatever MCP servers they run — their database gateway, their internal APIs, their SaaS bridges. The tools show up with names, descriptions, and typed schemas. The agent can use them immediately. Nobody wrote an adapter.
The enterprise version of this matters even more. The teams that own systems get to own their MCP servers — including what’s exposed, to whom, with what auth. The agent team stops being a bottleneck through which every integration must pass. That org-chart change is worth more than the protocol itself.
What it doesn’t change
The parts of tool use that were always hard are still hard, and it’s worth being clear-eyed about them:
Tool descriptions are prompts. The model chooses tools based on names and descriptions, and a vague description produces vague tool choice regardless of protocol. We spend real eval time on “does the agent pick the right tool” — MCP standardized the plumbing, not the judgment.
Trust boundaries got sharper, not softer. An MCP server is third-party code feeding text into your context. A malicious or compromised server can return tool results carrying injection payloads. We treat every tool result as untrusted input: content isolation, output validation on what tools return, and approval gates on any write-action regardless of which server it came from.
Too many tools is still too many tools. Connect five servers exposing sixty tools and watch selection accuracy drop. We scope which tools each agent actually sees per task — the protocol makes connecting everything easy, and connecting everything remains a mistake.
Where I’ve landed
We now default to MCP for anything external: it’s the difference between “integration backlog” and “configuration screen.” The bespoke path still exists for latency-critical internal calls where a protocol round-trip isn’t worth it.
Standards win when they make the boring path the right one. This one does.