MCP: The Protocol That Wants to Be USB-C for AI

June 7, 2026 · mcp, model-context-protocol, ai-infrastructure, usb-c, anthropic, llm, tools, 實讀 12 min read

MCP: The Protocol That Wants to Be USB-C for AI

You’ve probably heard the comparison already. Someone called MCP — the Model Context Protocol — “USB-C for AI,” and the phrase stuck. Like a lot of sticky tech metaphors, it’s useful up to a point. USB-C gave us a single cable for everything from charging your laptop to outputting 8K video. Before that, every gadget needed its own cable, its own connector, its own wall wart. MCP promises something similar: one standardized way for AI models to talk to the tools, data sources, and services they need to actually be useful.

But the analogy only goes so far. USB-C is a hardware standard you barely think about. MCP is a protocol — a set of rules for how software talks to software — and whether you’re a developer or just someone who uses ChatGPT or Claude, it’s quietly becoming infrastructure you rely on.

So what exactly is MCP, why does it exist, and should you care?

The Mess It’s Trying to Fix

Before MCP, connecting an AI model to external tools was a custom integration job every single time. Say you wanted to build a chatbot that could check your company’s inventory, search a knowledge base, and send Slack messages. You’d need to write bespoke glue code for each connection — figure out authentication, define the endpoint, handle errors, format the data just right for the model to understand. Every tool integration was a one-off.

Now multiply that by every app that wanted to add AI features. The result was what engineers call an N×M integration problem: N AI models × M tools, each needing its own bespoke bridge. It didn’t scale. Small teams couldn’t afford to build all those integrations. Large companies ended up with brittle, hard-to-maintain spaghetti code.

MCP collapses this. Build one MCP server for Slack, one for Salesforce, one for your calendar. Now any MCP-compatible AI app — Claude, ChatGPT, Gemini, or a custom system — can use them all. Call it N + M instead of N × M. The math is brutal: if you have 5 AI apps and 10 tools, you go from 50 integrations to 15.

The design was heavily inspired by the Language Server Protocol (LSP), which did something similar for code editors a decade ago. Before LSP, every editor needed its own plugin for every programming language. LSP gave editors one protocol. One language server works in VS Code, Neovim, JetBrains, and Emacs. MCP is LSP’s spiritual successor, but for AI and tools instead of editors and languages.

How MCP Actually Works

MCP follows a simple three-part architecture: Host, Client, and Server.

When you ask an AI assistant to “look up the sales figures for last quarter,” here’s what happens behind the scenes: the host sends your request to the client, the client routes it to the right server, the server does its job and sends back the result, and the model weaves that into its reply.

MCP servers expose three kinds of capabilities:

  1. Resources — data the model can read. Files, database records, API responses. Think of these as the “get” operations.
  2. Tools — actions the model can trigger. Send an email, update a record, run a calculation. These involve side effects, and most implementations require user confirmation before execution.
  3. Prompts — reusable templates for common tasks. Instead of writing a long instruction each time, a server can offer a pre-built prompt for things like “summarize this document” or “file a bug report.”

Servers can run in two modes. STDIO mode runs the server as a local subprocess — fast, secure, no network exposure. Your data stays on your machine. Streamable HTTP mode lets the server run remotely, so you can call it over the web with OAuth 2.1 authorization. This makes MCP flexible enough for everything from a local script that reads your calendar to a cloud service handling enterprise billing.

If you’re a developer, MCP SDKs exist for TypeScript, Python, Java, Kotlin, C#, Go, PHP, Perl, Ruby, Rust, and Swift. Pretty much any language you’d reasonably reach for has support.

Who’s Behind This Thing

MCP started as an Anthropic project, but it didn’t stay that way for long. In November 2024, Anthropic announced it as an open standard. By December 2025, they donated the protocol to the Linux Foundation’s newly formed Agentic AI Foundation (AAIF). The message was clear: this isn’t meant to be an Anthropic-only play. It’s industry infrastructure.

The founding members of AAIF read like a who’s-who of tech: Anthropic, Block, and OpenAI as co-founders. Then Amazon Web Services, Bloomberg, Cloudflare, Google, and Microsoft as platinum members. Yes — OpenAI and Google both signed up. The same companies racing to build competing AI models agreed to cooperate on the protocol layer. This mirrors the governance structure that hosts the Linux kernel, Kubernetes, and Node.js.

Adoption numbers are hard to fake. As of early 2026, the MCP SDKs were being downloaded 97 million times every month. Over 10,000 public MCP servers exist, covering everything from file systems and databases to GitHub, Slack, Notion, Google Maps, and Spotify. In April 2026, the first MCP Developer Summit was held in New York City, drawing about 1,200 attendees. For a protocol that didn’t exist eighteen months earlier, that’s a meaningful signal.

What MCP Actually Enables

Abstract architectures are fine, but what does MCP look like when it’s working? Here are concrete examples.

Your own knowledge base. This is where MCP hits close to home for this site. Tools like the OpenViking knowledge base — a semantic search engine for your personal notes, documents, and research — work as MCP servers. Your AI assistant can query your own data directly: “find that paper about GRPO training instability” or “what were the key findings from the HKO forecast analysis?” The model reaches into a structured database, not its training data, so the answers are specific and grounded in your actual work.

