MCP: The Protocol That Lets AI Talk to Everything

Every developer who has built more than one AI application has written the same code three times.

The code that connects the AI to your database. The code that gives it access to your files. The code that lets it call your internal APIs. Each implementation is slightly different, handles errors differently, authenticates differently, and needs to be maintained separately. It's the hidden tax on every AI project that ships beyond a prototype.

MCP is the attempt to make you write it once.

What MCP Actually Does

Model Context Protocol is an open standard for connecting AI applications to external data and tools. The description Anthropic's team uses, "USB-C for AI," is accurate in the specific way that makes it useful: you define the interface once, and anything that speaks the protocol can plug in.

Without MCP, the integration story looks like this: you're building an AI assistant, and you want it to have access to your Notion workspace. You write code to talk to the Notion API, parse the responses into a format the LLM can use, handle rate limits, handle auth, and surface errors in a way the model can understand. Then you want it to access your database. Same process, different system. You end up building and maintaining as many integration layers as there are data sources.

With MCP, you write a server for each data source. That server advertises what it can do. Any MCP-compatible client (Claude Desktop, VS Code with Copilot, Cursor, Claude Code) can discover and use it without any additional integration work. Your Notion server works with every AI tool that supports the protocol.

The Three Primitives

MCP servers can expose three types of things:

Tools are functions the AI can call to take actions: run a database query, create a calendar event, send a Slack message, deploy a service. The server defines what the tool does and what arguments it takes. The AI decides when and how to use it based on the task at hand.

Resources are data the AI can read: file contents, database records, API responses. The model pulls them in as context. Resources are passive (the AI reads them); tools are active (the AI calls them).

Prompts are reusable instruction templates. A prompt might define how to analyze a specific type of document, or how to write in your company's style. The AI can invoke them by name rather than you repeating the instructions every time.

In practice, most of the interesting work happens through tools, because tools are how AI goes from knowing things to doing things.

The Mechanics Are Worth Understanding

MCP runs on JSON-RPC 2.0, a straightforward remote procedure call standard. When an AI client connects to a server, they exchange capabilities in a handshake: each side says what it supports, they agree on a protocol version, and the connection is established.

The client can then call tools/list to see what's available, tools/call to invoke a specific tool with arguments, and resources/read to fetch data. Responses come back in a standardized format the AI can parse.

Two transport options exist. Local servers run as a subprocess; the AI application launches them and communicates through standard input/output. Remote servers use HTTP with optional streaming. The same server code can support both since the wire format is identical.

One feature that distinguishes MCP from a simple API wrapper: servers can push notifications to clients. If your tool list changes (a user revokes permissions, a new service comes online), the server tells the client immediately rather than waiting for the client to ask. For dynamic environments where capabilities change, this keeps the client's view accurate.

Where the Ecosystem Stands

VS Code with Copilot, Claude Desktop, Cursor, and Claude Code all support MCP. Anthropic published reference server implementations for filesystems, databases, GitHub, Slack, and a handful of other common systems. The community has built hundreds more.

The parts that are still maturing: authentication for remote servers is not fully standardized, long-running task support (labeled "tasks" in the spec) is experimental, and some client implementations lag behind the spec. The stable core (tools, resources, local transport) is reliable for production. The experimental parts should be treated accordingly.

The Separation MCP Creates Is the Point

What MCP accomplishes is a useful separation of concerns: AI models improve on their own schedule, and data sources stay where they are, and MCP is the layer that connects them without either side needing to adapt to the other.

Before MCP, a better model meant rebuilding integrations because the new client needed new glue code for the same systems. After MCP, a better model just speaks the same protocol to the same servers.

That decoupling has business implications. A small team can build MCP servers for their internal systems once and get the benefit of every subsequent model improvement without integration work. A vendor can build one MCP server for their product and support every AI client their customers use. The integration tax doesn't disappear, but you pay it once per data source instead of once per AI tool.

You still have to write the servers. But you write them once, and they work everywhere that speaks the protocol.