What MCP is, and the problem it solves
> This course now describes an earlier version of the protocol (2025-11-25). The Model Context Protocol became stateless in the 2026-07-28 revision — initialize was replaced by the optional server/discover, and sampling, roots and protocol logging were deprecated. For the current protocol and Python SDK v2, taught as a code-along, read MCP in Practice. What follows is kept for reference.
An LLM knows exactly two things: what was in its training data, and what is in its context window right now. Everything an AI application does — answer from your documents, check an order, file a ticket — reduces to one engineering problem: getting the right things into that context, and the model's decisions back out. For the first few years of the LLM era, every application solved that problem privately, and the private solutions did not compose.
This course is about the protocol that ended that era. By the close you will have built both sides of it — a server that exposes real capabilities and a client that discovers and drives them — read the actual bytes that cross the wire, broken it in the ways it actually breaks, and secured it against the attacks that are specific to it. Every frame of protocol traffic shown in this course was captured from a live session, not typed from documentation.
The road to MCP, compressed
The pre-history matters because each stage left an idea the protocol kept.
Prompt stuffing came first: paste everything relevant into the prompt. It works until the context fills, and its refinements — sliding windows, summarised history — are all lossy triage. The lesson it left: context is a scarce resource under someone's management.
RAG made fetching systematic: retrieve the relevant passages, then generate. But retrieval pipelines are bespoke — every application wires its own sources. The lesson: the model should reach for knowledge, not have all of it shovelled in.
Function calling (2023) let the model emit a structured request — "call get_order with {"id": "PT-1041"}" — that your code executes. This was the real breakthrough and the real bottleneck: every application defines its own functions, in its own format, wired by hand to every backend. The lesson: the model can decide; what was missing was a standard for what it decides against.
The M×N problem
Count the integrations. M applications (Claude Desktop, Cursor, your internal chatbot, a support desk…) each need N systems (GitHub, Postgres, Slack, your order database…). Every pair is a bespoke adapter: M×N pieces of glue, each with its own auth, its own format, its own maintenance. Ten apps and twenty systems is two hundred integrations. Nobody builds two hundred integrations; they build four, and the rest never happens.
The Model Context Protocol collapses M×N to M+N. A system exposes its capabilities once, as an MCP server. An application implements the client side once. Any client can then use any server — the twenty-first server costs its builder one implementation, and every existing app gets it for free.
If this rhymes with something, it should. The Language Server Protocol did exactly this for editors and languages in 2016: before LSP, every editor implemented every language's tooling; after, each side implemented one protocol, and language support stopped being an editor feature. MCP's designers cite LSP directly, and the family resemblance runs deep — JSON-RPC underneath, capability negotiation at startup, a long-lived session. The looser analogy you will hear is USB-C: one connector, any device. It is a fine slogan as long as you remember the important half is not the plug but the negotiation — both sides discovering, at connection time, what the other can do.
What MCP is, precisely
An open, vendor-neutral specification — released by Anthropic in November 2024, adopted across the industry through 2025 — that standardises how an AI application and an external capability provider talk. It defines the message format (JSON-RPC 2.0), the session lifecycle (initialise, discover, use, terminate), and a small set of primitives — tools, resources, prompts, sampling — that cover, surprisingly well, everything an AI application needs from the outside world.
Equally important is what MCP is not. It is not an agent framework — it does not decide when to call a tool, loop, or plan; that intelligence lives in the application (lesson 10 makes this concrete). It is not a model feature — any LLM works behind it. And it does not make integrations safe by standardising them; it makes them uniform, which cuts both ways, and section 4 of this course is about the second edge.
The three roles
Every MCP conversation involves three parts, and keeping them straight is the mental model for the whole course. The host is the user-facing application — Claude Desktop, your IDE, your chatbot. The client is the protocol driver inside the host, one per server connection. The server is the capability provider — a small program, often a hundred lines, that speaks the protocol on one side and your actual system on the other. Lesson 2 takes these apart properly.
Where this course goes
Section 1 gives you the architecture and the wire — by the end of lesson 4 you will have read a complete session, frame by frame. Section 2 covers the four primitives and the control model that makes them more interesting than they first look. Section 3 builds both sides for real: a server with craft, a client from scratch, testing, and wiring into the hosts you already run. Section 4 is the threat model, the defences, sandboxing, and the ecosystem.
The running example throughout is Paper Trail Books — a small online bookstore whose operations we expose over MCP: order lookups, refund drafting, a returns policy, a weekly report workflow. Small enough to hold in your head, real enough to exercise every primitive and most of the failure modes.
If you have read Claude for Developers, its MCP lesson showed you the view from one host. This course is the protocol itself — both sides of the wire, any host, any model.