The Model Context Protocol (MCP) is a protocol, built on JSON-RPC , that lets an AI application call capabilities hosted by a separate service. This lesson covers the three roles it defines, what a server exposes, and why the protocol is stateless.
Why build an MCP server
- Internal system access: give an agent a way into a ticketing tool, a deploy pipeline, or a customer database
- One integration instead of many: expose a service once and every MCP-capable application can use it, instead of writing and maintaining a separate integration per assistant
- Live data: let an agent read schemas, logs, or config that isn't in the model's training data
- Tasks a model shouldn't guess at: wrap operations like running a query or sending an email
The three roles
| Role | What it is | Examples |
|---|---|---|
| Host | The application a person uses, with a model in it | VS Code, Claude Desktop, Cursor |
| Client | Created by the host, communicates with exactly one server | The MCP client built into VS Code |
| Server | Exposes capabilities and answers requests | What you'll build in this course |
A host runs one client per server and aggregates the context they provide. Add a new server to the host and its capabilities become available immediately, with no changes to the model or the host itself.
Note: the server you start with runs as a subprocess that the host launches on your own machine, with nothing listening on a port. Lesson 9 moves the same server onto Streamable HTTP, where it does listen on one. Either way, "server" here means a program that answers MCP requests, not a machine in a data center.
What a server exposes
Three primitives, and the difference between them is who decides when they're used:
| Primitive | Controlled by | What it's for |
|---|---|---|
| Tool | The model | An action the model can decide to take: query a database, create an issue, send an email |
| Resource | The host | Read-only content the host can pull into context on its own: a schema, a config file, a log |
| Prompt | The user | A message template a person selects by name, usually as a slash command |
Why the protocol is stateless
Every request an agent sends is self-contained : it carries the protocol version it speaks and the capabilities it supports right alongside the request. A server can inspect any single request and know exactly how to respond, without remembering anything about earlier requests from that same agent.
That's what makes MCP servers straightforward to scale: any server instance can handle any request, and there's no per-agent state to keep in sync between instances. It's also the constraint that shapes lesson 9, where a tool that needs to remember something between calls has to store it somewhere other than the server instance.
Check your understanding
Tool, resource, or prompt?
Your server needs to expose your production database schema so the assistant can reference it while writing queries. The schema is read-only and gets referenced repeatedly across a conversation. Which primitive fits, and why?