MCP / An interactive field guide
Model Context Protocol (MCP) is an open standard that lets AI applications plug into outside tools and data — the same way USB lets any device plug into any computer. This page teaches you the whole picture, one packet at a time.
request travels out response travels back — a full round trip on one wire
§01 · The cast
Every MCP setup has the same three roles. Once you can tell them apart, everything else is just messages between them.
The app you actually use — Claude, an IDE, a chat interface. It runs the AI model and decides which servers to connect to.
The host owns the user experience: it asks for your permission before a tool runs, and it decides what the model is allowed to see.
A connector that lives inside the host. It speaks the protocol: it discovers what a server offers and carries messages back and forth.
Each client maintains exactly one connection to one server. A host that uses five servers simply runs five clients side by side.
A small program that exposes real capabilities — search a database, read files, call a weather API — in a standard shape any client understands.
Servers can run on your own machine (talking over standard input/output) or remotely over HTTP. The protocol messages are identical either way.
§02 · The three primitives
A server describes everything it can do using three building blocks. The easiest way to remember them: who gets to decide when each one is used.
Tools are actions. A tool is a function the AI model can choose to call while it works — fetch a forecast, create a calendar event, run a query. The server describes each tool with a name, a plain-language description, and the exact inputs it expects, so the model knows when and how to use it.
// what the server tells the client a tool looks like { "name": "get_forecast", "description": "Get the weather forecast for a city", "inputSchema": { "type": "object", "properties": { "city": { "type": "string" } } } }
Resources are data. A resource is read-only context the server makes available — a file's contents, a database record, a log. Resources don't do anything; the host application chooses which ones to hand to the model as background reading. Each one is identified by a URI.
// a resource is context, addressed by a URI { "uri": "file:///project/README.md", "name": "Project README", "mimeType": "text/markdown" }
Prompts are reusable templates. A prompt is a pre-written instruction pattern the server offers — "summarize this bug report," "review this code for security issues." The user selects one (often as a slash command), fills in any blanks, and the template shapes the conversation.
// a prompt template with one argument to fill in { "name": "summarize_bug", "description": "Summarize a bug report for triage", "arguments": [ { "name": "report_url", "required": true } ] }
§03 · The request flow
Here is the full round trip when the model uses a tool. Orange arrows carry the request out; green arrows carry the response back. The numbers are the order things happen.
get_forecast tool.tools/call protocol message.§04 · Hands on
Step through one real exchange — a user planning a trip — and watch which part of the system is active at each moment.
Everything starts in the host app. You ask something the model can't answer from memory — it needs live data.
// your message to the chat "What should I pack for Tokyo this weekend?"
The model scans the tool list its clients gathered from connected servers. It spots get_forecast — description and inputs match the question — and decides to call it with city: "Tokyo". The host asks for your approval before anything runs.
// the model's reasoning, roughly // "I need weather data. get_forecast takes a city. Use it." get_forecast(city: "Tokyo")
tools/call messageThe MCP client turns the model's intent into a standard JSON-RPC message and sends it down the wire to the server. This exact shape works with every MCP server ever written — that's the point of a protocol.
{
"jsonrpc": "2.0",
"id": 7,
"method": "tools/call",
"params": {
"name": "get_forecast",
"arguments": { "city": "Tokyo" }
}
}
The server receives the call and runs its own code — here, an ordinary HTTPS request to a weather service. The model never touches the external API directly; the server is the only part that knows how to talk to it.
// inside the server's get_forecast handler GET https://api.weather.example/v1/forecast?city=Tokyo // → 200 OK: rain Saturday, 18°C; clear Sunday, 22°C
The server wraps the API's answer in a protocol result message and returns it to the client. Note the id: 7 — it matches the request, so the client knows exactly which call this answers.
{
"jsonrpc": "2.0",
"id": 7,
"result": {
"content": [ {
"type": "text",
"text": "Sat: rain, 18°C. Sun: clear, 22°C."
} ]
}
}
The client hands the result to the model as fresh context, and the model folds it into a reply. From your side, it just looks like the assistant knew the weather.
// what you see in the chat "Saturday looks rainy (18°C), Sunday clear (22°C) — pack a rain shell and one light layer."
§05 · Check your wiring
Pick an answer to see instant feedback. You can change your answer any time.
§06 · Recap
JSON-RPC messages.