---
title: "MCP is not USB-C: where the analogy breaks | Len P. van der Hof"
description: What MCP means, why its own docs compare it to USB-C, and the four places that analogy breaks. Plus a checklist before you plug in an MCP server.
image: "https://lenvanderhof.com/media/generated/blog-hero-mcp-is-not-usb-c-v1.bce2e066975b.wide.webp"
---

[AI Systems](https://lenvanderhof.com/en/blog/category/ai-systems/) Research guide

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

The plug is standard. What the model reads through it is not.

Len P. van der HofPublished 6 October 20267 min read

Every plug fits. That was never the question.

Direct answer

MCP (Model Context Protocol) is an open standard that lets AI applications connect to outside tools and data through one common interface. Its official introduction compares it to a USB-C port, which is right about the plug. It breaks in four places: the model reads each tool's description as text and can be steered by it, a server can act rather than just carry data, permissions live in the app rather than the protocol, and a registry listing proves who published a server, not that it is safe.

## Key takeaways

- MCP's own introduction says to think of it like a USB-C port for AI applications.
- The analogy is right about one standard plug for many tools.
- It breaks because a language model, not a driver, reads what a server says about itself.
- The specification says MCP cannot enforce its security principles at the protocol level. Your app has to.
- Read the full tool descriptions, start read-only, and log every call before you plug a server in.

**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](https://modelcontextprotocol.io/docs/getting-started/intro)) 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](https://www.ncbi.nlm.nih.gov/sites/books/n/statpearls/article-25043/)). This page is about the AI protocol. For the dictionary entry and the other meanings, see [MCP meaning](https://lenvanderhof.com/en/blog/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](https://modelcontextprotocol.io/specification/2026-07-28)). 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-CMCPWhat to do about itWho reads the labelThe operating system reads a short structured descriptor and loads a driverThe language model reads the tool’s description as ordinary textRead every tool description in fullWhat the plug doesCarries power and dataA tool can run code: send mail, change files, call paid servicesTreat write tools like handing over keysWho enforces the rulesCompliance testing happens before a product may carry the USB logoThe spec says MCP cannot enforce its security principles; the app mustCheck what your app asks before a tool runsWhat a listing provesA certified product passed compliance testingA registry listing proves who owns the name, not what the code doesVet 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](https://modelcontextprotocol.io/specification/2026-07-28)).

**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](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)). 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](https://www.usb.org/compliance)). 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](https://modelcontextprotocol.io/registry/about)). 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](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks)). 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](https://assets-global.website-files.com/6098eeb4f4b0288367fbb639/62bc77c194c4e0fe8fc5e4b5_SRLabs-BadUSB-BlackHat-v1.pdf); [recording](https://archive.org/details/youtube-nuruzFqMgIw)).

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**](https://lenvanderhof.com/frameworks/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](https://lenvanderhof.com/books/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](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/)). 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](https://lenvanderhof.com/en/blog/what-is-an-mcp-connector/) covers how to attach a server in each app, and [MCP explained for founders](https://lenvanderhof.com/en/blog/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/](https://lenvanderhof.com/en/blog/mcp-is-not-usb-c/) · Published 6 October 2026.

## Terminology

- [MCP](https://lenvanderhof.com/glossary/mcp/)
- [STACK](https://lenvanderhof.com/glossary/stack/)

## Sources

1. [What is the Model Context Protocol (MCP)?](https://modelcontextprotocol.io/docs/getting-started/intro) · Model Context Protocol project
2. [Specification, version 2026-07-28 (Security and Trust & Safety)](https://modelcontextprotocol.io/specification/2026-07-28) · Model Context Protocol project
3. [Specification, version 2026-07-28: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) · Model Context Protocol project
4. [The MCP Registry (Trust and Security)](https://modelcontextprotocol.io/registry/about) · Model Context Protocol project
5. [MCP Security Notification: Tool Poisoning Attacks](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks) · Invariant Labs (Luca Beurer-Kellner and Marc Fischer)
6. [The lethal trifecta for AI agents: private data, untrusted content, and external communication](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/) · Simon Willison
7. [Compliance](https://www.usb.org/compliance) · USB Implementers Forum (USB-IF)
8. [BadUSB: On accessories that turn evil (slides)](https://assets-global.website-files.com/6098eeb4f4b0288367fbb639/62bc77c194c4e0fe8fc5e4b5_SRLabs-BadUSB-BlackHat-v1.pdf) · SRLabs (Karsten Nohl, Sascha Krißler, Jakob Lell)
9. [BadUSB: On Accessories that Turn Evil (Black Hat recording, 2014)](https://archive.org/details/youtube-nuruzFqMgIw) · Black Hat, via Internet Archive
10. [Anatomy, Shoulder and Upper Limb, Hand Metacarpal Phalangeal Joint](https://www.ncbi.nlm.nih.gov/sites/books/n/statpearls/article-25043/) · StatPearls (NCBI Bookshelf)
11. [STACK (framework)](https://lenvanderhof.com/frameworks/stack/)
12. [The Agentic Codebase](https://lenvanderhof.com/books/the-agentic-codebase/)
13. [MCP meaning](https://lenvanderhof.com/en/blog/mcp-meaning/)

## Further reading

- [MCP meaning](https://lenvanderhof.com/en/blog/mcp-meaning/)
- [What is an MCP connector?](https://lenvanderhof.com/en/blog/what-is-an-mcp-connector/)
- [MCP explained for founders](https://lenvanderhof.com/en/blog/mcp-explained-for-founders/)
- [STACK](https://lenvanderhof.com/frameworks/stack/)

About the author

## [Len P. van der Hof](https://lenvanderhof.com/en/authors/len-p-van-der-hof/)

Entrepreneur, AI Innovator and Venture Builder

Len P. van der Hof builds practical AI systems, digital ventures and evidence-informed tools for founders.

```json
{
	"@context": "https://schema.org",
	"@graph": [
		{
			"@type": "Person",
			"@id": "https://lenvanderhof.com/#person",
			"name": "Len P. van der Hof",
			"alternateName": [
				"Len van der Hof",
				"L.P. van der Hof",
				"Leendert Pieter van der Hof"
			],
			"honorificSuffix": "MSc",
			"url": "https://lenvanderhof.com/",
			"image": [
				"https://lenvanderhof.com/photos/len-portrait-1.jpg",
				"https://lenvanderhof.com/photos/len-portrait-2.jpg",
				"https://lenvanderhof.com/photos/len-portrait-3.jpg",
				"https://lenvanderhof.com/photos/len-portrait-4.jpg",
				"https://lenvanderhof.com/photos/len-speaking.jpg",
				"https://lenvanderhof.com/photos/len-hero.jpg"
			],
			"jobTitle": "Entrepreneur, AI Innovator and Venture Builder",
			"description": "Len P. van der Hof, MSc, is a Dutch entrepreneur and AI innovator in Zwijndrecht. He builds ReasonKit, MindSesh, Undominated.ai, books under his name, the fiction imprint LPH98.lifestyle, and technology ventures through LPH98.ventures. Eleven titles in Systems for the Strategic Self are available now, in English and Dutch.",
			"address": {
				"@type": "PostalAddress",
				"addressLocality": "Zwijndrecht",
				"addressCountry": "NL"
			},
			"alumniOf": {
				"@type": "CollegeOrUniversity",
				"name": "Rotterdam School of Management, Erasmus University"
			},
			"knowsAbout": [
				"Artificial intelligence",
				"AI agents",
				"Agentic AI systems",
				"LLM routing",
				"SEO",
				"Generative engine optimization",
				"Answer engine optimization",
				"Venture building",
				"Founder performance",
				"Founder psychology",
				"Evidence-based decision-making"
			],
			"sameAs": [
				"https://www.linkedin.com/in/lenvanderhof/",
				"https://x.com/LenvanderHof",
				"https://www.youtube.com/channel/UCTG20buKqYYbitqqf7l3zJA",
				"https://www.instagram.com/Lenvanderhof/",
				"https://www.threads.com/@lenvanderhof",
				"https://github.com/Lenvanderhof",
				"https://huggingface.co/LPH98",
				"https://www.npmjs.com/~lenvanderhof",
				"https://www.goodreads.com/author/show/70983905.Len_P_van_der_Hof",
				"https://www.amazon.com/author/lenvanderhof",
				"https://www.bol.com/nl/nl/b/len-p-van-der-hof-msc/609879394/",
				"https://bsky.app/profile/lenvanderhof.com",
				"https://mastodon.social/@Lenvanderhof",
				"https://crates.io/users/Lenvanderhof",
				"https://cursor.com/@Lenvanderhof",
				"https://medium.com/@Lenvanderhof",
				"https://gitlab.com/Lenvanderhof",
				"https://hub.docker.com/u/lenvanderhof/",
				"https://dev.to/lenvanderhof",
				"https://www.facebook.com/Lenvanderhof",
				"https://soundcloud.com/Lenvanderhof"
			],
			"affiliation": [
				{
					"@id": "https://lenvanderhof.com/#publisher"
				},
				{
					"@id": "https://lenvanderhof.com/#mindsesh"
				},
				{
					"@id": "https://lenvanderhof.com/#lifestyle"
				}
			]
		},
		{
			"@type": "WebSite",
			"@id": "https://lenvanderhof.com/#website",
			"url": "https://lenvanderhof.com/",
			"name": "Len P. van der Hof",
			"description": "Len P. van der Hof, MSc, is a Dutch entrepreneur and AI innovator in Zwijndrecht. He builds ReasonKit, MindSesh, Undominated.ai, books under his name, the fiction imprint LPH98.lifestyle, and technology ventures through LPH98.ventures. Eleven titles in Systems for the Strategic Self are available now, in English and Dutch.",
			"inLanguage": [
				"en",
				"nl"
			],
			"publisher": {
				"@id": "https://lenvanderhof.com/#person"
			}
		},
		{
			"@type": "Organization",
			"@id": "https://lenvanderhof.com/#publisher",
			"name": "LPH98.ventures",
			"url": "https://lph98.ventures",
			"founder": {
				"@id": "https://lenvanderhof.com/#person"
			}
		},
		{
			"@type": "Organization",
			"@id": "https://lenvanderhof.com/#mindsesh",
			"name": "MindSesh",
			"url": "https://mindsesh.net",
			"founder": {
				"@id": "https://lenvanderhof.com/#person"
			}
		},
		{
			"@type": "SoftwareApplication",
			"@id": "https://lenvanderhof.com/#reasonkit",
			"name": "ReasonKit",
			"url": "https://reasonkit.sh",
			"creator": {
				"@id": "https://lenvanderhof.com/#person"
			}
		},
		{
			"@type": "SoftwareApplication",
			"@id": "https://lenvanderhof.com/#undominated",
			"name": "Undominated.ai",
			"url": "https://undominated.ai",
			"creator": {
				"@id": "https://lenvanderhof.com/#person"
			}
		},
		{
			"@type": "Organization",
			"@id": "https://lenvanderhof.com/#lifestyle",
			"name": "LPH98.lifestyle",
			"url": "https://lph98.lifestyle",
			"founder": {
				"@id": "https://lenvanderhof.com/#person"
			}
		},
		{
			"@type": "ImageObject",
			"@id": "https://lenvanderhof.com/en/blog/mcp-is-not-usb-c/#primaryimage",
			"url": "https://lenvanderhof.com/media/generated/blog-hero-mcp-is-not-usb-c-v1.bce2e066975b.wide.webp",
			"contentUrl": "https://lenvanderhof.com/media/generated/blog-hero-mcp-is-not-usb-c-v1.bce2e066975b.wide.webp",
			"representativeOfPage": true
		},
		{
			"@type": "BreadcrumbList",
			"@id": "https://lenvanderhof.com/en/blog/mcp-is-not-usb-c/#breadcrumb",
			"itemListElement": [
				{
					"@type": "ListItem",
					"position": 1,
					"name": "Home",
					"item": "https://lenvanderhof.com/"
				},
				{
					"@type": "ListItem",
					"position": 2,
					"name": "Blog",
					"item": "https://lenvanderhof.com/en/blog/"
				},
				{
					"@type": "ListItem",
					"position": 3,
					"name": "AI Systems",
					"item": "https://lenvanderhof.com/en/blog/category/ai-systems/"
				},
				{
					"@type": "ListItem",
					"position": 4,
					"name": "MCP is not USB-C: where the favourite analogy breaks, and why that matters",
					"item": "https://lenvanderhof.com/en/blog/mcp-is-not-usb-c/"
				}
			]
		},
		{
			"@type": "WebPage",
			"@id": "https://lenvanderhof.com/en/blog/mcp-is-not-usb-c/#webpage",
			"url": "https://lenvanderhof.com/en/blog/mcp-is-not-usb-c/",
			"name": "MCP is not USB-C: where the favourite analogy breaks, and why that matters",
			"description": "What MCP means, why its own docs compare it to USB-C, and the four places that analogy breaks. Plus a checklist before you plug in an MCP server.",
			"isPartOf": {
				"@id": "https://lenvanderhof.com/#website"
			},
			"primaryImageOfPage": {
				"@id": "https://lenvanderhof.com/en/blog/mcp-is-not-usb-c/#primaryimage"
			},
			"breadcrumb": {
				"@id": "https://lenvanderhof.com/en/blog/mcp-is-not-usb-c/#breadcrumb"
			},
			"inLanguage": "en-GB"
		},
		{
			"@type": "BlogPosting",
			"@id": "https://lenvanderhof.com/en/blog/mcp-is-not-usb-c/#article",
			"mainEntityOfPage": {
				"@id": "https://lenvanderhof.com/en/blog/mcp-is-not-usb-c/#webpage"
			},
			"headline": "MCP is not USB-C: where the favourite analogy breaks, and why that matters",
			"description": "What MCP means, why its own docs compare it to USB-C, and the four places that analogy breaks. Plus a checklist before you plug in an MCP server.",
			"datePublished": "2026-10-06T07:00:00.000Z",
			"author": {
				"@id": "https://lenvanderhof.com/#person"
			},
			"publisher": {
				"@id": "https://lenvanderhof.com/#person"
			},
			"image": [
				"https://lenvanderhof.com/media/generated/blog-hero-mcp-is-not-usb-c-v1.bce2e066975b.square.webp",
				"https://lenvanderhof.com/media/generated/blog-hero-mcp-is-not-usb-c-v1.bce2e066975b.landscape.webp",
				"https://lenvanderhof.com/media/generated/blog-hero-mcp-is-not-usb-c-v1.bce2e066975b.wide.webp"
			],
			"articleSection": "AI Systems",
			"inLanguage": "en-GB"
		}
	]
}
```
