For most of 2024, every agent project we touched ended up with a folder called something like tools/: hand-rolled function definitions, ad-hoc JSON schemas, a wrapper class per integration, and a tangle of retry and timeout logic re-invented per project. The Model Context Protocol is the first credible attempt to replace that folder with a real interface. Most teams still treat it as a developer convenience. We are starting to treat it as the production interface between the agent and the systems it touches.
What changes when MCP is the contract
When the agent talks to your databases, your search index, your ticket system, and your billing API through MCP servers, four things stop being your problem and start being the server's problem.
Tool definitions stop being hand-written prompts. They are produced by the server, versioned by the server, and discovered by the agent at runtime. The agent's prompt is no longer the source of truth for what a tool can do.
Auth stops being a per-tool concern. The server owns the credential boundary. The agent never sees the API key, the database password, or the OAuth refresh token. The blast radius of a compromised prompt drops by an order of magnitude.
Schema drift stops being silent. When the billing API changes, the MCP server's response schema changes with it. The agent fails loudly on the next call, not silently three weeks later when nobody notices the empty field.
Retry, timeout, and rate-limit logic stops being copy-pasted across tool wrappers. It lives in the server, where it belongs, with the rest of the integration's operating concerns.
Where the factory rule applies
The MCP server is a piece of production software, not a glue script. It deserves the same operating kit every other production system in our handover gets: an eval suite that exercises the tools against realistic inputs, a runbook for what to do when the server returns malformed responses, a decision log for why each tool exists, and an owner.
The mistake we are watching teams make is treating MCP as the agent's problem. It is not. The MCP server is a production service that the agent happens to be the only client of right now. Build it like one.
What we will not do with MCP yet
We will not put a write-capable MCP server in front of a long-horizon agent without a verifier in the loop. The blast radius of a confidently wrong tool call inside a multi-step agent is larger than most teams have modelled.
We will not expose the entire SQL surface of a production database as an MCP tool, even though the demos make it look easy. The eval cannot defend the outcome, and the model will eventually run a query nobody wanted at 3 a.m.
We will not let the MCP server be the place where security review gets skipped because "the AI calls it." If a human service calling the same endpoint would need scoped credentials and an audit log, the agent needs the same.
Why this matters before it is mainstream
MCP is roughly where REST was in 2008: real, useful, increasingly common, and still mostly being deployed as if it were a side project. The teams who build it as a production interface now — with evals, ownership, and a runbook — will spend the next two years operating cleanly. The teams who treat it as glue will spend those two years debugging the seams.