How This Course Works
One notes assistant, built piece by piece
You do not study eleven separate subjects. You build one thing, a research notes assistant for Nare, who runs a small (made-up) sleep and memory lab, and every module adds a part to it: the server over her notes, a host that lets a model use it, authorisation, security, production operation and a capstone. Every idea in the course is tried on the same eight notes, so you always know what the right answer is. By the end you have one repository you can show and explain line by line.
The project, its people, its data and its dates are described in 03-the-notes-assistant.md. It is fictional; the real cases that open each lesson are not.
Pictures first
Every lesson is a walk through one example, one picture at a time. A figure shows an idea; a short paragraph says what the figure shows in plain words; a short block of code proves it; a walkthrough explains every line of that code. Then the next figure. A lesson has fifteen to thirty figures and takes thirty to forty-five minutes to read properly.
The same colours mean the same things in every figure:
| Colour | Means |
|---|---|
| Blue | Your system, the normal path: the host, the client, the server |
| Amber | The model, anything uncertain |
| Green | Correct, safe, passed |
| Red | Failure, attack, danger |
| Grey | Optional, background, ignored |
The shape of every lesson
| Part | What happens | Why it is there |
|---|---|---|
| The situation | A problem in Nare's lab, with named people | You learn the idea because you need it |
| A real case, first | Something that really happened, from a published source, cited | So you know the idea matters outside a course |
| The idea | Figures and short paragraphs, one running example throughout | The picture comes before the vocabulary and the specification text |
| Run it | A short piece of code, pasted into Colab, with a code walkthrough | You see it work, and you understand every line |
| Break it | You make it fail on purpose | Real systems fail; see the failure here first |
| In production | What teams do with this at scale | The part most courses leave out |
| Check yourself | Three to five questions, answers hidden until you click | You find out whether it stuck |
| Exercise | One task with a way to check it | You do it, not just read it |
| Key terms and sources | A short glossary and the sources the lesson used | So you can go further |
Three depths of topic
Not every topic deserves the same attention. Each one is marked in its heading:
| Mark | Meaning | What you get |
|---|---|---|
| (Essential) | You cannot do the job without it | Figures, code and a "break it" step |
| (Recommended) | Skip it only if you have a reason | A figure and a short section, often with code |
| (Optional) | Knowing it exists is enough | An "awareness card": what it is, when you would need it |
If you are short of time, do the Essential sections of every module first and come back for the rest.
What every module contains
| File | What it is |
|---|---|
README.md | What the module is for, what you need to know first, the lesson list |
| Numbered lessons | One file per group of topics |
...-module-lab.md | A guided build that adds this module's files to the notes assistant |
...-incident-file.md | A real, published failure, then the same failure replayed in Nare's lab and fixed |
Module 11 is the capstone: one lab that assembles every module into one tested repository, with an acceptance checklist.
Skip what you know
You may already have written an MCP server, or call models with tools every day. Each module README starts with What you need first, so you can check whether it is safe to jump ahead. Some suggested routes are in the course README. Where another course in this series teaches a subject in more depth (agents that act unattended, retrieval, deployment as general engineering), the module points you to it.
How to run the code
All code runs in Google Colab. Open a new notebook, paste each code block into a cell in order, and run it. No installation is needed beyond the install cells the lessons give you.
MCP was designed for programs that run in separate processes, so this course does a few things in a notebook that you would do differently in a terminal: it writes server files with %%writefile, uses await directly in cells instead of asyncio.run(), starts stdio servers as child processes of the notebook, and runs HTTP servers in a background thread on 127.0.0.1. 02-setup-colab-and-llm-providers.md shows each pattern once, with the output it gave.
Every lesson that calls a model starts with the same short setup cell. It lets you choose between three model providers by changing one word. Groq and Gemini work in Colab with a free key. Ollama runs a model on your own computer, so if you choose it you work in a code editor on your machine. Setup for both routes, the one table of model prices, the pinned libraries each module needs, and how to run everything locally: 02-setup-colab-and-llm-providers.md.
Lessons use only the slice of shared data they need, copied from 06-shared-data.md. All of it is simulated, and all of it is written by code: nothing is downloaded.
Some steps cannot run in a notebook: connecting a desktop host such as Claude Desktop, the MCP Inspector's web interface, a real identity provider, containers. Those lessons give exact instructions for your own computer, say plainly that they were not run in the course, and say what was checked against the official documentation instead. The single page for running the course on your own computer is section 7 of 02-setup-colab-and-llm-providers.md; modules do not have their own.
The tools
Everything in the course is open source, apart from the hosted model services, which are shown as options. Servers and clients use the official MCP Python SDK. Where it helps you understand, a lesson first builds the mechanism by hand (a JSON-RPC message typed out, an agent loop in plain Python, a tracer in twenty lines), then shows the SDK's or framework's version, so you know what it is doing for you. The course uses LangChain for calling models and LangGraph for loops and approvals, so the same code works with Groq, Gemini or Ollama.
Every output is real
Every output printed in a lesson came from running that lesson's code, with real provider keys where a model is involved, on the date shown. There are no hand-written "example outputs". Many lessons test plumbing (an approval gate, a pinning check, an attack) with a scripted stand-in, a few lines of Python that pretend to be a model and always make the same choice. The lesson says so, and the stand-in's choices are never presented as what a model did. Numbers in the text come from those runs or from a cited source.
Your answers will not match ours exactly
Language models do not return the same words, or choose the same tools, every time. When a lesson shows a model's output, yours may differ, and an evaluation score may differ by a case or two. That is normal. Module 3 shows how to measure tool choice with a confidence interval, and Module 10 shows how to tell a real regression from that noise.
MCP moves fast
The specification has five published revisions, from 2024-11-05 to 2026-07-28; the Python SDK published six stable 2.x releases between 28 July and 2 October 2026 (checked on PyPI, 13 October 2026); and hosts change what they support month by month. Versions, dates and model names live in one place (course-guide/02), every lesson that names a fast-moving feature says what is likely to change, and Module 1 shows you how to follow the next revision yourself.