Model Context Protocol Explained: What It Actually Is, and What the USB-C Analogy Hides

By Muhammad Ramzan Aatish

The Model Context Protocol gets introduced with the same comparison almost every time. It’s USB-C for AI, one standard plug for every tool. The comparison is catchy. It is also incomplete in a way that matters, because a plug does not tell you who to trust, what it costs to stay connected, or what happens when something on the other end misbehaves. So what is MCP, really, underneath the slogan?

Strip away the marketing and the Model Context Protocol is an open standard that gives AI applications one shared way to connect to external tools, data, and prompt templates. Before it existed, every pairing of an AI app and an outside system needed its own custom integration. Ten apps connecting to ten systems could mean dozens of bespoke adapters, each with its own way of describing tools, handling authentication, and reporting errors. Ask ten explainers what is MCP and you will get ten versions of the USB-C line. The useful answer is duller and more important: MCP replaces that tangle with a common contract, so any compatible application can use any compatible tool.

How the Model Context Protocol actually works

Three roles show up in every interaction. The host is the AI application you actually talk to, an assistant, a coding environment, or an agent platform. Inside the host, a client is created for each connection, and each client maintains a dedicated link to exactly one server. The server is the program on the other end, exposing some capability from a system it wraps. One host can hold several connections at once, a filesystem server here, a database server there, a business application somewhere else, all presented to the model through the same interface.

Messages travel as JSON-RPC, and the two sides start by negotiating which protocol version and capabilities they both support. Then the sequence runs like this. The client asks the server what it offers. The server answers with structured tool definitions, including the input each tool expects. The host puts selected definitions in front of the model. The model proposes a call. The host checks its own policy and, where the action matters, asks you first. Only then does the validated request go to the server, which runs it and returns a structured result. The host decides how much of that result the model gets to see next.

That last step is easy to skip over. It is the whole point. The Model Context Protocol standardizes the exchange. It doesn’t decide whether the model should be trusted with a tool. That decision belongs to the host and its policy layer, and no protocol update removes it. Two transports carry these messages: stdio for local servers on your own machine, and Streamable HTTP for remote servers, with standard HTTP authentication and OAuth recommended for tokens. The distinction matters because a local server runs with the same privileges as the application hosting it, while a remote one brings the full problem set of internet services, identity, scopes, and revocation.

Three things a server can offer, and three it can ask for

MCP servers expose capabilities called primitives. Three point from server to model, and three point the other way, each only if both sides negotiated it. Most confusion about the protocol comes from blurring this split.

The protocol itself keeps evolving. An earlier revision assumed stateful connections with a handshake and a session header. The latest major revision went fully stateless, retiring both, which lets servers scale horizontally on ordinary load-balanced infrastructure without session affinity. If you ever debug a connection that behaves oddly, the first question is which revision each side speaks. Mismatched assumptions here explain a whole class of strange failures.

MCP vs function calling: different layers, not rivals

Here’s the confusion that shows up most often. Models could already call tools before MCP existed, so why add a protocol? Because function calling is a capability, and MCP is a standard. Function calling means the model emits a structured request for a function. It is also provider-specific: one vendor’s format differs from another’s, so connectors built for one model get rebuilt for the next. MCP sits underneath all of that. It standardizes how tools get discovered, described, and reached across a boundary you do not own. The model still uses function calling under the hood. What changes is portability: a part that fits one machine versus a part that fits every machine built to the standard.

MCP vs function calling is not a choice you make once. In practice the two work together constantly: the server tells the host which tools exist, the host shows selected definitions to the model, the model emits a call, and the host sends it through MCP to the right server. If someone tells you MCP replaced function calling, they have the layers mixed up.

MCP and A2A: downward versus sideways

Google’s Agent-to-Agent protocol solves a different problem from the Model Context Protocol, and the pair is easy to confuse because both now sit under the same foundation. The Model Context Protocol connects an agent downward to its tools and data. A2A connects agents sideways to each other, letting one agent discover another, delegate a task, and track its progress through defined states. A practical system uses both: MCP inside each agent to reach its tools, A2A between agents to coordinate work. Neither replaces the other.

Why every big vendor signed on

The Model Context Protocol started at Anthropic, announced with software kits for the two most common languages and reference servers for everyday systems like Drive, Slack, GitHub, and Postgres. Within months, OpenAI had adopted it into its agents toolkit, Google had committed its Gemini models to it, and Microsoft had made it a first-class standard across Copilot, Windows, GitHub, and Azure. AWS followed with support in its agent platform. Then Anthropic donated the protocol to the Agentic AI Foundation, a Linux Foundation fund co-founded with Block and OpenAI and backed by Google, Microsoft, AWS, Cloudflare, and Bloomberg, with technical decisions made by individual maintainers rather than company representatives.

