Part 1 of 6 · 2 min read
Overview
In this module you will
- Draw the host, client and server roles of the Model Context Protocol (MCP) and say what each is responsible for.
- Explain the three things a server offers, tools, resources and prompts, and who decides when each is used.
- Read an MCP message: the JSON-RPC envelope, a tool call, and the difference between a protocol error and a tool error.
- Describe the two eras of the protocol (a handshake session, and the newer stateless form), and what a client must do to talk to either.
- Answer how MCP differs from plain function calling, and when you should not use MCP at all.
- Say what the host must do that the protocol does not do for it: prefix names, ask consent, distrust claims, keep the conversation to itself.
Level 5 gave your agent tools that you wrote. Real agents need tools that other people wrote: a calendar, a code host, a database, a company wiki. Without a standard, every pair of agent and system needs its own adapter, and every adapter needs its own security review. MCP is the attempt to make that connection one shape: a system implements a server once, and any application that speaks the protocol can use it.
That is useful, and it is also a larger attack surface: every server you connect is code you did not write, handing text to a model that follows instructions. So this module teaches two things at once: how the pieces fit, and where the host must stay in charge.
About the examples, and about the protocol version
The example code is a teaching imitation of the message shapes in two revisions of the specification: 2025-11-25 (a connection opens with a handshake) and 2026-07-28 (no handshake; every request carries its own metadata). I read the specification pages for both on 24 October 2026 and built the imitation from them. It is not an SDK: it has no real transport (module 3), no subscriptions, no sampling or elicitation (module 4), no authorisation (module 5), no tasks, and where the specification text I read gave no code, I chose one and said so in the code. The "servers" are three small in-process objects and the "attacker" in the last experiment is a script. The byte counts depend on this toy's JSON, so use them as direction only.
Check the current specification before you rely on any detail here.