Before Model Context Protocol (MCP), connecting an AI model to an external tool meant writing a custom integration. Connect five models to ten tools and you’re maintaining fifty separate connectors — each one fragile, each one breaking on its own whenever either side gets updated. Anthropic released MCP in November 2024 to fix this. It reduces the integration count from M×N (models times tools) to M+N (models plus tools) by introducing a standard protocol any AI model can use to reach any compliant tool. That arithmetic shift is the technical substance behind the USB-C analogy you’ll hear associated with MCP. It’s also what makes the protocol architecturally significant rather than just convenient. Our MCP guide covers the broader landscape — this article explains how the three-component architecture actually achieves that reduction, why MCP won the protocol competition against UTCP, and what “de facto standard” concretely means by 2026.
What is the M×N integration problem MCP was built to solve?
Without a common protocol, each of M AI models has to be individually wired to each of N tools or data sources, producing M×N distinct connectors. The problem isn’t just the initial build. Every connector encodes assumptions about a specific model’s function-calling format and a specific tool’s API schema. When either changes — and both change often — that connector breaks independently of all the others.
Put numbers to it. Five LLMs connected to ten enterprise tools requires 50 custom connector implementations. Adding an eleventh tool means writing five new connectors. Switching one model means rewriting ten integrations. It adds up fast, and none of that work is reusable.
With MCP, the arithmetic changes. Each tool writes one MCP server; each model writes one MCP client. Total implementation count: 5 + 10 = 15. Adding an eleventh tool means writing one MCP server, and it’s immediately available to all five existing models. The M+N gain also compounds at runtime — because discovery is standardised, a host application connects to a new MCP server without any code changes at all. Zero host-side work per new integration.
The USB-C analogy earns its place here. Before USB-C, every combination of device type and port type needed its own cable — the same combinatorial explosion in physical hardware. USB-C standardised to a single connector. MCP applies the same architectural logic to AI-tool integration. The analogy has limits though: MCP carries a richer security surface than a physical connector standard. A malicious or misconfigured MCP server can expose tools to over-permissioned AI invocations in ways a USB cable simply cannot. The M×N reduction is the foundational claim in our MCP guide.
How does MCP’s three-component client-server architecture actually work?
MCP is a three-part model. Here’s how it breaks down.
MCP Host is the AI-facing application environment: Claude Desktop, VS Code, Cursor, a custom agent runtime. The Host embeds or interfaces with the LLM, decides which MCP servers to connect to, and orchestrates one or more MCP Clients.
MCP Client is a protocol-layer component embedded within the Host. Each Client maintains a 1:1 connection to a single MCP Server and translates Host instructions into JSON-RPC 2.0 messages. This is the layer where the M+N model is operationally realised — each Client speaks the same protocol regardless of what tool or data source is behind the server it connects to.
MCP Server is a lightweight process that wraps an existing tool, API, or data source and exposes it via the protocol. It advertises a capability manifest — tools, resources, and prompts — and executes invocations when called by a Client. The Server is also the primary security enforcement boundary: it controls what capabilities are exposed and to whom. The full threat surface is covered in the SAFE-MCP security framework.
If you’ve worked with the Language Server Protocol (LSP), this architecture will feel familiar. IDE ↔︎ language client ↔︎ language server maps directly onto MCP Host ↔︎ MCP Client ↔︎ MCP Server. MCP’s specification explicitly draws on LSP.
The data layer is JSON-RPC 2.0 — transport-agnostic, bidirectional, and language-agnostic at the wire level. REST wasn’t used because it’s HTTP-bound and request/response only. The transport layer offers two options: stdio for locally-spawned processes, and SSE (Server-Sent Events, via HTTP) for remote or cloud-hosted servers.
What is the JSON-RPC tool call flow from prompt to result?
With the three components in place, the execution path from prompt to tool result follows a predictable sequence.
-
Discovery: At session initialisation, the MCP Client calls
tools/list,resources/list, andprompts/liston the Server to retrieve its full capability manifest — function signatures, parameter types, return shapes, and data access paths. -
Context injection: The Host injects the relevant capability descriptions into the model’s context window. The LLM knows what tools are available and how to invoke them without any custom per-tool prompt engineering.
-
Call: When the LLM decides to invoke a tool, the Host instructs the Client, which sends a JSON-RPC 2.0 method invocation to the Server.
-
Result: The Server executes the tool and returns a JSON-RPC response. The Host surfaces the result back to the model for the next inference step.
The key insight is in step 1. Standardised, machine-readable discovery means a Host can connect to a new MCP Server and use all its tools without any Host-side code changes. The M+N gain is self-reinforcing at runtime — it compounds every time a new server joins the ecosystem, not just at build time.
Why did MCP win over UTCP — and what does UTCP’s existence reveal about the trade-offs?
UTCP, the Universal Tool Calling Protocol, represents a coherent alternative design philosophy. Understanding it clarifies what MCP is actually trading away in exchange for its abstraction.
UTCP eliminates the MCP Server intermediary entirely. Rather than wrapping tools in a protocol server, UTCP defines a descriptive JSON “manual” that tells an AI agent what a tool does and how to call it. The agent reads the manual and communicates directly with the tool over HTTP, WebSocket, gRPC, or whatever native interface the tool already exposes.
UTCP’s genuine engineering advantages are real. No proxy overhead (latency benchmarks show MCP adding 25–100% per-call overhead versus UTCP direct calls), native authentication that reuses the tool’s existing API security controls, no server infrastructure to deploy or maintain, and protocol flexibility across HTTP, WebSocket, CLI, SSE, and others. If your tools already have well-governed APIs, the argument for skipping another service layer is a reasonable one.
The deciding factor for MCP’s adoption was ecosystem network effects. Each new MCP server is usable by every MCP-compatible client platform. When OpenAI, Google, GitHub Copilot, Cursor, and VS Code all implement MCP as a first-class client, any tool that ships an MCP server gains access to that entire ecosystem immediately. UTCP, without that installed base, requires tools to be discovered and integrated client-by-client.
UTCP’s rational niche is organisations with well-governed, consistent existing APIs who want to avoid server deployment overhead and aren’t targeting broad client ecosystem reach. For most teams, UTCP remains a viable architectural pattern rather than a practical alternative. Worth noting: UTCP can describe tools that themselves implement MCP, so the two aren’t adversarial — they address different positions on the abstraction/performance trade-off spectrum, and both are developed within the AAIF ecosystem.
What does “de facto standard” actually mean for MCP by 2026?
“De facto standard” should be a verifiable claim, not a marketing phrase. And for MCP, the evidence is substantial.
The most credible independent validation comes from Andy Pavlo’s 2025 Databases in Review at Carnegie Mellon University. Pavlo noted that 2025 was the year every major DBMS vendor shipped an MCP server — OLAP (ClickHouse, Snowflake, Firebolt), SQL (YugabyteDB, Oracle, PlanetScale), and NoSQL (MongoDB, Neo4j, Redis). That’s independent academic validation with no commercial stake in MCP’s success.
The adoption numbers: Anthropic’s December 2025 AAIF announcement confirmed 97 million monthly SDK downloads and more than 10,000 active public MCP servers. First-class client support spans competing platforms: ChatGPT (OpenAI), Google Gemini, GitHub Copilot, Cursor, and VS Code. OpenAI’s adoption in March 2025 was the definitive signal that MCP had transcended its Anthropic origins.
The governance milestone: Anthropic donated MCP to the Linux Foundation‘s Agentic AI Foundation (AAIF) in December 2025, co-founded with Block and OpenAI, with Platinum members including AWS, Bloomberg, Cloudflare, Google, and Microsoft. That transformed MCP from a vendor protocol into vendor-neutral infrastructure. The procurement implications are covered in the Linux Foundation governance article.
Why this matters architecturally: the M+N model has a compounding network effect. Each new MCP server adds value to every existing client. Once the flywheel is turning at 10,000+ servers and 97M monthly downloads, a technically superior but adoption-poor alternative faces a structural disadvantage that merits alone cannot overcome. For teams building AI agents in 2026, the question isn’t whether to support MCP — it’s how.
Where does MCP end and A2A begin?
MCP is an agent-to-tool protocol. It standardises how an AI agent connects to external tools, APIs, and data sources. The scope ends at the agent-tool boundary.
A2A (Agent-to-Agent Protocol) and ACP (Agent Communication Protocol) are the complementary agent-to-agent layer — they standardise how agents coordinate with each other: task delegation, handoffs, multi-agent orchestration. The distinction in one sentence: MCP gives an agent hands (tool access); A2A and ACP give agents voices (inter-agent communication).
In practice, a planner agent delegates sub-tasks to specialist agents via A2A, while those specialists invoke tools via MCP. For teams evaluating full agentic architectures, the governance article covers A2A and ACP governance alongside MCP. What the orchestration layer above raw MCP tool calls adds is covered in the Code Mode article.
Frequently Asked Questions
Is MCP a replacement for REST APIs?
MCP is not a replacement for REST — it’s a coordination layer that typically sits on top of it. MCP Servers frequently wrap existing REST APIs without requiring the underlying API to change at all. A weather REST API becomes an MCP tool by writing an MCP server that wraps it; the REST API is untouched. The distinction: REST describes how a client communicates with a server over HTTP; MCP describes how an AI agent discovers and invokes capabilities, which may use REST, gRPC, a database driver, or any other implementation internally.
Does MCP work with any LLM or only Anthropic’s Claude?
MCP is model-agnostic. Anthropic created the protocol, but it’s now governed as a vendor-neutral standard under the AAIF. First-class MCP client implementations exist for ChatGPT, Google Gemini, GitHub Copilot, Cursor, and VS Code — none of which are Anthropic products. Any LLM that supports function calling can be given MCP access through an appropriate Host and Client implementation.
What is the difference between an MCP client and an MCP server?
An MCP Client lives inside the Host, maintains a 1:1 connection to a single MCP Server, and translates Host instructions into JSON-RPC 2.0 method calls. An MCP Server wraps a tool or data source, advertises its capabilities via a standard manifest, and executes tool calls when invoked. The Client is not the end-user application; the Server is not the cloud infrastructure. A single Host can run multiple Clients simultaneously, each connected to a different Server.
What are MCP tools, resources, and prompts?
The three primitives define the full surface of what an MCP Server can expose: Tools are callable functions the LLM invokes with parameters (e.g., query_database, send_message); Resources are readable data the model can access without a function call (files, database records); Prompts are reusable instruction templates the server offers to the Host. Together, these make MCP more than a simple “function calling wrapper”.
Why does MCP use JSON-RPC 2.0 instead of REST?
REST is HTTP-bound and restricted to request/response interactions. JSON-RPC 2.0 is transport-agnostic — it works over HTTP, stdio, and WebSockets — and supports bidirectional messaging. For MCP’s use case, where an agent may spawn local processes via stdio or connect to remote services via SSE, REST’s HTTP binding would be a constraint rather than a feature. JSON-RPC 2.0 is also language-agnostic at the wire level, which accelerated cross-language SDK development.
What is UTCP and is it worth evaluating alongside MCP?
UTCP (Universal Tool Calling Protocol) eliminates the MCP Server intermediary: the AI model calls tool APIs directly using the tool’s own authentication and schema. Its genuine advantages — no server overhead, native auth, lower latency — are real. But in 2026, MCP’s ecosystem lead (97M+ monthly SDK downloads, 10,000+ servers, all major clients) means the integration cost of bypassing MCP outweighs UTCP’s per-call performance gains for most teams.
How many MCP servers are there and who uses MCP?
As of Anthropic’s December 2025 AAIF announcement, MCP has 97 million monthly SDK downloads and more than 10,000 active public MCP servers. First-class client implementations span competing platforms: ChatGPT (OpenAI), Google Gemini, GitHub Copilot, Cursor, and VS Code. Academic validation comes from Andy Pavlo’s 2025 Databases in Review at Carnegie Mellon University, which noted that 2025 was the year every major DBMS vendor shipped an MCP server.
Does MCP have security risks I should know about?
MCP’s security surface is richer than the USB-C analogy implies. MCP Servers are the primary security enforcement boundary — a compromised or misconfigured server can expose tools to over-permissioned AI invocations. Key risk categories include credential management within MCP servers, tool poisoning via adversarial capability descriptions, and over-broad permissions granted to agent sessions. The full threat model is covered in the SAFE-MCP security article.
Where can I find the official MCP specification and documentation?
The official specification and SDK documentation are at modelcontextprotocol.io. Primary SDK implementations are Python and TypeScript; community SDKs exist for additional languages. AAIF governance information is available via the Linux Foundation’s AAIF pages (aaif.io).
For a complete map of MCP’s scope — from governance and security through to platform selection and vertical protocol extensions — see our MCP overview: What Is MCP and Why Every AI Agent Architecture Depends on It.