That governance move is the part people underestimate. A standard owned by one vendor is a product decision. A standard held by a foundation with rival vendors on the board is infrastructure, and infrastructure is what makes teams comfortable building on top of it. Reported scale figures point the same way: Anthropic reported monthly software-kit downloads in the tens of millions and public servers past ten thousand, and independent trackers counted public server repositories climbing from a couple thousand to well past ten thousand in about a year. Treat those as reported figures, not audited census data. The direction is clear either way.

The same shift explains why the protocol keeps appearing in AI agents coverage on this site. Agents need tools and context to do anything beyond chatting, and our guides to AI agents, how to use AI agents, and local AI agent deployment all describe systems that live or die by their connections. MCP is the connection layer those systems increasingly share.

MCP security: the trust problem nobody can protocol away

The Model Context Protocol improves interoperability through standardization. It doesn’t make a server trustworthy, and this is where the cheerful version of the story ends. The documented risks have names worth knowing. Tool poisoning hides malicious instructions inside a tool’s description or parameter schema, which the model reads and can follow while you see only a harmless tool name. Rug pulls change a server’s tool definitions after you approved it, so the approval you gave no longer matches what the server does. Prompt injection arrives through tool output: a fetched page, document, or email carrying hidden instructions that the model treats as commands. The confused deputy problem means a server acts with its own broad privileges rather than yours, and over-scoped credentials turn one compromised tool into access far beyond its job. Add lookalike servers impersonating popular integrations, and local servers running with full access to your machine, and the picture is complete. None of this requires a flaw in the protocol itself. It requires only misplaced trust.

The sharpest public fight about that trust came from security researchers at OX Security (Moshe Siman Tov Bustan, Mustafa Naamnih, Nir Zadok, and Roni Bar), who reported that the official software kits execute the local transport’s command parameter verbatim, without sanitization, so any path letting an attacker influence server configuration yields arbitrary command execution. Their scope claim ran to hundreds of millions of downloads, thousands of publicly reachable servers, and hundreds of affected open-source projects, with dozens of disclosures and high-severity flaws in downstream tools following. Anthropic’s position, as reported by OX, was that the behavior is by design and sanitization is the developer’s responsibility. I am presenting that as OX’s account of a dispute, not as a settled verdict, because the two sides describe the same mechanism very differently. A later OX scan of publicly indexed servers found a small but real slice running on personal machines exposed through consumer tunneling services, and found that most registries it tested accepted a harmless proof-of-concept server with no security review at all. “I installed it from the registry” is not a safety answer.

So what actually helps? The defenses are unglamorous, and they all sit outside the protocol. Give each of your MCP servers only the credentials and scope its job needs, never shared tokens across servers. Prefer read-only access and narrow permissions, and short-lived tokens over permanent ones. Require a human yes for sensitive, external, financial, or destructive actions. Enforce input validation and business rules in code, not in prompts. Return only the fields the agent needs. Log every call, and make revocation easy. Pin exact server versions and re-review on every update, because approvals do not survive rug pulls. None of this is exciting. All of it is the difference between a useful connection and an open door.

The backlash is the interesting part

Scroll through developer discussion about the Model Context Protocol and the mood splits in a way you miss if you only read vendor announcements. On Hacker News, one thread about the protocol’s moment drew a comment from someone who had built several servers: it’s not how they’d design a protocol, but it works, and everyone is using it, so hooray for interoperability. In the same discussion, another voice put it more bluntly: this is not the new TCP for AI, it is essentially an RPC layer for chat, and the hype is overblown. A related thread called the USB comparison absurd outright. The counter-voice in yet another thread was simpler: it is JSON-RPC with some descriptors, and the value is in the consensus, the ability to make a tool that agents can connect to with no prior knowledge.

The sharpest version of the argument came from a coding tool called Pi. Its homepage used to declare, as a point of philosophy, that it does not support MCP. The creator’s objection was concrete, not vibes: a popular browser-automation server dumped twenty-one tool definitions and thirteen thousand seven hundred tokens into the model’s context on every single session, while a command-line tool with a good readme costs nothing until the agent actually needs it. Then the tool shipped MCP support anyway, with a self-aware announcement acknowledging the reversal, and the discussion exploded. That reversal is probably the most useful signal in the whole debate. The fight was never really about whether a standard is good. It was about token cost, and token cost is a real engineering constraint that no slogan fixes. Some voices have gone further and declared the protocol dead for agents that can code. Others answer that the hype dying is not the technology dying: it becomes one of several ways agents interact with software, and the agent does not care about our arguments, only about getting the job done. I find the second framing more honest. The protocol is not everything. It’s not nothing either. It’s plumbing, and plumbing gets judged by whether it leaks.

