Homework — Lesson 11

Three tasks · ecosystem audit, cold-start measurement, migration triggers · ~60–90 min

Lesson 11 made the case for TypeScript as the default substrate for remote, internet-facing MCP servers and gave you permission to stay in Python for personal, scientific, or throwaway servers. These three homework tasks turn that argument into evidence for your own project: (1) survey three real public MCP servers and record the language/transport/deploy distribution you actually find; (2) measure the cold-start gap on your own laptop instead of trusting the back-of-envelope numbers in the slides; (3) write down the concrete triggers that would push your codebase one way or the other, so future-you can pattern-match against a real situation.

Before you start

Lesson 11's lab must be done: Node 20+ and Docker installed, the TypeScript skeleton at mcp-servers/sample-server/typescript/ in place with npm install already run, and your Python PKB server from Module 4 still runnable for the cold-start comparison in Task 2. No code change is required by this homework — the output is three short artifacts (a table, two numbers, two lists) that live in your own notes.

Task 1 — Ecosystem audit

Find three real, public MCP servers and record three facts about each. Sources worth searching: the modelcontextprotocol GitHub organisation, the MCP registry / awesome-list references in the SDK READMEs, vendor blogs (Anthropic, Cloudflare, Vercel, Fly.io), and the third-party "MCP server for X" packages on npm and PyPI. Do not count Claude-Desktop-bundled servers — those are official examples, not the ecosystem.

For each server record:

Language — TypeScript, Python, Go, Rust, etc.
Transport — stdio, HTTP+SSE, or Streamable HTTP. The README or src/server.* entry-point will say which transport class is imported.
Deploy model — npx/npm package, pip install, Docker image, managed (Workers / Vercel / Deno Deploy), or self-hosted binary.

Format the findings as a 9-line table (header + 3 rows + separators is fine):

| Server | Language | Transport | Deploy |
|--------|----------|-----------|--------|
| ...    | ...      | ...       | ...    |
| ...    | ...      | ...       | ...    |
| ...    | ...      | ...       | ...    |

✓ Self-check: at least 2 of the 3 servers in your table are TypeScript or Node-based; at least 1 uses an HTTP transport (HTTP+SSE or Streamable HTTP). If your sample is all Python or all stdio, broaden the search — the 2026 ecosystem skews TS/HTTP and your sample should reflect that within three picks.

Task 2 — Cold-start measurement

Time the cold start of your Python PKB server and the empty TypeScript skeleton on your actual laptop. The back-of-envelope numbers in the slides (~800 ms Python vs. ~150 ms Node) are population averages; your hardware, OS, and disk speed will move both numbers. Recording your own gives you a sense of how large the gap is for the substrate you would actually deploy on.

Run both, preferably twice (the second run hits filesystem cache and is cheating — record only the first):

time python -c "import pkb.server"
time node -e "import('@modelcontextprotocol/sdk/server/index.js').then(()=>{})"

The Python command assumes you are in mcp-servers/sample-server/python/ with the venv activated; the Node command assumes you are in mcp-servers/sample-server/typescript/ after npm install. Record both real times in your notes.

✓ Self-check: the Node number is smaller than the Python number. Both are under 2 seconds on a modern laptop — if either exceeds 2 s, either your machine is cold from boot, your venv/node_modules is on a slow disk, or something is misconfigured. Note the ratio, not just the absolute numbers: a 2–5x ratio is the typical signal that informs the "edge HTTP → TS" rule from the theory page.

Task 3 — Migration trigger list

Write down the concrete triggers that would push your project from Python-MCP to TypeScript-MCP, and a counter-list of triggers that would push back. "Concrete" means a future-you reading the list can pattern-match it to a real situation — not abstract phrases like "scalability" or "performance". Tie each trigger to a thing that would change in your project, your users, or your deployment.

Part A — Toward TypeScript (5–8 bullets). Examples to draw from (replace with your own):

First non-self user connects from a different machine.
I want to deploy on Cloudflare Workers, Vercel, or Deno Deploy.
The audit team mandates automatic TLS termination by a reverse proxy.
I need sub-200 ms cold-start because the platform scales pods from zero.
I want a transport feature (Streamable HTTP, resumable sessions) that ships in the TS SDK first.

Part B — Back toward Python (3 bullets). Examples:

I add a tool that calls torch, transformers, or a NumPy kernel I don't want to re-implement.
The server's primary consumer becomes a Jupyter notebook on the same machine.
The team that will maintain the server is a data-science team that does not write JavaScript.

Treat the bullets above as a starter set. The exercise has value only if you replace at least half of them with triggers that are specific to your project.

✓ Self-check: both lists exist; the total length is between 8 and 11 bullets (5–8 toward TS + 3 back to Python). Every bullet names a concrete event, dependency, user, or deployment property — not an adjective. Save the memo somewhere you will re-read in six months; that is the only audience that matters.

View solutions →