MCP: The Protocol Quietly Rewiring AI

Quick take: MCP is an open standard that lets any AI assistant connect to any tool through a single common interface — instead of requiring a new custom integration for every app-and-tool pairing. It was released by Anthropic in November 2024, runs on plain JSON-RPC, and by 2026 has become the default wiring layer for AI agents. It is not a safety layer. Scope your servers narrowly.

Imagine you’re a developer who just built a tool that lets AI assistants search your company’s internal knowledge base. Congratulations — you’ve built it for Claude. Now your team switches to a different coding agent. You rebuild it. Then someone wants it in their terminal assistant. You rebuild it again. Somewhere around the fourth rewrite, you stop asking “how do I make this useful everywhere?” and start asking “why isn’t there a standard for this?”

In November 2024, Anthropic answered that question by releasing the Model Context Protocol — MCP for short. By mid-2026 it has quietly become the connective tissue of the AI tooling ecosystem, supported by a long list of IDEs, agent frameworks, and desktop assistants far beyond Anthropic’s own products. The spec and SDKs live at the community-run modelcontextprotocol.io.

The thesis here is not that MCP is magic. It is that MCP is boring in exactly the right way — a narrow, well-scoped protocol that solved a real coordination problem without trying to solve everything else. Understanding what it does and doesn’t do is the difference between using it well and trusting it with more than it can handle.

The Integration Tax That MCP Eliminated

Before MCP, every AI-to-tool connection was a custom job. Claude needed one integration to read GitHub issues; your IDE’s AI assistant needed a different one; your terminal agent needed a third. The underlying API was the same. The capability was the same. The code was not.

This is the M×N problem: M applications times N tools equals M×N integrations, each one custom-written, each one someone’s maintenance burden. A team with five AI tools and ten internal systems owed fifty integrations to the universe. Most of those integrations were never written, which meant most AI tools stayed sandboxed to whatever data happened to be in their prompt window.

MCP collapses that to M+N. A tool exposes one MCP server. Any MCP-capable client — every AI app that speaks the protocol — can use it. The team with five tools and ten systems now maintains fifteen things instead of fifty, and the tools they already use start working with new systems automatically.

That accounting is the whole economic argument for MCP. The protocol details are just how you cash it in.

Three Primitives, One Wire Format

MCP defines a client–server model with three roles. The host is the AI application you use — a desktop assistant, a coding agent, whatever. Inside it, one or more clients each maintain a connection to a single server: a small, purpose-built program that exposes a specific capability.

Communication uses JSON-RPC 2.0, which is about as unsexy a choice as possible, and deliberately so. The spec supports two transports: stdio (the server runs as a local subprocess, which is the common case for developer tools) and HTTP with Server-Sent Events for remote servers.

Every server can offer exactly three types of primitive:

• Tools — actions the model can call, like create_issue or run_query. The model decides when to call them.
• Resources — read-only data the model can pull in, like a file or a database record. Think of these as context, not commands.
• Prompts — pre-written templates a user can invoke explicitly. Useful for standardized workflows inside a team.

Each connection opens with an initialize handshake where client and server exchange protocol versions and declare capabilities. That one handshake is why an older host and a newer server can still negotiate what’s supported at runtime, without either side hard-coding the other’s behavior.

A concrete tool call — say, asking a filesystem server to list a folder — looks like this on the wire:

{ "jsonrpc": "2.0", "id": 1, "method": "tools/call",
  "params": { "name": "list_directory", "arguments": { "path": "/notes" } } }

The server replies with a structured result the model reads directly:

{ "jsonrpc": "2.0", "id": 1,
  "result": { "content": [{ "type": "text", "text": "ideas.md\ntodo.md\n2026-q3.md" }] } }

No model-specific glue. That’s intentional. The server doesn’t know or care which model called it; the model doesn’t know or care how the server implemented the tool. That decoupling is what makes portability real rather than theoretical.

What MCP Is Not (And Why That Matters More Than What It Is)

Here’s the original insight most MCP coverage buries: MCP is a coordination protocol, not a trust boundary. The distinction matters enormously for anyone evaluating it for production use.

When a model gets access to tools through MCP, it gains the ability to act. That’s the whole point. But MCP itself has no opinion about which actions are appropriate, no built-in sandboxing, and no way to verify that the content reaching the model hasn’t been crafted to manipulate it. The spec added authentication flows as the ecosystem matured, but they remain younger and rougher than, say, the OAuth tooling you’d use for a human-facing app.

