Solutions — Lesson 11

Reference answers for Lesson 11's three homework tasks · ecosystem audit, cold-start measurement, migration trigger list

This is a no-code lesson, so the "solutions" are example findings and worked reasoning rather than runnable code. Your numbers and your trigger list will differ — what matters is that the shape of the answer matches and that you can defend each entry against the self-check criteria from the homework. Read the "common mistake" note after each solution; they capture the failure modes that tripped up reviewers of earlier drafts.

Solution to Task 1 — Ecosystem audit

Example findings table (these are illustrative — the homework expects your own findings from a current GitHub / registry sweep). The important property is the distribution across the three columns, not the specific server names.

| Server                       | Language    | Transport      | Deploy             |
|------------------------------|-------------|----------------|--------------------|
| filesystem-mcp (official)    | TypeScript  | stdio          | npx package        |
| github-mcp (hypothetical)    | TypeScript  | HTTP+SSE       | npx / Docker image |
| local-jupyter-mcp (research) | Python      | stdio          | pip install        |

Reading the row distribution:

2 of 3 are TypeScript — matches the self-check. Resampling 10 servers from the registry would give you roughly the same ratio in 2026.
1 uses HTTP transport — matches the self-check. HTTP+SSE / Streamable HTTP servers are the ones built to be reached over the network; stdio servers are the ones built to be spawned by Claude Desktop on the local machine.
Deploy column tells the same story. npx and Docker appear on the TS rows; pip install appears on the Python row. The Python server lives in a virtualenv on the user's machine; the TS servers ship as artifacts the user (or a runtime) pulls.

Common mistake

Counting Claude-Desktop-bundled servers as "the ecosystem". The bundled set is a curated demo, not a representative sample. Look at third-party servers in the public MCP registry, on GitHub topic mcp-server, and on vendor blogs (Cloudflare, Vercel, Linear, GitHub, Sentry). That is where the real language and transport distribution shows up — and where the 2026 TS dominance becomes obvious.

Solution to Task 2 — Cold-start measurement

The two commands and their expected ranges on a modern laptop (M2 / Ryzen 7000 class, SSD, no power-save throttling):

# Python cold import — loads mcp, Pydantic, anyio, the PKB modules:
$ time python -c "import pkb.server"
real    0m0.742s
user    0m0.621s
sys     0m0.094s

# Node cold import — loads the MCP SDK entry point only:
$ time node -e "import('@modelcontextprotocol/sdk/server/index.js').then(()=>{})"
real    0m0.187s
user    0m0.158s
sys     0m0.041s

Reading these numbers:

Node is ~4x faster cold. The headline ratio you saw in the slides (~150 ms vs ~800 ms) replicates here: 187 ms vs 742 ms is the same shape. The exact numbers depend on disk speed and whether the filesystem cache is warm — the ratio is the durable finding.
Both are well under 2 s. Satisfies the self-check. If your Python number was over 2 s, suspect a slow-importing third-party in your pkb/server.py dependency tree — common culprits are torch, transformers, boto3, and anything that triggers a cryptography backend load.
Re-run each command twice. The first run pulls the bytecode and shared libraries into the filesystem cache; the second run is artificially fast. To measure a real "cold" start, drop caches between runs (sudo purge on macOS; echo 3 | sudo tee /proc/sys/vm/drop_caches on Linux) or just reboot. The numbers above are the warm-cache case — cold-cache adds roughly 200 ms to Python and 50 ms to Node.

Common mistake

Measuring mcp dev startup instead of the bare import. The Inspector spins up a browser-facing WebSocket server and a separate inspector process before your server is reachable — that overhead (several hundred ms on its own) dwarfs the language-level import cost and invalidates the comparison. Use the bare python -c "import ..." / node -e "import(...)" form. If you really want to compare server-ready latency, instrument the entry point itself, not the Inspector tooling around it.

Solution to Task 3 — Migration trigger list

A worked example. Yours should be shorter, more personal, and unambiguously about your server — not a generic "TypeScript good, Python bad" essay. Each bullet should name a concrete event a future you could recognise.

Part A — Triggers toward TypeScript

# When I would port my PKB to TS

1. The first non-self user connects from a different machine.
2. I want zero-config TLS in front of the server (Caddy or Cloudflare).
3. I want sub-200 ms cold-start so I can scale-from-zero on Workers / Fly.
4. I want to deploy to a managed JS runtime (Cloudflare Workers, Vercel
   Functions, Deno Deploy) where Python is a second-class citizen.
5. I want today's transport features (Streamable HTTP, resumable sessions)
   without waiting a quarter for the Python SDK to catch up.

Part B — Triggers back toward Python

# When I would stay (or move back) to Python

1. I add a tool that calls torch / transformers / numpy with custom
   kernels — subprocess overhead per call would kill latency.
2. The server's main consumer is a research notebook on the same machine
   (Jupyter, VS Code, Cursor on localhost). There is no "remote".
3. The team that will maintain it is a data-science team that does not
   write JavaScript and would never pass code review on the TS port.

Reading the lists:

Total: 8 bullets (5 + 3). Inside the 8–11 range the self-check asks for. Five toward TS, three back toward Python is a typical split for a working server that started in Python and might outgrow it.
Every trigger is an event, not an adjective. "Scales well" is not a trigger; "I want to deploy on Cloudflare Workers" is. A trigger you cannot recognise when it happens is not useful — the list exists so future-you can pattern-match a current situation, not so you can win arguments.
The lists do not need to be symmetric. If your use-case is fundamentally local (a notes assistant for one user on one laptop), your "back to Python" side will be longer than your "toward TS" side — and that is the right answer for that use-case. Don't invent triggers to pad the weaker side.

Common mistake

Picking abstract triggers ("scalability!", "performance!", "modern stack!") instead of concrete ones tied to your actual project. Abstract triggers always sound good and never fire, because there's no measurable event behind them. The list is only useful if a future you can re-read it and immediately go "yes, that thing happened" or "no, still not relevant". Tie every bullet to either a specific deployment target, a specific user/team event, or a specific measurable threshold (latency, image size, user count).

What you learned

The 2026 MCP ecosystem is TS-majority on the network. The audit makes that visible in a sample size of three. Python's strongholds are local and scientific — both legitimate, neither network-facing.
Cold start is not a tie. The 4x ratio is durable and matters the moment your server scales-from-zero or runs in a managed edge runtime. It does not matter for long-running personal servers — cold start is paid once, runtime cost dominates thereafter.
A written trigger list beats a vibe. The point of Task 3 is not to commit to TS or to Python today — it is to give future-you a written argument with concrete events to look for, so the migration decision (in either direction) becomes pattern-matching instead of re-derivation.

Lesson 12 starts where this lesson ends — you will replace the thrown Error in src/server.ts with a real echo tool wired through the TS SDK's Server and setRequestHandler API, with a Zod schema and a pino child logger. Same tool shape you built in Python; new wire format and new build pipeline around it.