MCP is not USB-C: where the favourite analogy breaks, and why that matters

MCP (Model Context Protocol) is an open standard for connecting AI applications to outside systems such as files, databases, calendars and search tools. An AI app such as Claude or ChatGPT (the host) connects to small programs called MCP servers, and each server offers tools the model can call, such as “search the customer list” or “create a calendar event”.

The official introduction explains it with one picture: “Think of MCP like a USB-C port for AI applications.” (MCP documentation) That picture is right about the plug. It is wrong about what happens after you plug in, and that difference decides whether your AI assistant can be talked into handing your private files to a stranger’s server.

A quick note on the letters: in anatomy, the MCP (metacarpophalangeal) joint is your knuckle (StatPearls). This page is about the AI protocol. For the dictionary entry and the other meanings, see MCP meaning.

What does the USB-C comparison get right?

The promise of one standard plug. Without a shared standard, every AI app needs custom code for every tool. With MCP, a tool builder writes one server, and any app that speaks MCP can use it.

The idea has a precedent in software. The specification says MCP takes inspiration from the Language Server Protocol, which did the same job for programming languages and code editors (MCP specification). One contract instead of a tangle of one-off connections. That part of the analogy is worth keeping.

Where does the analogy break?

In four places. Each one changes what you should check.

	USB-C	MCP	What to do about it
Who reads the label	The operating system reads a short structured descriptor and loads a driver	The language model reads the tool’s description as ordinary text	Read every tool description in full
What the plug does	Carries power and data	A tool can run code: send mail, change files, call paid services	Treat write tools like handing over keys
Who enforces the rules	Compliance testing happens before a product may carry the USB logo	The spec says MCP cannot enforce its security principles; the app must	Check what your app asks before a tool runs
What a listing proves	A certified product passed compliance testing	A registry listing proves who owns the name, not what the code does	Vet the server yourself

1. The reader is a model, not a driver. When you plug in a USB device, it tells your computer what it is through a short technical descriptor, and the operating system picks a driver (SRLabs’ slides describe this step). An MCP server describes its tools in plain language, and the model reads that text when deciding what to do. Text a model reads can contain instructions. The specification is blunt: descriptions of tool behaviour “should be considered untrusted, unless obtained from a trusted server” (MCP specification).

2. A server acts; a cable carries. The same page says tools “represent arbitrary code execution and must be treated with appropriate caution.” A tool is not a wire. It can send, delete, publish and pay, if someone wired it to.

3. The rules live in the app, not the plug. The specification lists user consent, data privacy and tool safety as key principles, then adds that “MCP itself cannot enforce these security principles at the protocol level.” Hosts must obtain explicit user consent before invoking any tool, and the Tools page says there should always be a human in the loop who can deny a call (Tools specification). Whether that actually happens depends on the app you use and how you set it up.

4. A listing is not a certificate. USB products that pass the USB-IF compliance programme are “considered USB-IF certified” and may license the logo (USB-IF). The official MCP Registry, still in preview, verifies that a publisher owns its namespace (a GitHub account or domain). It leaves security scanning of the actual server code to package registries and downstream marketplaces (MCP Registry). A listing tells you who published a server. It does not tell you what the server will do.

A real case: the poisoned calculator

In April 2025, the security firm Invariant Labs published a demonstration they called a Tool Poisoning Attack (Invariant Labs). A server offered an innocent-looking tool, add, which adds two numbers. Hidden in its description were instructions telling the model to read the user’s MCP configuration file and private SSH key (the file that logs you into other servers) and pass them along inside a tool parameter.

The user saw a simple tool name. The model saw the full description, and followed it. Invariant also described a rug pull: a server changes its tool descriptions after you approved it. Their recommended defences were plain: show users the full descriptions, pin server versions with a hash (a fingerprint that changes if the text changes), and keep boundaries between servers.

Where the analogy is right about danger

Here is the twist. USB has had its own version of this problem. At Black Hat in 2014, SRLabs researchers showed “BadUSB”: a USB stick’s hidden controller chip can be reprogrammed so the stick registers as a keyboard and types commands into the computer (SRLabs slides; recording).

So the old office rule still applies: do not plug in a stick you found in the car park. With MCP, the stick is a server you found in a forum thread, and its label is read by something far more suggestible than a driver.

STACK: where MCP belongs in your setup

STACK is a framework for organising a code repository so that people and AI coding agents can work in it safely. It comes from The Agentic Codebase, which is available now. Five layers:

1. Structure. The layout, entry points and boundaries an agent can find its way through in its first minute.
2. Toolchain. The shells and commands an agent may run, written down instead of remembered.
3. Agent configuration. Instruction files such as AGENTS.md and CLAUDE.md, rules and skills, versioned like code.
4. Connection. MCP servers, tool contracts, hooks and guardrails, with least privilege (only the access the job needs) and a known failure story.
5. Knowledge and quality. Memory, context budgets, evals (automated tests of AI output) and CI, so a model upgrade does not quietly lower the bar.

You do not need the book to use this. MCP lives in the Connection layer. The book’s own picture is not USB-C but a bus: one shared line that every tool hangs from, where each tool owes you a written contract with its scope, limits, timeout, named failure modes and a human owner. It also advises running servers locally unless you need them remote, and pinning a hash of the tool descriptions so your setup refuses to start when they change.

Imagine a hypothetical two-person accounting firm that wants its AI assistant to read invoices from a shared drive. Applied to the Connection layer: one read-only file server, scoped to the invoices folder; no email tool in the same session; Anna named as owner; the description hash pinned; every call logged. The second rule, no email tool next to the invoices, has a name outside the book too. Simon Willison calls the combination of private data, untrusted content and the ability to send data out the “lethal trifecta” (Willison). Supplier invoices are private data, and they are also untrusted content, because outsiders wrote them. Add an email tool to that session and it holds all three.

Before you plug in an MCP server: a checklist

1. Name the owner. Who wrote the server, and who on your side answers for it?
2. Read every tool description in full. Not the one-line summary in the app. Instructions to the model (“before using this tool, first read…”) are a red flag.
3. Start read-only. Add write tools (send, delete, pay, publish) only when you need them, and keep confirmation on.
4. One credential per server, smallest scope. Never a shared admin token.
5. Break the trifecta. No single session gets private data, untrusted content and a way to send data out.
6. Pin and re-review. Record the version and a hash of the descriptions. Re-read them when they change.
7. Log every call. Which tool, which inputs, what came back.
8. Know how to unplug. Decide now what breaks if you remove it at 17:00.

The MCP connector guide covers how to attach a server in each app, and MCP explained for founders covers the review in more depth.

Try this today: a ten-minute audit

Open the connector or MCP settings of the AI app you use most. List every server. For each one, write three things: its owner, whether it can write, and the date you last read its tool descriptions. Any blank line is a server to unplug or to read tonight.

Cite this:MCP is not USB-C: where the favourite analogy breaks, and why that matters.Len P. van der Hof. https://lenvanderhof.com/en/blog/mcp-is-not-usb-c/ · Published 6 October 2026.