MCP Explained: The Protocol That Made AI Agents Useful
MCP turned the M×N integration problem into M+N. 88,000 GitHub stars, 10 language SDKs, every major AI tool supports it. Here is how it actually works under the hood — no buzzwords.
Every AI tool you use has the same problem. It's smart, it can reason, it can write — and then you ask it to check your calendar, or read a specific database, or pull a file from Notion, and it hits a wall.
Not because it can't understand those things. Because it can't reach them.
For the last two years, every time someone built an AI integration, they wrote custom glue code. One connector for Google Drive. Another for Slack. Another for Postgres. Another for GitHub. If you had 10 AI tools and 10 data sources, you needed 100 integrations. The industry was building an M×N problem by hand.
The Model Context Protocol — MCP — was created to fix this. And it's working. The servers repo has 88,000 GitHub stars. There are SDKs in 10 programming languages. Claude, ChatGPT, VS Code, Cursor — they all support it. The protocol spec is now a Linux Foundation project.
But here's what nobody explains clearly: what MCP actually is, how it works under the hood, and whether you should care about it. So let's fix that.
The USB-C Analogy (And Where It Breaks)
The official docs describe MCP as "a USB-C port for AI applications." It's a good analogy, so let's use it — but then go deeper, because the analogy oversimplifies.
USB-C gave us one physical connector that handles power, data, and video. Before it, you had USB-A, mini-USB, micro-USB, Lightning, Thunderbolt, DisplayPort, HDMI — each needing its own port. USB-C said: one connector, one protocol, everything talks.
MCP does the same thing for AI. Instead of writing a custom integration for every (AI tool, data source) pair, you write an MCP server once for your data source, and any MCP-compatible AI tool can use it. The problem goes from M×N to M+N.
Where the analogy breaks: USB-C is a physical standard. MCP is a protocol — specifically, a JSON-RPC 2.0 protocol that runs over standard I/O streams or HTTP. It's not a cable. It's a conversation format. And understanding that conversation is the key to understanding why MCP matters.
How MCP Actually Works
MCP uses a client-server architecture. Three roles:
- MCP Host — the AI application. Claude Desktop, Cursor, VS Code, CopperRiver. This is what the user interacts with.
- MCP Client — a component inside the host that manages connections. Each server gets its own client instance.
- MCP Server — a program that exposes data and tools. Could be running locally (stdio transport) or remotely (Streamable HTTP transport).
The host creates one client per server. If Cursor connects to a Git server, a Filesystem server, and a GitHub server, that's three clients — each maintaining a dedicated connection.
The protocol itself runs on two layers:
Transport layer: Handles the plumbing. Local servers use stdio (standard input/output streams) — zero network overhead, direct process communication. Remote servers use Streamable HTTP — HTTP POST for messages with optional Server-Sent Events for streaming. OAuth recommended for auth.
Data layer: This is where the actual protocol lives. JSON-RPC 2.0 messages — requests, responses, notifications. The data layer handles:
- Lifecycle management — connection initialization, capability negotiation, shutdown
- Primitives — the actual stuff servers expose to AI models
And those primitives are the heart of the whole thing.
The Three Primitives: Tools, Resources, Prompts
Every MCP server can expose three types of things:
Tools
Functions the AI can execute. This is the big one. A tool might be "search the web," "query the database," "create a GitHub issue," "send a Slack message." The AI model decides when to call a tool, passes arguments, and gets results back.
Tools are the mechanism that turns a language model into an agent. Without tools, a model can only talk. With tools, it can act.
Resources
Data the AI can read. File contents, database schemas, API responses, documentation. Resources are passive — the model reads them for context but doesn't change them. Think of it as giving the AI a window into your data without handing it the steering wheel.
Prompts
Reusable templates that structure how the AI interacts. System prompts, few-shot examples, role definitions. Prompts let server authors encode best practices for working with their specific data or API — so the model doesn't have to figure it out from scratch every time.
Here's what makes this elegant: the protocol handles discovery automatically. When a host connects to a server, it negotiates capabilities. Then it can ask "what tools do you have?" and get a structured list back — names, descriptions, argument schemas. The AI model sees this list and decides which tools are relevant to the current task. No hardcoding. No manual configuration of which tools exist.
The M+N Problem, In Practice
Let's make this concrete.
Before MCP: you're building an AI assistant. You want it to read files, search the web, query a database, and manage GitHub issues. For each AI provider you support (Claude, GPT, Gemini), you write separate integration code for each data source. Three providers × four data sources = twelve integration codebases. Each with its own auth, its own error handling, its own quirks.
After MCP: you pick any MCP-compatible host. You connect the Filesystem MCP server, a web search MCP server, a Postgres MCP server, and the GitHub MCP server. Done. Four servers, zero custom integration code. And if you switch from Claude to GPT to an open-source model — the servers don't change. The protocol is provider-agnostic.
This is why MCP spread so fast. It didn't just solve a technical problem — it solved the technical problem for anyone building AI applications.
The Ecosystem: What Actually Exists
The numbers tell the story.
The modelcontextprotocol/servers repository has 88,000+ GitHub stars. The Python SDK alone has 23,500. There are official SDKs in TypeScript, Python, Go, Rust, Java, Kotlin, C#, Swift, Ruby, and PHP. Ten languages, all maintained under the official organization.
The official registry — still in preview — provides a centralized place for discovering published servers with namespace verification (reverse DNS format, like io.github.username/server-name). It delegates security scanning to underlying package registries (npm, PyPI, Docker Hub) and downstream aggregators.
Reference servers maintained by the MCP steering group cover the basics: Filesystem, Git, Memory (knowledge graph), Fetch (web content), Time, Sequential Thinking. Archived servers include integrations for Brave Search, Google Drive, Google Maps, PostgreSQL, Redis, Sentry, Slack, and more — many now maintained directly by the companies themselves.
Client support is universal among major tools: Claude, ChatGPT, VS Code, Cursor, and dozens of community-built hosts.
What MCP Doesn't Do
MCP is a protocol for context exchange. It is not:
An AI model standard. MCP doesn't dictate how models reason, how they're trained, or how they generate responses. It's purely the plumbing — how context gets from your data to the model.
An execution sandbox. MCP servers run code. That code can do anything — delete files, send emails, make API calls. The protocol doesn't enforce isolation. Security is delegated to the server implementation and the host's permissions model. This is both a feature (flexibility) and a risk (a malicious server is full system access).
A replacement for function calling. Function calling is how individual models invoke tools. MCP is how tools are discovered and connected. They're complementary — MCP provides the menu, function calling places the order.
Mature. The spec version is 2025-11-25. The registry is in preview with a warning that "breaking changes or data resets may occur before general availability." The protocol is evolving, and early adopters should expect rough edges.
The Security Question
This deserves its own section because it's the thing most people get wrong.
When you connect an MCP server to an AI host, you're giving the AI access to whatever that server can reach. A Filesystem server with access to ~/.ssh/ is an AI with access to your private keys. A GitHub server with a write token is an AI that can push code to your repos.
The protocol includes capability negotiation — clients and servers declare what they support before anything happens. But "capability negotiation" is not "access control." The server still needs to implement its own security model, and the host needs to enforce its own permission boundaries.
The MCP Registry tries to help with discovery trust through namespace authentication (DNS verification, GitHub account ownership). But the registry explicitly states it delegates actual security scanning to package registries and downstream aggregators. It authenticates authorship, not behavior.
In practice, the security model is: trust the server author, trust the host's permission prompts, and hope the AI doesn't do something clever with the tools it's been given. For production use, you'd want least-privilege server configurations, separate tokens for each server, and human-in-the-loop confirmation for destructive operations.
This isn't a knock on MCP — it's a protocol, not a security framework. But anyone deploying MCP servers in production needs to understand that "the AI can call this tool" means "the AI has the permissions of whatever credentials you gave the server."
Why This Matters for AI Agents
Here's the throughline.
AI agents are defined by their tools. A language model without tools is a calculator that talks. A language model with a filesystem, a browser, a terminal, and an API client is an agent that can do real work.
MCP is the standardized way to give agents those tools. Before MCP, every agent framework had its own plugin format, its own tool definition schema, its own integration model. Building a tool for one agent meant it didn't work with any other.
Now? Build an MCP server once. It works with Claude, Cursor, VS Code, and any other MCP-compatible host. Write a tool that queries your company's internal API, and every AI tool your team uses can access it through the same interface.
This is why MCP adoption matters even if you never write a server yourself. The ecosystem effect compounds. Every new server makes every MCP-compatible agent more capable. Every new host makes every existing server more valuable. The network effects are real, and they're already past the tipping point.
For open-source AI specifically — models like GLM, DeepSeek, Qwen — MCP is especially important. These models don't come with a proprietary ecosystem like OpenAI's or Anthropic's tool integrations. MCP gives them a plug-and-play tool ecosystem that works the same way it works for the big proprietary models. It levels the playing field.
Should You Care?
If you build AI tools: yes, absolutely. MCP is becoming the standard integration layer. Not supporting it means your tool only works with bespoke integrations.
If you use AI tools: yes, indirectly. MCP support in your favorite AI app means it can connect to more data sources with less friction. You'll see more capable agents without needing to understand the protocol.
If you're just watching from the sidelines: the interesting story is the speed of standardization. MCP went from announcement to near-universal adoption in roughly 18 months. That's faster than OAuth, faster than OpenAPI, faster than most protocol standards. The AI industry moves fast, and when everyone has the same integration problem, a good solution spreads like wildfire.
The USB-C analogy works better than I thought. Not because MCP is a cable — but because everyone was tired of carrying seven different chargers.
AI agents are only as useful as the tools they can reach. CopperRiver supports MCP servers out of the box — connect your tools once, and your agent gets access to everything. See how it works.