# MCP fundamentals: what the protocol does

The Model Context Protocol (MCP) is how AI applications talk to your tools and
data through one common standard, instead of a different bespoke integration for
every pairing. Anthropic open-sourced it in late 2024, and it is now the way
Claude Code, Claude Desktop, and most agents reach the outside world. This guide
is the mental model you need before you configure or build anything.

## What problem does MCP solve?

Before MCP, connecting M AI applications to N tools and data sources meant
writing M times N integrations. Every app needed custom code for every service.

MCP turns that into M plus N. Each app speaks MCP once, each tool speaks MCP
once, and they all interoperate. The common shorthand is that MCP is "USB-C for
AI applications": one port, many devices.

## What are the three roles in MCP?

MCP has three parts, and the names matter because the docs use them precisely:

- **Host** · the AI application that coordinates everything (Claude Code, Claude
  Desktop, an IDE, your own agent).
- **Client** · a connector the host creates to talk to one server. The host runs
  one client per server, each holding its own dedicated connection.
- **Server** · a program that exposes tools and data. It runs locally as a
  subprocess, or remotely over HTTP.

So a host with three servers connected is running three clients, each
with its own one-to-one link.

## What does an MCP server expose?

A server offers up to three kinds of capability, called primitives:

- **Tools** · functions the model can call to *do* something: query a database,
  open a pull request, send a message. The model decides when to call them. For
  how that call-and-return cycle works, see [tool calling explained](/guides/tool-calling-explained).
- **Resources** · read-only data the model can pull in for context: a file's
  contents, a database schema, an API response.Resources are usually application-driven: the host or user picks what to attach, the model does not fetch them on its own. If you want the model to grab data autonomously, expose it as a tool, not a resource.
- **Prompts** · reusable templates the host can offer the user, like a
  pre-built "review this PR" flow with the right instructions baked in.

The canonical example is a single database server that exposes a *tool* to run a
query, a *resource* for the schema, and a *prompt* with good [few-shot](/guides/few-shot-prompting) examples.
To see what real servers expose, browse [useful MCP servers](/guides/useful-mcp-servers).

## How does an MCP request flow?

When you ask Claude to do something that needs a server, this happens:

1. On startup, the host and each server shake hands and agree on a protocol
   version and what each side supports.
2. The host asks every server for its tool list and merges them into one set the
   model can see.
3. The model decides to call a tool. The host catches that, routes it to the
   right client, and the client sends the call to its server.
4. The server runs the work and returns the result.
5. The host feeds the result back to the model as context, and the model
   continues.

Seen over time, the startup handshake happens once, then the tool-call loop
repeats for every tool the model decides to use.Many readers picture the model dialing out and reaching a server itself, so they try to grant it network access or hand it API keys. It cannot. All the model ever produces is a request to call a tool by name, and everything past that point belongs to the host: routing the call, running it, returning the answer. Gate access where the wire is. That means the host or the server, never a phantom model connection.

## What is the difference between stdio and HTTP?

Servers connect over one of two transports:

- **stdio** · the host launches the server as a local subprocess and talks to it
  over standard input and output. No network, runs on your machine. This is the
  common case for local tools.
- **Streamable HTTP** · the server runs remotely and the host reaches it over
  HTTP, with support for tokens, API keys, and OAuth. This is how hosted, shared
  servers work.

You may still see an older SSE transport mentioned. It is deprecated and kept
only for backward compatibility; new servers use Streamable HTTP.

## Where you'll meet it

You do not have to build anything to benefit from MCP. You meet it the moment
you add a server to Claude Code, wire one into Claude Desktop, or connect an
approved remote connector. To put this into practice, [install your first MCP
server](/guides/install-your-first-mcp-server), or to go the other way and
[build an MCP server](/guides/build-an-mcp-server) of your own.