Lessons 16 and 17 built MCP servers — a Python server and a TypeScript server, each exposing tools, resources and prompts over stdio. Neither lesson asked what happens on the other end of that connection: an agent that wants to actually use those capabilities in a conversation with the model. That is this lesson's whole subject.
The gap between "a server exists" and "the model can call it" is smaller than it looks, and the size of that gap is the point. An MCP tool is not a new kind of thing the model has to be taught to understand. It is an ordinary tool — same `name`, `description` and `input_schema` shape from lesson 02, same `tool_use`/`tool_result` lifecycle from lesson 04 — that happens to have been discovered through a standard protocol instead of hardcoded by hand. Consuming an MCP server means running the loop from lessons 04 and 05 exactly as written, with one extra step in front of it: converting whatever `list_tools()` returns into that same tool-definition shape.
The rest of this lesson works through that conversion step, the two ways to host it (your own client versus the API connecting to a remote server for you), what happens once more than one server is in play, and the lifecycle obligations a live MCP connection carries that a hardcoded tool never did.
Analogy🏏Cricket
🏏 Think of it like cricket: When BCCI's zonal scouting network flags Mayank Yadav's raw pace during a Ranji Trophy match in Lucknow, the report travels through a standardized pipeline — video footage logged, speed-gun readings recorded, a fitness dossier compiled — so the same format works whether the scout is watching him in Delhi or Bengaluru. That pipeline is the discovery mechanism: it tells the selection committee where to look and how the report arrives, and says nothing about how Mayank actually bowls once picked. When he's finally named in the India squad, he signs the same central contract every other fast bowler signs — the same match-fee slabs, the same squad rules that governed Bumrah's selection and Siraj's before him. The scouting pipeline can change — Ranji footage one year, an IPL trial the next — but the contract he plays under never does. A selector who confused the scouting report's format with the playing contract would be making a category error: one standardizes how talent is found, the other governs how it plays. MCP is the scouting pipeline, a standard way to discover and reach a tool wherever it lives. The Claude API's tool contract — name, description, input_schema — is the central contract, unchanged no matter which server the tool was scouted from.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.