A standard that nobody is excited about, that changes everything
Standards rarely produce excitement. ODBC didn’t get a keynote. USB-C took a decade to be appreciated. Most of the technology that actually matters is wire format — boring, agreed-upon, invisible most of the time. The Model Context Protocol is that kind of standard for the agent era, and the companies who internalize it now will spend the next five years writing 10% as much glue code as their competitors.
For the unfamiliar: MCP is a JSON-RPC protocol for exposing tools, resources, and prompts from a server to an LLM client. It is provider-agnostic. It is transport-flexible (stdio, SSE, HTTP, WebSocket). It is open. Anthropic shipped it; OpenAI’s tooling supports it; Google, Microsoft, and most of the agentic frameworks have adopted it.
The reason it matters is simpler than the spec. MCP standardizes the boundary between an agent and the world it acts on. Before MCP, every agent framework had its own definition of “tool,” its own auth model, its own discovery protocol, its own ways to fail. After MCP, those concerns are commodity. The tool you build once is callable by any compliant client, forever.
What this changes about how to design tools
Most teams I see still build “tools” as ad-hoc functions inside their agent codebase. The function lives in src/agent/tools/some_thing.py. It is implicitly coupled to the agent’s runtime, the agent’s auth model, the agent’s logging. Want to use the same tool in a different agent? Copy the file. Want to expose it to a second team? Send a Slack thread.
The MCP-shaped version of that tool is a server. The server exposes a stable schema, a stable auth, and a stable discovery surface. It runs in its own process. It logs to its own observability stack. It can be tested without standing up the agent. It can be used by ten agents and four humans and a CI pipeline, all on the same wire format.
The conceptual shift is from tools as functions to tools as services. Each tool gets its own life. The benefit is the same benefit microservices gave us in 2014, except the consumers are LLMs and the contracts are negotiated at runtime via JSON Schema.
The four architectural moves that matter
Once you accept MCP as the boundary, four design moves follow:
1. Tools live in their own repos when they’re shared
A tool that’s used by one agent can live alongside that agent. A tool used by three should be its own repo, deployable independently, versioned independently, with its own README. The repo cost is small and the coupling cost saved is large.
2. The agent runtime is thin
If your tools are MCP servers, your agent runtime is almost trivial: load the workflow, connect to the MCP servers, expose them to the model, dispatch calls. There is no “tool registry” inside your agent. There is no custom auth layer. The complexity sits in the servers, where it belongs.
3. Credentials live in a gateway, not in the agent
This one took us a while to internalize, but it’s important: MCP servers should not store OAuth tokens or long-lived API keys themselves. They should fetch short-lived credentials from a gateway at runtime. The gateway handles token refresh, rotation, and revocation centrally. This pattern means a single revocation in the gateway disables a credential across every agent in the system. We learned this the hard way; if you’re building MCP servers right now and the credential lives in an env var on the server, you’re going to regret it the first time a token rotates unexpectedly.
4. Observability is a first-class part of the tool
Every MCP server emits structured logs for every tool call: inputs (redacted), outputs (sampled), duration, cost (if model-backed), error. The agent doesn’t have to know how to log a tool call; the server logs itself. This makes “what did the agent do last Tuesday at 3pm” a database query, not a forensic exercise.
What this looks like in a real build
The shape we use in Custom AI Builds:
- A central gateway (we wrote one called Claude Gateway) that holds long-lived credentials for every third-party service the agents need.
- Each tool is an MCP server in its own repo, deployed to its own container. The container has only two env vars: the gateway URL and an API key for the gateway.
- The server fetches a short-lived token from the gateway when it needs one. If the upstream credential rotates, the gateway handles the rotation. The server doesn’t care.
- The agent runtime connects to all the MCP servers it needs via SSE. The connection is plain. The model sees a clean toolset.
- Observability flows from each MCP server to a central log store. Cost is metered at the gateway and at the model client. Both are tracked separately.
This is not exotic. It is straightforward, boring, and it scales. The first few systems we built without this shape required rewrites within six months. The systems built on MCP from day one have been running for over a year with marginal maintenance.
What this changes about hiring and vendor relationships
Two second-order effects matter:
Hiring. Engineers who understand MCP can ship a useful tool in a day. Engineers who don’t will reach for ad-hoc HTTP wrappers and ship something that works for one agent and breaks for everything else. When we hire for AI engineering work, “shipped at least one MCP server” is now a checkbox on the rubric.
Vendor selection. Any vendor selling you an “AI integration” should be MCP-compliant by default. If their product exposes itself as a tool to an agent via some proprietary protocol that requires their SDK, you are buying lock-in. The right question to ask any vendor is “do you ship an MCP server for this?” If the answer is no in 2026, that’s a serious problem.
Where MCP isn’t the answer
MCP is the right boundary between agent and tool. It is not the right architecture for:
- High-volume, low-latency inference paths. If you’re calling a tool a million times an hour, the JSON-RPC overhead matters; you want a tighter binding.
- Cross-agent coordination. MCP is agent-to-world. Agent-to-agent coordination needs something else (queues, shared state, an orchestrator pattern). Don’t try to make MCP do this.
- Stateful UI flows. MCP tools are RPC calls. If your interaction has long-lived UI state, that state lives somewhere else.
Knowing where MCP doesn’t apply is as important as knowing where it does.
The take
If you are building an AI system in 2026 and you are not exposing tools via MCP, you are creating future migration cost for no benefit. The protocol is stable enough to bet on, broad enough to cover the work, and boring enough to ignore once you’ve adopted it. Boring infrastructure is the best kind of infrastructure.
Our Custom AI Builds are MCP-native by default. If you have an existing agent with ad-hoc tools and you’re considering a refactor, schedule a call — we’ll tell you honestly whether it’s worth the move.