How to use MCP yourself

I haven’t been able to get hands-on with this yet since no test environment was set up for this article, but based on the documented setup path, here is what to expect when you do. Most guides on how to use MCP start with the official filesystem server, which exposes a folder you choose to a compatible client. In Claude’s desktop app, you add it to the configuration file under the servers key, using absolute paths, then restart the app completely and verify by asking the assistant to list its tools. In Claude’s coding tool, the same connection is a single command. If you would rather test without registering anything, MCP Inspector opens a local interface where you can list tools and run calls directly.

Two practical warnings belong here before anything else. First, start with a folder that contains nothing sensitive, because a filesystem server sees what you point it at. Second, treat every one of the MCP servers you add like software you install, not like a website you visit: check who published it, read its tool descriptions, and pin the version. The setup itself takes minutes. The judgment about what to connect takes longer, and it should.

Coding assistants are the other natural first stop. Our guide to AI coding tools covers the editors where these connections now live, and agent products like Manus show the same pattern from the product side: the agent is only as useful as the systems it can reach, and MCP is increasingly how it reaches them. The Claude lineup is worth watching here too, since Claude’s desktop and coding tools were the reference implementation the rest of the ecosystem built against.

When not to use it

Not every project needs a protocol. A small application with one tightly controlled backend, or a single stable feature with fixed operations, is usually simpler, faster, and cheaper with direct function calling. The Model Context Protocol earns its keep when the same tools must serve multiple AI clients, when tools should be discoverable at runtime, or when a team wants to separate AI orchestration from system-specific integration code. Adopting it also means adopting its operational work: server lifecycle management, compatibility testing, authentication, observability, and governance. If that list sounds heavier than your problem, it probably is.

Frequently asked questions

What is the Model Context Protocol in simple terms?

One shared way for AI applications to connect to outside tools, data, and services, so developers stop writing a custom integration for every model-tool pairing.

Is MCP only for Claude?

No. Anthropic built it, but OpenAI, Google, and Microsoft all adopted it, and it now sits under a Linux Foundation fund with rival vendors on the board. Any application implementing the client specification can connect to any server.

Does MCP replace APIs?

Nope, and this one comes up constantly. The API underneath still does the real work. MCP just standardizes how an AI application discovers and calls what the API already offers, which is a much less dramatic claim than “replaces”, and a much more useful one.

How is MCP different from function calling?

Function calling is what the model does: emit a structured request for a function. The Model Context Protocol is the standard around it: how tools are described, discovered, and reached across applications and models. The model still calls functions under the hood. MCP makes the tool portable instead of locked to one app.

What about A2A, is that a rival?

Not a rival, a neighbor. MCP connects an agent to its tools. A2A connects agents to each other for delegation and coordination. A serious multi-agent setup ends up using both, one inside each agent and one between them.

Is MCP secure?

Depends on the server, the permissions it holds, and how it is deployed, which is an unsatisfying answer and also the true one. The documented risks are tool poisoning, rug pulls, prompt injection through tool output, and over-broad credentials. The defenses are least privilege, per-server credentials, human approval for consequential actions, pinned versions, and audit logs. A standard connection is not a security boundary on its own.

How do I try it without building anything?

Install the official filesystem server, point it at a boring folder, register it in your client’s configuration, restart, and ask the assistant to list its tools. Or skip registration entirely and poke at a server through MCP Inspector’s local interface first.

What to remember

The Model Context Protocol is a common language between AI applications and the tools around them, and its value comes from replacing isolated integration habits with a discoverable, structured protocol. Its limits come from the same place its value does: a standard makes connections portable, but it cannot make them trustworthy, cheap, or well-designed. Hosts still decide which MCP servers to trust, which capabilities to expose, what data to share, and when a person must approve. Governance makes the Model Context Protocol safe to build on. Engineering makes it safe to run. Keep those two jobs separate and the Model Context Protocol earns its place. Confuse them and no analogy will save you.

Sources

• Model Context Protocol official specification, Architecture page — modelcontextprotocol.io
• Unite.ai MCP explainer — unite.ai
• OWASP MCP Security Cheat Sheet — OWASP
• OX Security advisory on the STDIO disclosure — ox.security
• Hacker News discussion threads on the protocol’s design and hype — thread one, thread two, thread three
• Pi coding agent MCP reversal — dev.to
• Unite.ai MCP explainer — unite.ai
• Tech-insider MCP adoption timeline — tech-insider.org
• Anthropic announcement: Donating MCP to the Agentic AI Foundation — anthropic.com

Muhammad Ramzan Aatish covers AI tools and infrastructure for AI Discovery Wire, with a focus on explainers that working developers and curious readers can both use. He tracks agent frameworks, coding tools, and the connection layers between them.