Three concrete risks worth internalizing:

Prompt injection via tool output. If a model can call tools and also reads untrusted content — a web page it fetched, an email it summarized — that content can embed instructions designed to hijack subsequent tool calls. MCP does not address this. The defense lives in how you design the agent’s behavior, not in the protocol.

Overly permissive server scope. A filesystem server pointed at your home directory can read your SSH keys, your .env files, and your browser’s saved credentials. The protocol faithfully delivers whatever the server exposes. Scope servers narrowly, at the folder or resource level, before you wire them to anything sensitive.

Capability creep from third-party servers. The reference implementations — filesystem, GitHub, Slack, Postgres, web-fetch — are straightforward to audit. The hundreds of community servers in the registry are not. Treat a third-party MCP server with the same suspicion you’d give a third-party npm package with broad filesystem access: read the source before you run it.

None of this means MCP is unsafe. It means it’s a powerful primitive that inherits the responsibilities that come with power.

The Five-Minute Test Drive

You don’t need to write code to see MCP work. The fastest path to a running example:

1. Pick a host that speaks MCP — a desktop AI assistant or an MCP-capable code editor.
2. Add a reference server in its settings. The official filesystem server needs just a few lines of config:

{
  "mcpServers": {
    "files": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/notes"]
    }
  }
}

1. Restart the host so it launches the server subprocess.
2. Ask a question that requires the tool — “what’s in my notes folder?” — and watch the assistant call the server instead of guessing.
3. Tighten the scope. Point the server at one specific folder, not your whole home directory, before you trust it with anything real.

That’s the entire loop: declare a server, grant a scope, ask. The fact that setup is this lightweight is part of why adoption moved fast.

How the Same Server Became Infrastructure

The pattern that defines MCP in 2026 isn’t the individual developer running a local filesystem server. It’s the team that stood up one internal MCP server in front of its database and ticketing system, and now every AI tool the company approves can query it under the same permissions — one integration, one audit log, no per-tool glue.

That’s the organizational payoff the M+N math was always pointing toward. One server, maintained by whoever owns the data, accessed by every AI client that gets approved. New AI tool joins the stack? It speaks MCP. It works. No new integration required.

The reference implementations cover the obvious ground — filesystem, GitHub, Slack, Postgres, web-fetch are all available and actively maintained. Beyond those, the official registry lists hundreds of community servers, and a growing list of IDEs and agent frameworks in the open-source AI space now ship native MCP clients.

The same GitHub server can power your code editor, your terminal agent, and your chat assistant interchangeably — because they all speak the same protocol. That cross-client portability is what distinguishes MCP from the vendor-specific plugin systems it replaced, and it’s why AI agent tooling has converged on it rather than fragmenting further.

Is MCP the Same as Function Calling?

No, and conflating them is the most common source of confusion. Here’s how they differ in practice:

Function calling is how a model invokes a function inside one application. MCP is the protocol that makes those functions discoverable and callable across applications. Function calling is local; MCP is portable.

Does MCP Replace Your Existing API?

No. Your service’s REST API is still the interface humans and traditional software use. The MCP server is a thin adapter that translates the AI-native tool call interface into whatever your API already accepts. You’re adding a surface, not replacing one — and you can version and deprecate MCP servers independently of the underlying API.

Who Should Actually Build an MCP Server?

Any team that wants multiple AI tools to access the same internal system without writing a new integration per tool. If you find yourself writing the same data-access code for three different AI clients, that’s the signal. A single MCP server stops that duplication cold.

For individual developers, the Python and TypeScript SDKs make a basic server short — the scaffolding for a tool that wraps a REST endpoint is a few dozen lines.

Verdict: Start Narrow, Expand Deliberately

MCP is ready to use in 2026. The ecosystem is stable, the reference servers are well-maintained, and the tooling is lightweight enough that a working integration takes an afternoon, not a sprint.

The right starting move is a scoped reference server: one folder, one database, one API — not your whole home directory or your entire internal stack. Verify that the host correctly discovers and uses the tools. Then expand scope only as you gain confidence in the agent’s behavior and the server’s access controls.

Developers: writing one MCP server is the highest-leverage way to make a tool available everywhere AI clients go. Users: MCP is why your assistant can finally act on your real data — provided you set the permissions with the same care you’d apply to any system-level integration. The protocol is sound. The permissions are your job.

Last verified: June 2026. Based on the official Model Context Protocol documentation and Anthropic’s original announcement.