MCP: What a Standard Tool Protocol Changes, and What It Doesn't

A standard protocol for connecting agents to tools solves a real problem, and it's worth being precise about which one — because the problems it doesn't solve are the ones teams keep expecting it to.

The Model Context Protocol standardizes how an agent discovers and calls tools exposed by a server: a common wire format for listing tools, invoking them, and returning results. It's an integration standard, in the way that a database driver interface is.

What genuinely changes

Integrations become portable. A tool server written once works with any client speaking the protocol. Previously, connecting an agent to a system meant writing an adapter shaped to whatever framework you'd chosen — and rewriting it if that changed. That coupling goes away, which also makes framework choice less consequential.

Tool surfaces become inspectable at runtime. Discovery is part of the protocol, so a client can enumerate what a server offers rather than having it hard-coded. This makes late binding and per-user tool sets practical.

The ecosystem compounds. A server built for one purpose is usable by anything. This is the network effect that matters and the reason to care about a standard existing at all.

Ownership boundaries get cleaner. The team that owns a system can own its tool server and version it independently. A well-defined seam beats a shared adapter maintained by whoever needed it most recently.

What doesn't change

Tool design is still all yours. The protocol carries your descriptions, parameter names, and result shapes without improving any of them. A badly described tool is badly described over any transport. Everything about granularity, schema tightness, error text, and result formatting is exactly as hard as before — and it remains where most agent quality actually comes from.

Selection accuracy still degrades with list length. Easier connection means it's now trivial to attach dozens of tools, and the model's job gets harder as you do. → The convenience creates a pressure worth resisting: connect what the task needs, not what's available.

Permissions are still your problem. A protocol call is a capability. Which server an agent may reach, with which credentials, on whose behalf, remains an architectural decision. The confused-deputy question — is the tool checking the agent's authority or the requester's? — is untouched by standardizing the wire format.

Untrusted content is still untrusted. Tool results arriving over a standard protocol are exactly as capable of carrying injected instructions. ⚠️ If anything the risk rises with easy connection: more servers, more content sources, more surface, and less visibility into what any given one returns.

Latency and cost are unchanged. Same calls, same context, same token spend.

The practical questions before connecting a server

✅ Worth answering for each one, especially third-party servers:

• What are its tools' far-end effects? A server can expose anything. The name tells you nothing.
• What credentials does it hold, and whose authority do they carry?
• What does it return, and how large? A server returning full documents will blow your context and your budget.
• Is its content trusted? A server that fetches from the open internet returns attacker-controllable text into your agent's context.
• Who maintains it, and how do tool definitions change? A definition changing under you shifts behavior with no deploy on your side — worth pinning or reviewing.

That last one deserves emphasis: with local code, a tool description change is a diff in code review. With a remote server, it can change without you noticing. Treat tool definitions as a dependency with a version.

How it changes the build-or-buy calculus

Framework lock-in was one of the stronger arguments for adopting a big framework early, and this weakens it. If integrations are portable, a plain loop plus a protocol client has access to the same ecosystem, and switching later costs less.

The remaining reasons to adopt a framework — durable execution, tracing, approval flows — are unaffected. Which is a healthier decision to face, since those are concrete infrastructure rather than ecosystem anxiety.

The takeaway

A standard tool protocol solves distribution and portability: write a tool server once, use it anywhere, discover capabilities at runtime. It doesn't solve tool design, selection accuracy, permissions, untrusted content, or cost — the things that determine whether an agent works. Adopt it for the plumbing, then do the same careful work on descriptions, schemas, scoping, and trust that you'd have done anyway.