Container/runner/MCP lab polish (#41,#42,#45,#46) (#65)

Co-authored-by: claude <claude@jpaul.io>
Co-committed-by: claude <claude@jpaul.io>

modules/20-mcp-servers-giving-the-ai-hands/README.md

@@ -35,7 +35,8 @@ By the end of this module you can:
 1. Explain the MCP client/server model — what a server exposes (tools, resources, prompts), what the
    client (your agentic tool) does, and why "it's a protocol, not a vendor feature" is the whole
    point.
-2. Connect an existing MCP server to your agentic tool and confirm the AI can call its tools.
+2. Connect an MCP server to your agentic tool and confirm the AI can call its tools — an existing
+   reference server (the optional Part A warm-up) or the one you build in Part B/C.
 3. Build a tiny MCP server in Python that exposes one real capability over the `tasks-app`, and wire
    it into your tool.
 4. Watch the AI *use* that server — read and change real state through a tool call — and verify the
@@ -243,6 +244,9 @@ is the one that lands the concept.
   **Python packages and which `python`** note just below *before* you run `pip`.
 - The starter files in this module's `lab/` folder: `tasks_mcp_server.py` and
   `mcp-config-example.json`.
+- **Only for the optional Part A warm-up:** the reference server your tool points you at typically
+  runs via `npx` (needs Node) or `uvx` (needs uv) — install whichever its documented `command`
+  needs. Part B/C, the load-bearing path, need only the Python SDK above, so you can skip this.
 
 > **Python packages and which `python`.** This lab's one dependency is the MCP SDK, and *how* you
 > install it decides whether the server ever connects. Two things bite people:
@@ -273,15 +277,22 @@ is the one that lands the concept.
 > ~/workflow-course/tasks-app/.venv/bin/python -c "import mcp; print('mcp ok')"
 > ```
 
-### Part A — Connect an existing server (warm-up, ~10 min)
+### Part A — Connect an existing server (optional warm-up, ~10 min)
 
-Before building anything, prove the plumbing works by connecting a server someone else already
-wrote. The MCP ecosystem ships a set of **reference servers** (filesystem, fetch, git, and more) —
-pick a simple, read-only one your tool's docs point you at (a "filesystem" or "fetch" server is a
-good first choice).
+This part is **optional**: it proves the plumbing works by connecting a server someone else already
+wrote, but it's a warm-up, not the load-bearing concept — Part B/C land that on the Python SDK you
+already installed. The catch is the runtime: most **reference servers** (filesystem, fetch, git, and
+more) are distributed for `npx` (Node) or `uvx` (uv), *not* Python, so this warm-up needs whichever
+runtime its documented command uses. If you don't already have Node or uv and don't want to install
+one for a 10-minute warm-up, **skip straight to Part B** — you lose nothing the rest of the lab needs.
+
+To do it: pick a simple, read-only reference server your tool's docs point you at (a "filesystem" or
+"fetch" server is a good first choice), and install the runtime its command needs (Node for `npx`, uv
+for `uvx`).
 
 1. Add the server to your tool's MCP config, following the tool's docs. Most reference servers are
-   launched the same stdio way as the JSON shape shown in *Key concepts* — a `command` and `args`.
+   launched the same stdio way as the JSON shape shown in *Key concepts* — a `command` (e.g. `npx` or
+   `uvx`) and `args`.
 2. Restart or reload your agentic tool so it picks up the config. Confirm it reports the server as
    **connected** and lists its tools.
 3. Ask the AI to do something only that server enables — e.g. with a fetch server, *"fetch
@@ -429,8 +440,9 @@ The honest caveats — and one of them is large enough that it gets its own modu
 
 **You're done when:**
 
-- You connected an **existing** MCP server to your agentic tool and watched the AI call one of its
-  tools (Part A).
+- (Optional, Part A) If you ran the warm-up, you connected an **existing** reference MCP server to
+  your agentic tool and watched the AI call one of its tools. Skipping it costs nothing — Part C
+  connects the server you build and shows the same tool call.
 - You built `tasks_mcp_server.py`, wired it into your tool, and saw the `tasks` server report as
   connected with `list_tasks` and `add_task` available.
 - You asked the AI a question and it answered by **calling a tool** against the live system, and you
@@ -461,8 +473,9 @@ MCP is moving fast; re-check these at build/publish time rather than trusting th
 - [ ] **The `mcpServers` config shape.** Confirm it's still the widely-shared convention for stdio
       servers, and that the `command`/`args` fields are current. Keep the lesson tool-agnostic about
       *where* the config file lives.
-- [ ] **Reference servers (Part A).** Verify which first-party reference servers exist and how
-      they're launched today; the catalogue and launch commands change. Don't name a specific server
-      that may have moved or been retired without checking.
+- [ ] **Reference servers (optional Part A).** Verify which first-party reference servers exist and
+      how they're launched today; the catalogue and launch commands change. Don't name a specific
+      server that may have moved or been retired without checking. Confirm the named runtimes (`npx`
+      via Node, `uvx` via uv) are still how the common reference servers are distributed.
 - [ ] **Adoption framing.** Re-confirm the "open standard, adopted across vendors regardless of
       model" claim is still accurate and still vendor-neutral; update if the ecosystem has shifted.