MCP: What It Is and Why It Exists.

The problem: every AI-to-tool connection used to be handmade

AI models on their own can only do two things: read the text you give them and write text back. They cannot check your calendar, query your database, or open a browser. To do real work, they need connections to outside systems, and until late 2024, every one of those connections was custom-built.

That creates a multiplication problem. Say five AI applications each need to talk to five services: GitHub, Gmail, Slack, a database, a browser. That's twenty-five separate integrations, each with its own authentication, its own tool descriptions, its own edge cases. Developers who tried it describe the authentication piece alone as "as painful as it gets": three services meant three different login flows to build and maintain.

The Model Context Protocol (MCP) is Anthropic's answer, released as an open standard in November 2024. It defines one common way for AI applications to discover and use external tools and data. Build the connection once, on either side, and it works with everything else that speaks the protocol. The multiplication problem becomes addition: five apps plus five services means ten implementations, not twenty-five.

The comparison you'll see everywhere, including the official documentation, is USB-C. Before it, every device had its own charger; after it, one port fits all. MCP aims to be that port for AI applications.

One more reframing that makes MCP click: an MCP server is essentially a wrapper around an API. Users who built their own put it plainly: if something has an API, you basically already have the makings of an MCP server for it. The protocol doesn't replace existing APIs; it gives models a standard way to find them, understand them, and call them. And the name itself is a hint often lost in the noise: it is the Model Context Protocol. The point is getting relevant context and capabilities to the model, which cannot read your mind, only your connections.

The anatomy: host, client, server

Every MCP setup, no matter how elaborate, has three participants:

• The host is the AI application you actually use: Claude Desktop, Claude Code, Cursor, VS Code, a chatbot you built. It coordinates everything.
• The client is a component inside the host that maintains a dedicated 1-to-1 connection to a single server. A host that talks to four servers runs four clients. You never touch clients directly; the host manages them.
• The server is a program that exposes capabilities: the wrapper around GitHub, your filesystem, a weather API, your company database.

Take a concrete example you'll meet again in this series: connecting a coding assistant to GitHub. The assistant (host) spins up a client, which connects to the GitHub MCP server. The server tells the client what it can do; from then on, the model can list issues, read pull requests, and create branches through that one standardized channel. Add a second server (say, a browser) and the host simply creates a second client. Nothing about the GitHub connection changes.

Servers run in two places. Local servers run as processes on your own machine and talk to the host over standard input/output, which is right for anything that needs your filesystem or local apps. Remote servers run on someone else's infrastructure and speak HTTP, which is right for cloud services, where the provider hosts one server and every user connects to it. X's hosted MCP server, for example, gives any compatible agent access to its real-time data with no local setup at all. Under the hood, both variants exchange the same JSON-RPC messages; only the transport differs.

What a server can offer: tools, resources, prompts

The protocol defines three kinds of things a server can hand to the host: the official docs call them primitives (worth knowing outside the bookmarks, because most tweets only ever mention the first one):

• Tools are executable functions the model can decide to call: create an issue, run a query, fetch a forecast. Each tool ships with a name, a description, and a schema of its inputs, which is exactly how the model knows what it does and how to call it.
• Resources are data sources the application can read for context: file contents, database schemas, API responses. Where a tool does something, a resource is something.
• Prompts are reusable interaction templates a server can provide: pre-written starting points for tasks the server is good at.

A database server makes the trio concrete: tools to run queries, a resource containing the schema, and a prompt with worked examples of how to ask good questions of that database.

Discovery is what makes this dynamic. When a host connects to a server, the two first negotiate what they each support, then the client asks "what have you got?" (tools/list), and the server answers with its current catalog. If the catalog changes later, the server can notify the client to refresh. Nothing is hardcoded on the model's side, which is why you can bolt a brand-new server onto an existing assistant and it just starts using it.

Servers can also ask things of the application: they can request a model completion (so a server can use AI without shipping its own model access) and they can ask the user a clarifying question mid-task. Those two, sampling and elicitation in protocol terms, are what turn MCP from a one-way tool catalog into a two-way conversation.

Why it stuck: the ecosystem effect

Protocols live or die by adoption, and the bookmark record traces MCP crossing that threshold. Early on, even sympathetic developers found the docs "inscrutable" and the value unproven; one built a toy server specifically "to form my own opinion" and came away convinced it wasn't hype. By mid-2025 the question was settled by who showed up:

• Platform owners shipped official servers. GitHub released its open-source server in April 2025; the same week, AWS published a whole collection, and Cloudflare was building its server in public. draw.io, ElevenLabs, and dozens more followed. A third-party analysis counted the registry growing from 425 to 1,412 servers in six months, a 232% jump.
• Businesses exposed themselves as MCP endpoints. Every Shopify storefront now serves an MCP endpoint that lets any capable agent query the catalog, build a cart, and check order status. Salesforce went further and declared "our API is the UI," exposing its entire platform as APIs, MCP, and CLI. The product itself becomes something agents plug into.
• Rival AI vendors adopted it. The strongest signal that MCP is a genuine standard rather than an Anthropic feature: Google's Gemini documentation added official MCP examples, Google released an MCP Toolbox for databases, and OpenAI's tools, Cursor, VS Code, and ChatGPT all speak it. Vercel summarized the consensus: MCP is becoming the standard for building AI model integrations.
• Inside companies, it became infrastructure. Shopify's engineering leadership reported roughly a dozen internal MCP servers with the number growing quickly, the same build-once-connect-everything logic applied to private systems.

One boundary worth drawing: MCP standardizes how an agent reaches tools and data. It does not cover how agents talk to other agents; that's the territory of complementary protocols like Google's Agent2Agent (A2A), announced with 50+ partners in April 2025, one of more than a dozen protocols competing in the agent-communication space. If you remember one division of labor: MCP connects a model to capabilities; A2A-style protocols connect agents to each other.

Where to go next

You now have the mental model: a host runs one client per server; servers offer tools, resources, and prompts; discovery is dynamic; local servers speak stdio and remote ones speak HTTP.

The rest of this series makes it practical:

• mcp-02: plugging existing servers into your daily work, with the exact commands.
• mcp-03: the context-window cost that made power users abandon MCP for a while, and the patterns (tool search, code execution) that fixed it.
• mcp-04: building your own server around any API, in about thirty lines of Python.

If you want the primary source, the official documentation at modelcontextprotocol.io covers the architecture in depth, and a two-hour workshop by MCP's creator at Anthropic (bookmarked below) walks the whole protocol end to end.