The map, and what you now carry

This will move again

The version you learned is 2026-07-28, and the fact that it is a date rather than a number is the protocol telling you something. There will be another one. Sampling and roots were removed in this one; something in this course will be superseded in the next.

So the most durable thing to leave with is not a fact but a map: where ground truth lives, per question.

• "What does the protocol require?" — the specification at modelcontextprotocol.io/specification, at the dated version you are targeting. This is the authority, and it is the place to check when an SDK and your expectations disagree.
• "How do I do this in Python?" — the Python SDK documentation. It tracks the spec but has its own version and its own opinions, and the migration guide is the fastest way to translate old material.
• "Why is my server not working?" — the Inspector first, always. It removes your code and your host from the question in one command.
• "What is my client doing?" — that client's own documentation. The four config dialects in Lesson 10 are maintained by four different teams.
• "Is this safe?" — the specification's security guidance. Lesson 32's four attacks are drawn from it, and it is updated as new ones are found.
• "Has somebody already built this?" — the registry, before you write anything.

How you will know it moved

Three signals, in the order you will notice them.

An import fails. The clearest and least ambiguous. Check the SDK's migration guide, which is where renames are listed.

A client reports a version error. -32022 carries the versions the other side supports in its data field, which makes it self-diagnosing.

Something is marked deprecated. This is the useful one, because it comes with warning. Deprecation in MCP has meant "still works, will not always" — sampling and roots ran for a full cycle before removal. When you see it, note what replaced it and plan; you have time, and you will not get more warning than this.

What you now carry

You started with a floor, three rooms and a sentence a machine could not answer.

You know what MCP is — a specification, not a library — and why it exists: the integration bill was a product and is now a sum. You can tell tools from resources from prompts by asking who decides. You can read the wire, because it is JSON-RPC in an envelope you have now seen unpacked.

You can connect servers other people wrote, in four clients, and judge one in five minutes before installing it. You know that a connection is a supply-chain decision and that tool results are untrusted text.

You can build a server: type hints into schemas, return annotations into output schemas, honest annotations, the split between a domain failure the model can work around and a protocol error it cannot. You can share a database connection with lifespan, reach the world with Context, and test the whole thing in-process without a subprocess or a port.

You can handle the cases that make a server real rather than a demo. Ambiguity, through a resolver that asks only when it must. Credentials, through the one mode that keeps them out of the model's context. Work that takes eight minutes, through a durable handle instead of a held connection. An answer that is a grid rather than a sentence.

And you can ship it: over HTTP, mounted in an application you already have, with the host validation that stops a web page reaching it, tokens validated for the right audience, and the four attacks drawn well enough to spot in review.

Test what you carry

Reading a course and being able to use it are different things, and the gap is invisible from the inside. Two Hack modules exist for exactly this, and they are worth taking in order.

Model Context Protocol — Core → covers the ground this course walks in its first two sections: the primitives and who controls each, the architecture, the wire, and the two transports. Take it first as a warm-up — it will tell you quickly whether the conceptual half landed.

Model Context Protocol — Advanced → is this course's exit exam, and passing it is what earns the course certificate. It goes where this course goes: elicitation's re-entrancy and the three outcomes, task lifecycles and cooperative cancellation, audience validation and the token-passthrough ban, the four attacks from Lesson 32, and the design judgment in Lesson 34. If you have worked through Atrium end to end, it should feel like a description of what you already built.

If a question catches you out, the lesson it came from is the one to reread. That is more useful than a score.

If one thing sticks

Make it this.

MCP's whole value is that a system describes itself well enough for something else to act on the description. Not the transport, not the JSON-RPC, not the decorators — those are mechanism, and mechanism changes. The value is in the description: the tool name a model picks correctly from a list of forty, the parameter description that stops it guessing a date format, the annotation that tells a host whether to interrupt the user, the resolver that asks one question instead of assuming.

Every one of those is a sentence you write, and none of them are checked by anything. The protocol will happily carry a bad description to every client in the world.

So when a tool goes unused, or gets called with the wrong arguments, or does something the user did not want — before you look at your code, read what you told it. That is almost always where the bug is, and it is the part that stays true whatever the next version deletes.