What is MCP (Model Context Protocol) and why it matters

I have Claude Code connected to Supabase, Gmail and Google Drive, and asking it to check a table or dig up an old email takes one sentence. No export, no copy and paste, no glue script I wrote myself. That works because of MCP.

MCP stands for Model Context Protocol. It is an open standard for letting an AI app talk to outside tools and data, and Anthropic announced it on 25 November 2024. If you use AI tools for work, or you’re choosing what to build on, the term keeps turning up in product pages and changelogs. Here is what it does, how a request flows through it, and which parts get oversold.

what it is

MCP is a protocol, which just means an agreed set of rules for how two programs swap messages. It is not a model or a product, and there is nothing to install on its own. The official docs compare it to a USB-C port for AI applications, and that is a fair picture. One standard socket, and anything with the right plug can connect.

The design borrows from the Language Server Protocol, the standard that lets one code editor support many programming languages without a custom integration for each. MCP does that job between AI apps and the systems they want to reach.

There are three roles:

host: the AI app you actually use, such as Claude Desktop, Claude Code, Cursor or VS Code
client: a small piece of code inside the host that holds one connection to one server
server: a program that exposes a capability, like reading files, querying a database or searching a ticket system

The server is not the AI. It is usually a small, dull program that wraps something you already have. The MCP project publishes reference servers on GitHub for things like the filesystem, git and web fetching, and there are official SDKs in TypeScript, Python, Java, Kotlin and C#, among others. Writing a simple server yourself is closer to an afternoon than a project.

how it works

Under the hood, MCP messages use JSON-RPC 2.0, the same plain request and response format a lot of APIs already use. What matters more is the order of events.

The host starts up and connects to each server you configured. The two sides swap a short handshake where each says which features it supports.
The client asks the server what it offers. The server replies with a list of tools, each with a name, a plain-English description and a schema for its inputs.
Those descriptions go to the model alongside your message.
If the model decides a tool would help, it writes a structured call, roughly “run the query tool with this SQL”.
The host usually shows you the call and waits for approval. Then the client sends it, the server does the work, and the result comes back into the conversation.
The model reads the result and carries on.

Notice where the intelligence sits. The protocol only carries messages. The model chooses tools based on the descriptions it was given, so a badly written description means badly chosen calls.

A server can expose three kinds of thing:

tools: actions the model can choose to call, like “create issue” or “run query”
resources: data the app can pull in as context, like a file or a database row
prompts: reusable templates the user picks, a bit like slash commands

Tools are by far the most widely supported. I haven’t tested every client, and support for resources and prompts is patchier, so check your specific app before you assume.

There are two common ways to connect. A local server runs as a process on your own machine and the host talks to it over stdio, meaning standard input and output. A remote server lives on the internet and the host talks to it over HTTP, which the spec calls Streamable HTTP. Remote servers are where the authorisation part of the spec comes in, and it is built on OAuth.

A local setup is mostly a config file. In Claude Desktop it looks like this:

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

That launches the reference filesystem server and lets it see one folder. Claude Code has a claude mcp add command that does the same from the terminal.

why it matters

Four reasons, in the order I care about them.

Custom connectors stop multiplying. Say you have five AI apps and ten systems to reach. Without a shared standard that is up to fifty separate integrations, each with its own auth and its own bugs. With MCP each app builds the client side once and each system builds the server side once, which is fifteen pieces. Anthropic’s announcement makes a version of this argument, and it is the practical reason vendors piled in.

Your tooling survives a change of model. OpenAI announced MCP support in March 2025, Google said Gemini would support it the following month, and Microsoft announced its own support at Build in May 2025. A server you set up for one assistant should work with the next one. When competitors agree on a standard, it is usually because a rival one wasn’t worth the fight.

Chat turns into action. A model with only your prompt can talk about your database. A model with a database server can query it, and with a ticket server it can file the ticket. That is the mechanism behind most of what people now call agents, and it comes with a bill, because every tool call is another round trip through the model. I go through the maths in what an AI agent actually costs to run.

Small teams can put their own systems behind an assistant. If you have an internal database, a wiki or a billing system with an API, one small server makes it reachable from any MCP client. I’d test one properly before rolling it out to anyone else, and evaluating an AI tool in an afternoon covers how I’d go about it.

common misconceptions

Four wrong takes I keep seeing.

“MCP is a Claude feature.” Anthropic wrote the first version, but the spec is open and developed in public on GitHub, and the clients now include tools from OpenAI, Google and Microsoft plus editors like Cursor and VS Code. Anthropic has since handed governance to the Linux Foundation, so check the docs for how that currently works.

“MCP makes the model smarter.” It doesn’t. It gives the model reach. It does nothing for judgment, and the model can still pick the wrong tool or misread what came back. Tool descriptions also sit in the context window, so connect a dozen servers and a lot of your budget is gone before you type anything. That is one road to the errors in what a token limit error actually tells you.

“It’s a standard, so it’s safe.” A standard says how messages are shaped. It says nothing about whether a server is honest. A local server runs with your user’s permissions, so one that can read your files can read all of them. Worse, text the model reads (a web page, an email, a support ticket) can contain instructions aimed at the model, which is the attack described in prompt injection in practice. My rule, and you can argue with it: I don’t connect a server I can’t skim the source of. A directory listing isn’t vetting. If the data is sensitive, where it ends up is a privacy question too, and The Privacy Wire is the better place to read about that side.

“MCP replaces APIs.” It sits on top of them. Most servers are a thin layer that calls a normal API and describes it in a way a model can use. And if a plain script does the job on a schedule with no model in the loop, use the script. It will be cheaper and easier to debug.

where to go from here

If you want to keep going, here is the order I’d read things in:

prompt injection in practice, before you connect anything that touches email or files
what an AI agent actually costs to run, for the money side
how to choose an embedding model and Weaviate vs Qdrant for RAG, if the data you want to expose is a pile of documents

The rest of the library is on the blog index. If you try MCP this week, start with one server pointed at a low-stakes folder and watch what the model does with it before you connect anything that matters.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-09-20.