MCP & Tool Interoperability
Why every worker agent hand-wiring its own copy of the order-lookup tool doesn't scale, and how the Model Context Protocol decouples tools from any one agent.
The Same Tool, Wired Three Different Times
The refund, shipping, and account worker agents all need to look up order details. Each one has its own hand-written integration to the orders API, with its own bespoke input handling, its own error-formatting conventions, its own copy of the validation logic from the last guide. When the orders API adds a new field, three separate integrations need updating. When the team evaluates switching part of the system to a different agent framework, none of that tool-integration code carries over — it's tightly coupled to whichever framework wrote it, exactly the vendor-lock-in problem Spring AI solves for LLM providers, except here it's tools, not models.
MCP: One Tool Implementation, Any Agent
The Model Context Protocol (MCP) standardizes how tools, data, and prompt templates get exposed to an agent, independent of which model or framework is consuming them. An MCP server exposes a set of capabilities once; any MCP-compatible client — a different agent, a different framework, even a different company's AI product — can consume that same server without custom integration code. The order-lookup logic gets written once, as an MCP server, and every worker agent becomes a client that talks to it through the same standard interface.
MCP defines three kinds of capability a server can expose, and it's worth knowing the distinction even though "tools" gets most of the attention:
- Tools — callable functions with side effects or computation, the
get_orderandissue_refundcalls covered in the previous two phases. - Resources — readable data a client can pull into context on demand: a document, a CSV, a log file — closer to the retrieval side of RAG than to function calling.
- Prompts — reusable, parameterized prompt templates a server can offer, so a well-tested "check refund eligibility" prompt lives in one place instead of being re-written slightly differently inside every agent that needs it.
The official MCP introduction and Anthropic's announcement post are the two clearest starting points — the introduction covers the protocol's actual mechanics (client-server architecture, capability negotiation), while the announcement makes the interoperability case in plainer terms.
What MCP Actually Decouples — and What It Doesn't
MCP solves the wiring problem: the same order-lookup capability, written once, usable from any compliant client without bespoke per-framework integration code. It deliberately does not solve the problems from the previous guide — a tool exposed over MCP still needs schema validation, business-rule checks, and sandboxing on the server side before it executes anything with a real effect. MCP standardizes how a client discovers and calls a tool; it says nothing about whether the arguments a client sends are safe to act on, which remains entirely the server's responsibility. Adopting MCP without also building the harness-layer validation from the last guide just means the same unsafe execution problem, now reachable from more places.
Check yourself
After migrating the order-lookup tool to an MCP server, does the business-rule validation from the previous guide (checking a refund amount against the order total) become unnecessary?
What's Next
Interoperable, validated tools handle a single request well. They don't yet handle a refund dispute that takes three days to resolve because it's waiting on a human reviewer, or a payment call that fails halfway through with no clear signal of whether it actually went through. That's the last guide in this phase.
Frequently asked questions
Do I need to rewrite all existing tools to adopt MCP, or can it be added incrementally?
Incrementally is the realistic path for most teams — wrap an existing tool integration behind an MCP server without necessarily changing its internal implementation, then migrate agents to consume it as MCP clients one at a time. The value compounds as more tools and agents move onto the same protocol, but there's no requirement to convert everything at once.
Is MCP specific to one model provider?
No — that's the entire point. MCP is a protocol, not a proprietary API, and multiple model providers and agent frameworks support it as clients, which is what makes it a genuine interoperability layer rather than another vendor-specific integration to maintain.
Does using MCP improve latency or reliability on its own?
Not inherently — it's an interoperability and reuse win, not a performance optimization. A slow or unreliable underlying tool implementation is just as slow or unreliable behind an MCP server as it was hand-wired directly into one agent; MCP changes how many places can reuse that implementation, not how well the implementation itself performs.