MCP and the Quiet Standardization of AI Tool Use

The thing that almost didn't happen

When Anthropic released Model Context Protocol in November 2024, the framing was modest: an open spec for connecting language models to data sources and tools. The blog post was a few hundred words. There was no launch event. The reference implementations were Python and TypeScript SDKs that took an afternoon to read end-to-end.

Eighteen months later, MCP is the protocol that quietly ate every other competing approach. OpenAI, Google, Microsoft, and Mistral all ship native MCP support. Every major IDE — Cursor, Windsurf, Zed, VS Code — speaks MCP. Slack, Linear, GitHub, Notion, Stripe, and Zendesk all maintain official MCP servers. The protocol won, and almost nobody is celebrating, because winning protocols aren't supposed to feel exciting. They're supposed to feel inevitable.

Why MCP, and not the alternatives

The function-calling specs that came before MCP — OpenAI's plugin manifest, ChatGPT's actions, LangChain's tool wrappers — all tried to solve the same problem: how does a language model know what tools exist and how to call them? They failed at industry adoption for the same reason: each one tied the tool to a specific platform.

MCP made one decision differently. It separated the protocol (how a client and server talk) from the client (which model is on the other side). A Linear MCP server doesn't care if it's being called by Claude, GPT, Gemini, or a homegrown agent. The same server works for all of them, with no per-vendor adapter.

That single decision — protocol over platform — is the same one that made HTTP win over Gopher and TCP/IP win over OSI. The pattern repeats every twenty years. The lesson seemed unlearnable until MCP made it impossible to ignore.

The economics that finished the job

Once MCP existed, the math worked out for everyone in the value chain.

For tool vendors (Slack, GitHub, Stripe), writing one MCP server unlocked every AI client at once. The build cost was bounded; the addressable surface was the entire AI ecosystem. Refusing to ship one became the bigger risk.

For AI vendors, supporting MCP meant their model could connect to hundreds of tools they didn't have to integrate themselves. The pitch to enterprise buyers shifted from "we have integrations with X" to "we speak MCP — bring your own tools." The first answer is a feature; the second is a platform.

For end users, the win was less visible but more real: tools that used to require a custom integration per AI app now Just Worked. Connect your Claude desktop to your Notion. Connect your Cursor to your Postgres. Connect your team's internal AI bot to your incident-management tool. None of this required any vendor to do bespoke work for you.

What MCP is not

It's worth being precise. MCP is not an agent framework. It doesn't tell the model when to call a tool, or how to recover from a failed call, or how to chain multiple calls into a workflow. That work still belongs to the agent layer above MCP — and there are still many competing answers there (LangGraph, AutoGen, CrewAI, Anthropic's own Skills, OpenAI's Agents SDK).

MCP is also not a security boundary. A malicious or buggy MCP server can lie to the model about what it does. Permissions, sandboxing, and tool-call review are still the responsibility of whoever runs the client. If you're shipping AI to production, you still need a thoughtful answer to "what can this thing actually do."

What changes for builders

If you're building an AI product in 2026, three things follow from MCP's win:

Don't build vendor-specific tool wrappers anymore. If your product needs to call out to GitHub or Slack or Postgres, do it through their MCP server. You'll get the integration for free, and it'll keep working when you swap models.

If you have an API, ship an MCP server. The cost to write one is a weekend; the cost to not write one is being absent from every AI workflow your customers are building. There is no longer a defensible reason for an API-first product to skip this.

Plan for the agent layer to keep churning. The framework you pick today (LangGraph, OpenAI Agents SDK, custom) won't be the one you use in two years. MCP is the stable layer underneath. Build assuming the agent framework is replaceable — the tools beneath it aren't.

The quiet revolution

Most protocol wars are loud — fought through standards bodies, blog posts, and Hacker News flame wars. MCP won by being good enough that everyone shipped it before they noticed they'd agreed. The closest historical comparison isn't HTTP. It's USB-C.

That's the highest compliment a protocol can earn: at some point you stop noticing it's there.