The Model Context Protocol (MCP).
Connecting one AI app to one tool is easy; connecting M apps to N tools by hand is an integration explosion, and every team was rebuilding the same plumbing. The Model Context Protocol (MCP) is the open standard that collapses that M×N mess into M+N — the "USB-C for AI." This entry explains what MCP is, why it exists, how it's shaped, and where it can bite you.
The M×N problem, and why one connector fixes it.
You already know tool calling: your code hands the model a menu of functions and runs the ones it picks. That works, but each integration is bespoke. Build 5 AI apps that each need to reach 8 tools — GitHub, Slack, a database, a filesystem, and so on — and you write 5 × 8 = 40 custom connectors. Every new tool adds 5 more; every new app adds 8 more. Cost grows with the product of both sides. That is the M×N problem, and before MCP the whole industry was paying it in duplicated glue code.
MCP flips the arithmetic to M+N. Agree on one shared protocol; each app implements the client side once, each tool implements the server side once, and now any app can talk to any tool. 5 apps + 8 tools becomes 13 implementations, not 40 — and a tool anyone publishes instantly works in every app that speaks MCP. That is the substance behind the "USB-C for AI" tagline: before USB-C, every device shipped its own charger; after, one connector fits everything.
The analogy is exact in the way that matters. USB-C didn't make devices more powerful — it made them interoperable. MCP doesn't give a model new abilities; tool calling already does that. It standardizes how any app reaches any tool so the connection stops being custom work.
What's under the hood: client, server, three primitives.
MCP is a client/server protocol spoken over JSON-RPC 2.0 — a plain, long-established convention for "call this method with these arguments, get a result back." Three roles:
- The host is the AI app the user interacts with — an IDE, a chat client, an agent.
- Inside it runs an MCP client, which opens and maintains a two-way connection.
- Each external capability is an MCP server — a small program that exposes one tool or data source (a GitHub server, a filesystem server, a database server). One client can connect to many servers at once.
A server can offer three primitives, and who is "in charge" of each differs — a useful thing to keep straight:
- Tools — executable functions the model can invoke (model-controlled). This is ordinary tools and actions, now discoverable through a standard.
- Resources — data or content exposed for context, like files or database records (application-controlled).
- Prompts — reusable, parameterized templates or workflows (user-controlled).
Finally, transports — how the bytes actually move. stdio is for local servers: the client launches the server as a subprocess and they exchange JSON-RPC over stdin/stdout, no network involved. Streamable HTTP is the current remote transport: a single HTTP endpoint using POST plus optional Server-Sent Events (SSE) for streaming, introduced in the 2025-03-26 spec revision. It replaced an older two-endpoint HTTP+SSE transport, now deprecated. As a beginner you rarely touch the wire yourself — an SDK handles the JSON-RPC framing — but it helps to know the Streamable HTTP shape is what makes remote, hosted servers practical.
Why MCP won — and two things it is not.
A protocol only matters if everyone speaks it, so the turning point was cross-vendor adoption. Anthropic introduced MCP on November 25, 2024 (originally developed by David Soria Parra and Justin Spahr-Summers). Then OpenAI adopted it in March 2025, and Google and Microsoft followed — turning MCP into a shared, de-facto interoperability standard rather than one company's format. In December 2025 governance moved to the Linux Foundation, under the Agentic AI Foundation (AAIF), co-founded by Anthropic, Block, and OpenAI — cementing it as neutral infrastructure. (That donation announcement cited more than 10,000 active public MCP servers as of December 2025 — a point-in-time figure, but a fair signal of how fast the ecosystem grew.)
Two misconceptions are worth killing:
- "MCP is a Claude-only thing." False. Anthropic introduced it, but it is an open standard: OpenAI, Google, and Microsoft adopted it, and it is now Linux-Foundation-governed.
- "MCP is just function-calling / another API." Also wrong, and subtler. Function calling is one app's private mechanism for one model to invoke one set of functions. MCP is the protocol layer around that — a standard for discovering, connecting to, and describing tools across the whole ecosystem, so a server you didn't write works in an app you didn't write. For the wiring in detail, see the MCP architecture deep-dive.
Where it can bite you: servers are untrusted code.
MCP's superpower — plug in any server and it just works — is also its sharpest edge. A server is often code you didn't write, and the model reads text that server supplies. Two failure modes matter most:
Prompt injection via tool descriptions ("tool poisoning"). A malicious server can hide instructions inside the tool names and descriptions the model reads, steering it to leak data or misuse other tools — the model treats that metadata as trustworthy. Over-permissioned or over-trusted servers. A server may request broad access; a compromised or malicious one can exfiltrate data or take destructive actions. This is the "confused deputy" problem: your trusted app is tricked into acting on an attacker's behalf.
The fix is a mindset, not a setting: treat every server as untrusted code. Concretely — grant a server only the access it truly needs (least privilege); review what a server does before installing it, and prefer ones you or a trusted party have vetted; and require human confirmation for consequential actions (payments, deletes, sends) so a subverted prompt still cannot act unchecked. These are the same instincts as ordinary prompt-injection defense, now applied to a marketplace of third-party servers, and the tool-poisoning and security anti-patterns deep-dives catalog exactly how they go wrong.
When you're ready to build or secure servers for real, the wiki's MCP deep-dive group takes it from here: building servers in practice and tool design for the how, plus auth and ops in production for running them safely at scale.