Why MCP changed how we ship agents — and why we're not going back.

Six months ago, every agent we built came with the same problem: integration. Connecting an agent to Salesforce meant writing custom glue code. Connecting it to a client's internal ticketing system meant writing more glue code. Connecting it to their data warehouse meant writing yet more glue code. Each new tool was a new project, and each new client meant rebuilding most of it from scratch.

Then we started shipping with Model Context Protocol, and almost overnight that whole class of work disappeared.

This isn't a tutorial. There are good ones already — Anthropic's official docs are surprisingly readable. This is a field report on what changed for us when we adopted MCP across three production engagements, what the docs don't tell you, and why we now refuse to start an engagement without it.

The promise — and what it actually delivered

The pitch for MCP is simple: it's a standard protocol for connecting AI models to tools, data sources, and external systems. Instead of writing custom integration code for every (model, tool) pair, you write an MCP server once and any MCP-compatible model can use it. Think of it as USB-C for agent tooling.

The reality matched the pitch within about two weeks of adopting it. Here's what we measured across our last three engagements compared to the three before:

• Time to first working tool integration dropped from 3-4 days to about 4 hours
• Lines of integration code went from ~800 per integration to ~120
• Cross-engagement reusability went from "basically zero" to "we use the same internal MCP servers across every client"

That last point is the one that mattered most. We have an internal library now of about a dozen MCP servers we've built — for common things like document parsing, structured data extraction, and webhook routing. Every new engagement starts with that library already available. We're not rewriting the same code for the fourth time.

What the docs don't tell you

The official MCP documentation will get you to a working server in an afternoon. Here's what nobody tells you about running them in production.

1. Start with read-only tools first

The first MCP server you build for a client should expose only read operations. No writes, no deletes, no API calls that have side effects. Why: because the first week of any agent deployment is when the agent is most likely to do something stupid, and "stupid + write access" is how you make headlines for the wrong reasons.

We learned this on our second engagement when an early-stage agent decided to "helpfully" close a batch of support tickets that hadn't been resolved. The fix took an hour. The trust took longer to rebuild.

2. Tool descriptions matter more than tool code

The single biggest factor in whether an agent uses a tool correctly is the tool's description, not its implementation. We now spend more time iterating on tool descriptions than we do writing the tools themselves. Be specific. Use examples. Tell the model when not to call the tool — that's often more valuable than telling it when to call it.

3. MCP servers should be boring

Resist the urge to make your MCP servers clever. They should be thin wrappers around existing APIs that do one thing each. The cleverness belongs in the agent, not the tool. Boring tools that do exactly what they say are infinitely more debuggable than smart tools that do something slightly different depending on context.

The moment it clicked

About three weeks into our logistics dispatcher engagement, we connected the agent to its third tool — a simple MCP server that read live weather data. It took 40 minutes from "we need this" to "it's running in production." No new model code. No custom integration layer. Just point the agent at the new MCP server and tell it the tool exists.

That was the moment MCP stopped feeling like infrastructure and started feeling like the operating system for agents. Adding capabilities became a tool problem instead of an engineering problem. The agent's "what it can do" surface became something we could expand on a meeting-by-meeting basis with the client, instead of a sprint-by-sprint basis.

The agent's capabilities became something we could expand in meetings instead of in sprints. That's the shift.

What we're not going back to

Custom integration code, per-client glue layers, the endless rewrite of "talk to Salesforce" for every project that needs to talk to Salesforce. None of it. We have one MCP server for Salesforce now. We use it across every engagement that touches it. When Salesforce ships an API change, we update one server, not seven projects.

If you're building agents in 2026 and you're not on MCP yet, the question isn't whether to switch — it's how much technical debt you're willing to keep paying every week until you do.