What is MCP (Model Context Protocol)?

Why a protocol was needed

Before a standard existed, connecting a model to an external capability meant writing an integration for one specific pairing. Every assistant had its own plugin format; every tool provider re-implemented the same integration once per assistant. Ten tools and five clients is fifty integrations, and every one of them rots independently.

MCP replaces that grid with two sides of one contract. A server describes what it offers in a machine-readable form. A client reads that description and can immediately use it. Ten tools and five clients becomes fifteen implementations, not fifty — and any new client gets every existing server for free.

MCP is often described as a USB-C port for AI applications, and the analogy holds as far as it goes: one shape of connector, many devices behind it. The part the analogy misses is that a USB-C cable does not explain itself. An MCP server does. It hands the client a full description of every capability it has — names, arguments, types, what is required — so the model on the other end is choosing from a menu rather than guessing at a socket.

MCP architecture: host, client, server, transport

Four moving parts, and usually only one of them is yours to think about. The distinction people miss most often is between the host and the client: the host is the application, and it opens one client per server it connects to.

Tools, resources and prompts

A server can expose three kinds of thing. In practice most servers, this one included, are mostly about the first.

How MCP works, step by step

Underneath, MCP is JSON-RPC 2.0. A session runs the same four beats every time, whether the server is a local subprocess or an endpoint on the other side of the internet.

1. 1Connect and negotiateThe host starts a client, which opens a session and exchanges capabilities with the server: protocol version, which primitives each side supports, what it will and will not do.
2. 2DiscoverThe client calls tools/list. The server returns every tool with its name, description and JSON schema. The host passes that list to the model as callable tools.
3. 3DecideThe model reads the schemas and chooses — including choosing not to call anything. This is the step that separates MCP from an API: nobody hard-coded the sequence.
4. 4Call and returnThe client sends tools/call with the arguments the model chose. The server does the work and returns a result, which goes back into the conversation for the model to act on.

Step four on the wire looks like this. You will rarely write it by hand — your client does — but seeing it demystifies the whole thing.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "generate_image",
    "arguments": {
      "prompt": "a paper boat on still water",
      "aspectRatio": "16:9"
    }
  }
}

That is the entire mechanism. Everything else — capability negotiation, notifications, streaming, progress reporting — is machinery around this one idea.

MCP vs API vs RAG

These get compared as if you had to pick one. You do not — they sit at different layers, and a serious agent usually runs all three.

MCP is not a replacement for your API. Almost every MCP server is a thin protocol layer in front of an ordinary HTTP service — this one included. The same eight image operations are REST endpoints and MCP tools, on purpose, so an agent and a batch job can both do the work without either being forced through the wrong door. If you are weighing the two for a specific integration, the full MCP vs REST comparison goes through the trade-offs case by case.

And MCP is not a replacement for RAG either. RAG puts context in before the model runs; MCP lets the model reach for something during the run. A retrieval step can itself be exposed as an MCP tool, at which point the model decides whether the lookup is worth doing at all — which is usually cheaper than retrieving on every turn.

What MCP actually buys you

Security and trust

Connecting a server means letting a model take actions on your behalf, so it is worth being deliberate about which ones you install. Three things are worth checking before you paste a config.

• Tool descriptions are input to the model. A malicious server can write instructions into a tool description and try to steer the agent. Install servers from sources you would trust with a dependency in your package manager, and no further.
• Scope the credential, not the account. Give the server its own API key with only the permissions it needs, and keep that key in an environment variable rather than committed config. If it leaks, you revoke one key.
• Keep a human on destructive actions. Most hosts can require approval per tool call. Leave that on for anything that writes, deletes, spends or sends. Read-only and generative tools are the safe ones to let run unattended.

When MCP is worth it

The fastest way to understand the protocol is to watch a client use one. Connecting an image server takes a single config entry, and the model has eight new tools the moment it restarts — setup guides for every major MCP client are a click away.

Frequently asked questions about MCP

Sources

• Model Context Protocol — specification and introduction
• Anthropic — Introducing the Model Context Protocol (Nov 2024)
• MCP specification — transports