MCP Is Not a Plugin Store. Here's What It Actually Is.

#ai #mcp #llm #devtools

If you've read much AI news this year, "MCP" probably showed up in one of those posts, immediately surrounded by a lot of nouns: ecosystem, plugin store, App Store for AI, universal remote.

Most of that is wrong, or at least badly oversold. So let's do what I do with every acronym that suddenly appears in every other sentence: strip the framing back to the boring part underneath.

The boring part

MCP — Model Context Protocol — is a standard format for letting an AI application connect to external capabilities. Your files. Your database. A browser. GitHub. That internal API nobody else knows about.

That's it. It's a socket standard.

The problem it solves is embarrassingly mundane. If you want your AI app to read local files, you write an integration. If you want it to touch GitHub, you write a different one. If you want it to query a database, a third one. Every AI application paired with every tool — an N × M problem, and someone on your team is writing all that glue code.

MCP tries to collapse it. A tool exposes its capability once, in a common format, and any AI client that speaks MCP can use it.

Here's roughly what a capability looks like, stripped down:

// Simplified shape, not spec-exact
{
  "name": "read_repo_file",
  "description": "Read a file from a GitHub repository",
  "inputSchema": {
    "type": "object",
    "properties": {
      "repo": { "type": "string" },
      "path": { "type": "string" }
    },
    "required": ["repo", "path"]
  }
}

Notice what's missing: no auth scheme, no billing, no marketplace, no install flow. It's a description of a capability and the shape of its arguments. The protocol's ambition is exactly that small.

If you're on the tool side of this, the appeal is harder to see. You're not shipping an SDK. You're writing one function that reads a request, does the thing, and returns a result — and then, in principle, any client that speaks the format can call it. The work you'd do to build a bespoke integration for a single AI app gets written once instead of N times. The trade-off is real too: you no longer control the surface where your capability is discovered or presented, and you're trusting a shared format to keep existing. That trade is usually worth it if you were already going to build more than one integration.

Why it's bigger than a plugin store

Anthropic proposed MCP in late 2024. By 2025 and 2026 it had been picked up in clients and SDKs by other major vendors, including OpenAI and Google.

For tool authors, that flips the economics. You expose your capability once, and instead of hunting for integrations client by client, every MCP-capable client becomes a distribution channel for free. This is the same "interface dividend" REST and OpenAPI handed their ecosystems. It's just landing on the AI toolchain now.

So the USB-C comparison isn't a bad one. Before, plugging anything into anything meant finding the right cable. The value isn't that the cable is clever — it's that you get to stop thinking about cables.

What it is not

This is where most of the confusion lives, and it's worth three bullets, because these three get mixed up constantly:

It's not a plugin marketplace. MCP is a protocol — a format. It doesn't host anything, review anything, or take a cut. The "MCP marketplace" is just a directory a client built on top to help people find servers. OpenAI already walked this road once: the ChatGPT Plugins store launched and was shut down in 2024.

It's not an App Store. An App Store is one company governing one channel — review, fees, ranking, editorial. MCP is an open protocol, and in late 2025 Anthropic donated it to the Agentic AI Foundation under the Linux Foundation, governed together with OpenAI and Block. No single vendor can flip the switch off.

It's not "the AI decides whether to act." MCP standardizes how an AI application talks to a tool under rules you defined. It does not decide whether it should act at all. Authorization, revocation, and rollback are still lines you have to draw yourself.

That last one is the one I'd underline if I could only underline one.

Who should care this week

If your workflow already chains several tools together — worth two hours of experimentation.
If you build tools — a cheap way to reach AI clients without a bespoke integration per client.
If you maintain internal systems and want an AI assistant on them — a protocol beats a from-scratch plugin.

If you use ChatGPT to write copy and reformat your weekly report — relax. MCP is about "the AI operates software for me," which is a different problem from "the AI writes me a paragraph."

Where to start

Start read-only. Pick something boring and read-only — local file reads, read-only GitHub, read-only Notion — and get one demo working. You're not testing the protocol. You're testing your own sense of what the thing can reach.
Type out the quickstart by hand. Reading three more articles teaches you less than forty minutes of typing does.
Draw your tool map. Which actions are frequent, which are sensitive, which must always have a human. Connect the frequent-and-low-sensitivity ones first.
Don't rewire the whole house today. One power strip. Then decide whether the kitchen and the study deserve circuits.

The one-line version: MCP is less a new AI concept than the plumbing of the AI tool ecosystem. You don't have to renovate today, but you should know where the breaker panel is.

If you want this kind of thing without the hype — what happened, why it matters, who should care, what to do next, with sources linked back to the original — AI Hot publishes a daily signal briefing for builders and operators. The Chinese original of this post lives there, with the misconceptions section expanded.

DEV Community