Why MCP exists

In the last course you gave an agent tools by writing them straight into your Python script. That works — for that script. But the moment you want the same tools in Claude Desktop, in your editor, and in a teammate's app, you're writing the same integration three times, three different ways. MCP fixes that.

The M×N problem

Say there are M AI apps (Claude Desktop, Claude Code, editors, your own bots) and N things you'd want them to reach (your files, GitHub, a database, an internal API). Wire each app to each tool directly and you're on the hook for M × N custom integrations — and every new app or tool multiplies the work.

The Model Context Protocol turns that into M + N. Each app speaks MCP once; each tool is an MCP server once; any app can talk to any server. It's often called "USB-C for AI" — one standard plug instead of a drawer full of adapters.

Three roles

MCP has a simple shape:

• Host — the AI app the person actually uses (Claude Desktop, Claude Code).
• Client — the connector inside the host that speaks MCP, one per server.
• Server — the thing you'll build: it exposes your tools and data over the protocol.

You build servers. The host and client are already written for you.

Three things a server exposes

Every MCP server offers up to three kinds of capability — you'll build all three in this course:

• Tools — actions the AI can take (run code, hit an API, change something). Like a POST.
• Resources — data the AI can read to load into its context (a file, a record). Like a GET.
• Prompts — reusable, fill-in-the-blank templates a user can invoke on demand.

Set up

You need Python 3.10+ and the official SDK, which ships with a handy CLI:

pip install "mcp[cli]"

That's everything — building and testing a server needs no API key and no cloud account. Next, you'll write a complete server in about fifteen lines.