MCP (Model Context Protocol) Explained: The New Plumbing of AI
In a year, MCP went from an Anthropic experiment to the way every serious AI agent talks to your tools. Here's what the Model Context Protocol actually does and what changes for small teams.
Key takeaways
- MCP is an open standard for connecting AI models to tools, data sources, and prompts — think of it as USB-C for AI integrations.
- The win is leverage: one MCP server can serve every MCP-aware client, instead of writing a custom integration per assistant.
- It is model-agnostic. Claude, ChatGPT, Cursor, Windsurf, IDE extensions, and most agent frameworks speak it — and since December 2025 the standard has been governed by the Linux Foundation, not by Anthropic.
- What it does NOT solve: prompt engineering, evaluation, hallucinations, or cost. Those are still on you.
- For small teams, the practical move is to consume existing MCP servers first — and only build one when you have a tool worth exposing.
Yet another protocol, yet another three-letter acronym, yet another thing the internet says you must adopt this quarter. MCP fits the pattern — except this one is different. In about a year it stopped being a curiosity and became the way serious AI tools plug into the rest of your stack.
If every AI integration you ship feels like a one-off, hand-wired snowflake, MCP is the answer to that pain. Here's what it is, why it caught on, and where it stops being magic.
Why MCP exists: the integration sprawl problem
For two years, the AI ecosystem ran on bespoke glue. Every assistant that wanted to read your calendar, query your database, or push a deploy needed its own custom integration — ChatGPT's plugin shape, Claude's function calling, Cursor's own thing, whatever your IDE extension invented. None of it transferred. Want the same internal tool reachable from three AI clients? You wrote three integrations.
This is the problem peripherals had before USB: every vendor shipped a different cable. The Model Context Protocol, introduced by Anthropic in late 2024 and adopted broadly through 2025, is the standardization moment for AI tool use. It defines a common shape for tools, resources, and prompt templates, so any compliant client can talk to any compliant server. One cable.
How MCP works, in one paragraph
The protocol has three roles. A host is the application the user sees — Claude Desktop, an IDE, a custom agent runtime. Inside it runs a client, which speaks MCP over a transport like stdio or HTTP. The client connects to servers, which expose three things: tools the model can invoke (functions with side effects), resources it can read (files, records, queries), and prompts the host can offer as templated workflows. That's the whole mental model; everything else — auth, schemas, discovery — is detail layered on those three primitives.
What MCP changed in 2025
Anthropic shipped the spec and reference servers in November 2024, with Zed, Replit, and Sourcegraph among the first tools to wire it up. The IDE crowd — Cursor, Windsurf, then most VS Code AI extensions — added client support, and agent frameworks like LangChain and LlamaIndex made MCP a first-class tool source. OpenAI shipped support in March 2025, which removed the last "but it's an Anthropic thing" objection; Google DeepMind followed in April and Microsoft's Copilot Studio in May. By late 2025, "we built an integration for our internal API" stopped prompting "for which assistant?" and started prompting "is there an MCP server?"
The numbers back the vibe. At the end of 2025 the official Python and TypeScript SDKs were pulling more than 97 million downloads a month, with over 10,000 active public MCP servers in the wild. Then, on 9 December 2025, Anthropic gave the standard away: MCP was donated to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, OpenAI, and Block, with Google, Microsoft, AWS, Cloudflare, and Bloomberg backing it. Technical direction still sits with the maintainers and the public SEP process, but the protocol is no longer any one vendor's to steer. If you were holding off because MCP looked like a lock-in play, that argument is gone.
The spec ships as dated revisions rather than semantic versions. The current one, 2026-07-28, landed on 28 July 2026 after a release candidate that ran from late May, replacing 2025-11-25, and it is the largest change since launch: a stateless core, a standardized HTTP surface, cacheable list results, and a formal extensions framework. That is two days old as we update this, so treat SDK and client support as still landing, and pin a revision you have actually tested.
The shift changes who does the integration work. Before MCP, every AI vendor and tool vendor had to meet in the middle, separately, for every pair. After MCP, the tool vendor ships one server and every AI client gets it free. That's why we'd argue MCP is the most important infrastructure change in how AI agents actually work in two years.
Before MCP, every AI integration was a snowflake. After MCP, the snowflake is the exception.
What MCP doesn't do
This is the part that gets oversold. MCP is plumbing. Excellent plumbing. But plumbing.
- It doesn't make your model smarter. A bad prompt against a great MCP server still gives you bad answers.
- It doesn't replace evaluation. If your agent calls the wrong tool with the wrong arguments, MCP delivers that wrong call quickly and reliably.
- It doesn't fix hallucinations. The model can still invent tool names, parameters, or interpretations of what it just read.
- It doesn't lower your token bill. If anything, exposing more tools and resources makes prompts longer.
- It is not, by itself, secure. An MCP server is an API. It needs auth, scoping, audit logs, and the usual production hygiene.
None of this knocks MCP — it knocks treating any single piece of infrastructure as the whole picture. The hard problems of agent design don't disappear because the transport got standardized, any more than AI pricing goes away because you adopted a new framework.
Should you build an MCP server?
The question we get most often. The honest answer: usually not yet. Most teams should consume MCP servers long before they ship one.
Build one when: you have a tool or dataset that multiple AI clients want to reach — your CRM, an internal search index, a deploy pipeline, a knowledge base. An MCP server pays for itself the moment the second client shows up.
Skip it when: a single agent talks to a single tool. A direct function-call integration is shorter, easier to debug, and faster to ship, and you can extract it into a server later if a second client appears.
The same calculus applies to your first AI agent: get it working end to end with the simplest integration that fits, then refactor toward MCP if reuse becomes a real pressure rather than an imagined one.
Custom integration vs MCP server: the trade-off
| Approach | Best for | Watch out for |
|---|---|---|
| One-off API integration | A single agent talking to one tool | Re-doing the work for every new client |
| MCP server | Tools you want every AI client to use | Auth scoping; an open MCP server is an open door |
| Hybrid (MCP + light glue) | Production agents where MCP covers 80% | Where the glue lives and who maintains it |
Most production systems land in the hybrid row. MCP handles the standard surface area — files, search, common SaaS tools — and a thin layer of custom code wires up the weird, business-specific bits that don't deserve their own server.
Where people go wrong (and when to call a pro)
MCP is genuinely simpler than the alternatives it replaces, which makes it easier to ship dangerously fast. If your agent touches production data or money, the value of a second set of eyes isn't the spec — it's everything around it.
Frequently asked questions
What does MCP actually do that I couldn't already do?
Is MCP just for Anthropic models?
Should we build our own MCP server for our internal tools?
Does MCP fix hallucinations or evaluation?
Building with AI agents?
We'll wire your tools to AI without the brittle glue.
Ghostwire Systems builds production AI agents — including the MCP servers and integrations that make them usable across your stack. See how we work, then tell us what you're trying to ship.