How We Built (and Battle-Tested) the MCP Servers Course

Track 11 — Build MCP Servers: Extend Claude with Custom Tools — is now fully written and ready to publish. It is a 15-lesson, ~5.5-hour developer course covering everything from what MCP is to publishing your own server on npm and PyPI. But the story of how it got made is worth sharing, because it did not go entirely smoothly — and that is exactly the point.

What the Course Covers

The Model Context Protocol (MCP) is the open standard that lets you extend Claude with custom tools, resources, and prompts. Instead of being limited to what Claude knows out of the box, you can give it the ability to query your database, call your internal APIs, read files from your filesystem, or do anything else you can write code for.

The course takes you from zero to a published, production-ready MCP server in both TypeScript and Python. Here is what the 15 lessons cover:

• Lessons 1–4: How MCP works — the architecture, the three primitives (tools, resources, prompts), and the transport layer (stdio vs Streamable HTTP)
• Lesson 5: Setting up your development environment with Node.js/uv
• Lessons 6–7: Building your first working MCP server in TypeScript, then in Python using FastMCP
• Lesson 8: Connecting your server to Claude Desktop, Cursor, VS Code, and Claude.ai
• Lessons 9–11: Going deeper — tool schemas and validation, exposing resources with URI templates, building reusable prompt templates
• Lesson 12: Testing and debugging with MCP Inspector
• Lessons 13–14: Building remote HTTP servers with Streamable HTTP transport and securing them with OAuth 2.1
• Lesson 15: Publishing to npm, PyPI, and the official MCP Registry

Every lesson was researched against current sources — the official MCP specification, the TypeScript and Python SDK repositories, and 2026 deployment guides — before a single word was written.

The Verification Challenge

After all 15 lessons were written, a reasonable question came up: would a student actually be able to follow these instructions and end up with a working server?

There is a difference between content that is technically accurate and content that works when you follow it step by step. API names can be right. Code examples can be correct in isolation. And the whole thing can still fail on step three because a dependency was not mentioned.

So we ran the test. We followed the instructions exactly, from scratch, on a real machine.

TypeScript Path: Almost Perfect

The TypeScript weather server from Lesson 6 was set up from scratch:

1. Created a new directory, ran npm init -y
2. Installed @modelcontextprotocol/sdk and zod
3. Created tsconfig.json with the exact settings from the lesson
4. Wrote src/index.ts with the full weather server code
5. Ran npm run build

Step 5 failed.

error TS2591: Cannot find name 'process'. Do you need to install type definitions for node?

The lesson code uses process.exit(1) — standard Node.js — but the install instructions did not include @types/node, and the tsconfig.json was missing "types": ["node"]. Without those, TypeScript does not know that process exists.

The fix was two lines:

• Add npm install --save-dev typescript @types/node to the install step
• Add "types": ["node"] to tsconfig.json

Both Lesson 5 and Lesson 6 were updated immediately. After the fix, npm run build compiled cleanly.

Testing the Tools for Real

Once the server built, it was tested by sending raw JSON-RPC messages over stdin — exactly what Claude Desktop does when it connects to an MCP server. Both tools were called with live data from the US National Weather Service API.

get_alerts (California) returned a real Frost Advisory for Siskiyou County and an Air Quality Alert for the Imperial Valley, correctly formatted with event name, area, severity, and headline.

get_forecast (New York City) returned five forecast periods — 76°F and sunny that afternoon, 63°F overnight — confirming the two-step NWS API lookup (points endpoint → forecast URL → periods) worked end to end.

The JSON-RPC handshake, tool discovery, and tool responses all matched the MCP specification exactly.

Python Path: One Missing Line

The Python path required installing uv first — it was not present on the test machine. One command via Homebrew sorted that out, which is exactly what Lesson 5 documents.

After that: uv init, uv venv, uv add "mcp[cli]" httpx, write the server, run it. The FastMCP @mcp.tool() decorator pattern worked exactly as the lesson describes.

There was one subtlety worth noting: the server needs if __name__ == "__main__": mcp.run() at the bottom of the file. The lesson documents this correctly. Without it, uv run weather.py starts the script but the MCP server never actually launches — the process exits silently. It is an easy thing to miss, and Lesson 7 makes it explicit.

get_alerts (Texas) returned five live alerts: Flood Warnings, Flood Advisories, and a Flood Watch across west Texas — all from separate NWS forecast offices, confirming the Python implementation handles real-world API responses correctly.

What Was Added to the Lessons

Both Lesson 6 (TypeScript) and Lesson 7 (Python) now end with a Verified: This Code Works section that documents exactly what was tested, what environment it ran on, and what live data came back. The @types/node fix is already baked into the install instructions.

The goal was not just to say "this works." It was to show the specific output a student should expect to see, so they have a reference point when something does not match.

When the Course Publishes

Track 11 publishes after Track 10 (AI Safety, Ethics & Society) completes — currently scheduled for late June/July 2026, two lessons per week. All 15 lessons are written, tested, and ready to go.

If you are a developer who wants to extend Claude with your own tools, this is the course for it. No prior MCP experience required — just familiarity with TypeScript or Python.