How to Build an MCP Server (Part 3): Test, Document, and Ship on Demo Day

This is Part 3 of the NextFlows Academy MCP server course — the finish line. You should already have real data on P0 tools and a hardened server from Part 2 (Weeks 3–4), built on the setup in Part 1 (Weeks 1–2).

Part 3 covers Weeks 5–6: a manual test plan with evidence, a README a stranger can follow in about 15 minutes, example conversations, connecting to Claude Desktop or Cursor, tagging a public `v1.0.0`, rehearsing a 3–5 minute demo, Demo Day, and a resume-ready reflection.

This path matches the free Building an MCP for an AI Engine cohort outcome: a working MCP server on GitHub you can show in interviews.

Week 5 freezes features. You write and execute a test plan, fix only what fails, rewrite the README for cold installs, collect peer sign-off, and document three example conversations. Optional: a few unit tests on pure helpers — never on the stdio transport itself.

Host setup docs: Claude Desktop MCP and Cursor MCP. Inspector remains a valid Demo Day backup if host config fails on your machine — tell your mentor early.

Step 1 — Branch: `git checkout -b week-5-docs`.

Step 2 — Create `docs/test-plan.md` with columns: id, tool, setup, input, expected, result, evidence. Include at least eight cases across P0 tools: happy paths, invalid args, empty data, and offline/API-down (or simulated).

Step 3 — Execute and capture evidence (mandatory). Run every case in Inspector. On FAIL, fix, re-run, mark PASS with the fixing commit. Save screenshots for one happy path, one validation reject, and one empty/error path under `docs/evidence/` if helpful.

Step 4 — Optional smoke tests. Unit-test pure functions (CSV parse, URL builder) with Node’s test runner. Keep MCP transport out of unit tests. Skip if time is short — the manual plan is enough to pass.

Step 5 — Rewrite README (mandatory). Sections: what it does, prerequisites (Node version), install, run, Inspector one-liner, tool table, example prompts, troubleshooting (three common errors), license. Delete outdated Week 1 hello-world fluff.

Step 6 — Peer sign-off. A peer clones into a temp folder and follows README only. You may fix the README, not whisper tips. They comment on your Week 5 Issue with approximate time to first successful tool call.

Step 7 — Example conversations (mandatory). Write `examples/conversations.md` with three user prompts, expected tool sequences, and what a good final answer looks like. Link it from the README.

Step 8 — Host preview. Add Claude Desktop or Cursor config JSON with an absolute path to your server command. Run Conversation A live. If blocked, document the issue and keep Inspector as backup.

Week 6 is release engineering plus storytelling. Mentors must clone your public repo at tag `v1.0.0` and run it without private notes. You present live in 3–5 minutes: problem, one architecture slide, live tools, next steps.

Use Choose a License (MIT is fine unless told otherwise) and Semantic Versioning for the `v1.0.0` tag.

Step 1 — Repo polish. Add LICENSE, confirm `.gitignore`, set GitHub topics (`mcp`, `typescript`, `model-context-protocol`), write a one-line repo description, delete dead files you will not demo.

Step 2 — Public ship (mandatory). Set visibility to Public. From a temp directory: clone, `npm install`, start the server, call one tool. Create an annotated tag: `git tag -a v1.0.0 -m "Demo Day ship"` and push it. Submit URL + tag.

Step 3 — Demo script (mandatory). Write `docs/demo-script.md` with timed beats totaling ≤5 minutes. Prepare two always-working live prompts from your conversations file, plus a third backup. Build ≤5 slides. Rehearse twice with a timer. Plan the Wi‑Fi-down path (fixtures only).

Step 4 — Demo Day on-site. Arrive with `v1.0.0` checked out, server tested that morning, Prompt A on the clipboard. Present to time. Mention one security hardening if asked. Capture feedback bullets immediately after.

Step 5 — Reflection (mandatory). Commit `docs/reflection.md`: wins, blockers, a 3–4 sentence resume blurb naming MCP + TypeScript + Zod + public repo, optional LinkedIn draft, and one post-cohort improvement.

Step 6 — What’s next (optional). Skim HTTP transport in the TS SDK Server Guide. File one enhancement Issue on your repo. Add the repo to your CV or GitHub profile README.

Clarity: can a peer explain your problem in one sentence after your intro? Working demo: do live tool calls succeed without editing code on stage? Safety awareness: can you name one hardening (allowlist, timeout, schema)? Docs quality: does README match what you just ran?

Time discipline matters. Cutting slides to protect the live demo is the right trade. Overtime without a working call is a weaker outcome than a shorter, solid demo.

Use this pattern and fill in your details: “Built and published a TypeScript Model Context Protocol (MCP) server with Zod-validated tools for [problem domain], including local fixtures, input allowlisting, and a README that peers could run cold; shipped publicly on GitHub (`v1.0.0`) and demonstrated live to mentors.”

Keep it truthful. Only claim connectors (Claude Desktop / Cursor) you actually configured. Link the public repo on your CV.

Part 1: repo, first tool, Inspector, design doc, Zod schemas, multi-tool skeleton. Part 2: data plan, ≥3 real-data tools, threat model, harden PR, on-site review. Part 3: test plan evidence, README peer sign-off, conversations, public `v1.0.0`, demo script, reflection.

If you get stuck, jump back to the matching part: setup and tool design · data and security · this page for ship and Demo Day.

Follow this series self-paced, or apply to the free live cohort for mentor reviews and Demo Day structure: Building an MCP for an AI Engine — apply.

After you ship an MCP, explore everyday AI workflows without code in the NextFlows recipe library — useful when you want to show non-developers what AI tools can do alongside your server work.