What is MCP?

The protocol, the three primitives, why it matters.

Every time you wanted to give an LLM access to your data (Gmail, your database, your file system), you wrote a bespoke integration. Every time. For every model. For every app. Model Context Protocol (MCP) is Anthropic's answer to that mess. Released as open source in November 2024, it gives LLM apps and external systems a single standard language to speak. Think of it as the USB-C of AI tooling.

The problem MCP solves

Before MCP, every AI app shipped its own custom plumbing. Cursor had one way to talk to your file system, Claude Desktop had another, ChatGPT had a third, and your homemade agent had a fourth. If you built a Postgres connector for Claude, it was useless to anyone using Cursor. And vice versa.

MCP says: let's standardize the wire format and the verbs. Once a service speaks MCP, any MCP-capable host can use it. Build the connector once, plug it into any host.

USB-C analogy

Before USB-C, every device had a different port. After USB-C, one cable charges your laptop, phone, and headphones. MCP is doing that for AI: one connector standard, many hosts and many services.

The three primitives

MCP servers expose three kinds of things. Memorize these. They show up in every spec doc and SDK.

Tools are functions the model can call. send_email, query_db, create_issue. They take typed input and return a result. The model decides when to invoke them.
Resources are data the model can read. Files, database rows, log entries, API responses. Each has a URI like file:///home/me/notes.md or postgres://db/users/42. The host (or model) chooses which to load into context.
Prompts are templates users can invoke intentionally. Slash commands, basically. /summarize-pr on a server might expand to a curated system + user message about how to summarize.

The split is by who initiates

Tools = the model decides to call them. Resources = the host loads them as context. Prompts = the user picks them on purpose. Same underlying machinery, three different control models.

Host, client, server: the architecture

MCP has three roles. Get these straight and the docs stop being confusing.

Host: the user-facing app. Claude Desktop, Cursor, Zed, Windsurf, your custom agent. The host wraps the LLM and the UI.
Client: an instance inside the host that connects to exactly one server. A host typically runs many clients in parallel, one per server.
Server: the thing exposing tools, resources, and prompts. Could be a local Node process reading your file system, or a remote HTTP endpoint serving GitHub-on-MCP.

bash

# Conceptually, a host like Claude Desktop runs something like:
#
#   Host (Claude Desktop)
#   ├── Client A ── stdio ──> filesystem MCP server (local)
#   ├── Client B ── stdio ──> postgres MCP server   (local)
#   └── Client C ── HTTP  ──> github MCP server     (remote)
#
# Each client talks to exactly one server. The host orchestrates them all
# and feeds their tools/resources to the model.

Two transports: stdio and Streamable HTTP

MCP defines two ways for client and server to communicate:

stdio: the server is a subprocess. Messages are JSON-RPC over stdin / stdout. Zero network. Perfect for local tools that need access to your filesystem or local DB.
Streamable HTTP: the server is a remote endpoint. Client posts JSON-RPC requests, server responds (and can stream notifications back via SSE on the same connection when needed). This replaced the older SSE-only transport in the March 2025 spec. Used for hosted services like GitHub MCP, Notion MCP, etc.

The transport landscape moved

If you read docs from late 2024 they mention an SSE-only transport. That has been deprecated in favor of Streamable HTTP, which uses one endpoint, supports resumable streams, and is friendlier to load balancers. New servers should target Streamable HTTP.

What a real exchange looks like

Under the hood, MCP is JSON-RPC 2.0. Here is a (truncated) initial handshake plus a tool call:

initialize.json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": { "roots": { "listChanged": true } },
    "clientInfo": { "name": "claude-desktop", "version": "0.9.0" }
  }
}

tools-call.json

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "search_repos",
    "arguments": { "query": "rust embedded", "language": "Rust" }
  }
}

The server replies with a list of content items (text, images, embedded resources). The host hands those to the model, which decides whether to call again or to answer the user.

Why web developers should care

MCP started in the AI tooling world, but it is already crossing into backend engineering. Companies that ship REST or GraphQL APIs are now shipping MCP servers alongside them. GitHub, Stripe, Cloudflare, Sentry, Notion, Linear all have official MCP servers as of 2025. The implication for you:

Your future backend may expose POST /api/... for browsers and /mcp for AI agents. Two interfaces, one set of business logic.
When you build internal tools, exposing them as MCP servers makes them instantly usable by every AI agent in your org.
When you build an LLM app, you can consume any MCP server in the ecosystem instead of writing yet another bespoke integration.

MCP server registries

There are public registries (modelcontextprotocol.io, Smithery, mcp.so) that index hundreds of community and official servers. Before building a new one, search there. There is a good chance someone already shipped what you need.

Quick quiz

Quiz1 / 3

What problem is MCP designed to solve?

Recap

MCP is an open protocol from Anthropic for connecting LLM apps to external tools, data, and prompts.
Three primitives: tools (functions), resources (data), prompts (templates).
Architecture: host (the app), client (one connection), server (the integration).
Two transports: stdio for local subprocess servers, Streamable HTTP for remote ones.
Web devs increasingly ship MCP servers alongside REST APIs so AI agents and humans can both use the same backend.