How MCP Actually Works

Host, client, and MCP server: tools, resources, prompts, and why local stdio comes first.

Three roles show up in every MCP setup. Mixing them up is the usual source of “I started the server but the AI cannot see it.”

Host, client, server

Host — the app the human uses (an IDE or desktop assistant). It owns the conversation and the model.
Client — code inside the host that speaks MCP. You rarely write this yourself.
Server — your process. It advertises tools, resources, and prompts. This course is about that process.

The host starts (or connects to) the server, asks what it can do, then the model may request a tool call. The client forwards that call. Your server runs Python and returns a result. The host folds the result back into the chat.

Tools, resources, prompts

Tools — actions with arguments. “Create a ticket.” “Fetch weather for a city.” These are what most first servers need.
Resources — readable data at a URI, more like a file the model can open than a function it calls. Logs, a config snapshot, a schema.
Prompts — named recipes the host can offer (“review this diff”). They are not the system prompt for the whole app.

You will build a tool in Build Your First Tool, then compare resources in Resources vs Tools.

stdio first, remote later

A local server is usually started as a child process. The host talks over stdio (JSON-RPC on stdin/stdout). That is the right first target: no ports, no TLS, easy to debug. A remote server listens on HTTP so a laptop across the network can use it. We stay on stdio through the first half of the course, then move it off the laptop.

Next: create the project and get a server running.