The Model Context Protocol (MCP) is an open standard for connecting AI applications to the tools and data they need to do real work. Instead of every agent building its own one-off integration for GitHub, Postgres, or your filesystem, MCP defines a shared interface: write a server once, and any MCP-aware client can use it.
If you’ve used Claude Code and wondered how it suddenly knows how to query your database or browse a repo, the answer is usually an MCP server. This article explains what the protocol actually is, the pieces it’s built from, and why it changed how coding agents get their context.
The problem MCP solves
A language model on its own is a closed box. It can reason about text, but it can’t see your files, run your tests, or read a row from your production database unless something feeds that context in. Before MCP, every tool integration was bespoke — one plugin format for one editor, a different API shape for the next agent. The work didn’t transfer.
MCP fixes that by standardizing the connection. Anthropic introduced the protocol and published the spec and SDKs openly, so it isn’t tied to a single vendor. A server you build for one client works with another that speaks MCP. That portability is the whole point.
Think of it the way USB standardized peripherals: the cable is the same regardless of which laptop or device sits on either end.
The client/server model
MCP has three roles, and it helps to keep them straight.
- Host — the AI application the user interacts with. Claude Code, the Claude desktop app, or an MCP-enabled editor are hosts.
- Client — the connector inside the host that maintains a one-to-one link with a single server. A host with three servers runs three clients.
- Server — a separate program that exposes capabilities (tools, data, prompts) over the protocol. A filesystem server, a GitHub server, a database server.
The host launches or connects to servers, the client handles the conversation with each one, and the server does the actual work when asked. The model never touches your systems directly — it asks the host, the host routes the request through the client to the server, and the result comes back.
MCP roles at a glance
| Role | What it is |
|---|---|
| Host | The app the user runs |
| Client | Per-server connector inside the host |
| Server | Program exposing capabilities |
Tools, resources, and prompts
A server can offer three kinds of capability, called primitives. Most servers focus on one or two.
Tools
Tools are actions the model can invoke. A GitHub server might expose create_issue or list_pull_requests; a database server might expose run_query. Each tool has a name, a description, and a typed input schema so the model knows what arguments to pass. Tools are the primitive people mean when they say “give the agent the ability to do X.”
Tools can have side effects — they write files, hit APIs, change state — so they’re also where most of the risk lives.
Resources
Resources are read-only data the server makes available: file contents, database records, log output, documentation. The host can pull a resource into context so the model can read it. The distinction from tools matters — a resource is something you read, a tool is something you run.
Prompts
Prompts are reusable templates the server offers, often surfaced as slash commands or menu items in the host. A prompt might package a code-review workflow or a structured bug report. They’re user-initiated shortcuts rather than things the model decides to call on its own.
Transports: stdio vs HTTP
The protocol needs a way to move messages between client and server. There are two common transports.
stdio is the default for local servers. The host launches the server as a subprocess and they talk over standard input and output. This is how most local tools run — a filesystem server, a SQLite server pointed at a local file. It’s simple, fast, and nothing leaves your machine.
HTTP-based transport is for remote servers that run as a network service. Instead of spawning a subprocess, the client connects over HTTP to a server that might live on another host or a managed platform. This suits hosted, multi-user, or always-on servers.
The rule of thumb: local utility on your own machine, use stdio. Shared or remote service, use HTTP. Under either transport the messages themselves are JSON-RPC, but the SDKs hide that so you rarely write it by hand.
Why this matters for Claude Code
Claude Code is an MCP host. When you run claude mcp add, you’re registering a server that Claude Code will connect to, and its tools become available to the agent during a session. That’s how Claude Code reads from a Postgres database, drives a browser through Playwright, or works against the GitHub API — each capability is a server, not hardcoded into the agent.
The practical payoff is that you extend the agent without waiting on Anthropic to ship a feature. Need it to talk to an internal service? Wrap that service in an MCP server and add it. The agent gains the capability the moment the server is connected.
Because the protocol is shared, the same server you wire into Claude Code can serve other MCP clients too. You’re not investing in a dead-end integration.
When you’re ready to wire one up, see the step-by-step walkthrough for setting up MCP servers in Claude Code on Windows and WSL. For a tour of which servers are worth your time, the best MCP servers for Claude Code roundup is a good next stop.
A quick mental model
If you remember nothing else, hold onto this:
MCP in five points
- It's an open standard for connecting AI apps to tools and data.
- Hosts run clients; each client talks to one server.
- Servers expose tools (actions), resources (read-only data), and prompts (templates).
- stdio runs servers locally; HTTP runs them remotely.
- Claude Code is a host — added servers extend what the agent can do.
The protocol is deliberately small. That minimalism is why it spread quickly: there’s not much surface area to implement, so clients and servers showed up fast. The ecosystem is large and still maturing, though — plenty of servers are early-stage experiments rather than production tools, so treat a new server with the same scrutiny you’d give any dependency.
Where to go next
MCP turned tool integration from a per-app chore into a shared standard. Once you understand the three roles, the three primitives, and the two transports, every MCP server you meet fits the same shape — which makes the whole ecosystem easier to reason about.
Next, get hands-on: add your first server in Claude Code, then dig into the broader Claude Code power-user guide to see how MCP fits alongside skills, subagents, and hooks.