Claude Code. Anthropic’s own coding assistant uses MCP internally. When Claude Code reads your project files, runs tests, or makes git commits, it’s using MCP servers in STDIO mode — local, fast, no network calls. The code never leaves your machine.

Enterprise chatbots. This is where the real action is. Companies are building internal AI assistants that connect to their own Salesforce instances, Jira boards, HR systems, and knowledge bases via MCP. Instead of training a model on company data (expensive, slow, hard to keep current), they give the model real-time access through MCP servers. The model stays generic; the data stays fresh.

Personal assistants. Tools that can check your email, add calendar events, control smart home devices, or pull up last week’s grocery list — all through MCP servers. If you’ve ever wanted an AI that could actually do things rather than just talk about doing them, this is how that happens.

The Parts People Aren’t Happy About

Not everything about MCP is smooth. Two criticisms keep coming up.

Security

Giving an AI model the ability to trigger actions in the real world is inherently risky. Three attack vectors keep getting mentioned:

Security researchers have demonstrated practical attacks, and the MCP specification itself documents these risks. The protocol includes mitigations — STDIO mode keeps servers sandboxed as local processes, Streamable HTTP requires explicit user authorization via OAuth 2.1 with PKCE, and the June 2025 spec update prohibited token passthrough and added resource indicators. Most security teams recommend running MCP servers at minimum privilege, auditing servers before connecting them, and never granting write access without human approval.

”Do We Really Need This?”

The second criticism is more philosophical. Some developers argue that MCP is solving a problem that already has adequate solutions. OpenAI’s Function Calling, for example, already lets models call external APIs with structured arguments. REST APIs exist. Webhooks exist. Why add another layer?

The counter-argument is that those solutions are all one-off integrations. Function Calling works if you’re using OpenAI. If you switch to Claude or Gemini tomorrow, you rewrite your integrations. MCP is the abstraction layer that makes your tools model-agnostic. Write one MCP server, and any compliant host can use it. Whether that trade-off is worth the complexity depends on who you ask.

There’s some truth to the skepticism. If you only need one AI app talking to one tool, MCP adds complexity without benefit. The protocol makes sense at scale — multiple apps, multiple tools, multiple teams — but a direct API call is simpler for a single-purpose integration.

Adoption is also uneven. Big tech companies are on board, but smaller tool makers and open-source projects haven’t all joined in. Some see MCP as more overhead than it’s worth for simple integrations. The protocol is still young, and standards this ambitious take years to settle.

MCP vs. the Alternatives

MCP isn’t the only protocol in this space. The two worth knowing about:

A2A (Agent-to-Agent) is Google’s entry. Announced in 2025, A2A is designed for agents talking to other agents, not for an agent talking to tools. Google’s view is that dedicated tool protocols and inter-agent protocols solve different problems. MCP handles tool access; A2A handles agent coordination. The two are complementary rather than competitive — MCP for the “how does the model reach my data?” part, A2A for the “how does this agent delegate to that agent?” part. Google is an MCP platinum member, so they see value in both.

REST APIs and Function Calling aren’t going away. They’re the incumbent. MCP doesn’t replace REST — it wraps it. Many MCP servers are just thin layers on top of existing REST APIs that translate between the protocol and the actual service. The value MCP adds is that you don’t need to hand-craft that translation for every combination of model and tool. A REST API can return anything in any format. An MCP server follows a standard schema for tools, resources, and prompts, which means any MCP client can discover and use any MCP server without prior knowledge of its API shape.

For users who aren’t developers, the practical difference is this: a world with MCP means your AI assistant can work with more tools out of the box. You don’t need to wait for every app to build its own AI plugin. They build one MCP server, and it works everywhere.

Why You Should Care

Here’s the thing about infrastructure protocols: when they work well, you never notice them. You don’t think about HTTP when you load a web page. You don’t think about SMTP when you send an email. You just click and it works.

MCP is heading toward that kind of invisibility. If it succeeds, the apps you use every day will get better AI features without you needing to know why. Your calendar app’s AI assistant will check your email, look up flight times, and suggest a meeting time — and it won’t matter whether the underlying model is from OpenAI, Anthropic, or Google. The protocol handles the plumbing.

It also means you might get more control. Because MCP servers are modular, you can run your own — a personal data server that sits on your machine and exposes your files, notes, and calendar to whatever AI assistant you choose. Your data stays local. The model comes to the data, not the other way around. MCP is open and decentralized by design.

Think about what happened when USB-C became standard. Suddenly you could use one charger for your laptop, phone, headphones, and tablet. Accessories got cheaper. Travel got simpler. The standard made the ecosystem better for everyone, not just the engineers who designed the ports. MCP aims to do the same for AI tools.

When the protocol is mature and widely adopted, here’s what changes:

There are legitimate concerns — security, complexity, the possibility that the protocol never reaches critical mass. But the direction is clear. The AI industry is moving from models that only produce text to models that take action. MCP is the most serious attempt so far to build the pipe that connects those actions to the real world.

The USB-C for AI analogy is more than a marketing tagline. It captures exactly what the protocol is trying to be: a universal connector that makes everything work together. We’ll see if it gets there. But for the first time, the industry is actually trying to agree on one.