Turning Point Academy · MCP Engineering

Capstone — Brief

Curso MCP Engineering · M5

This is the printable brief for the final project of MCP Engineering. It's your roadmap: read it in full before starting, pick an idea, and use the checklists to know exactly when you're done. You got this far knowing what MCP is, how the primitives work, how to go from an API to tools, how to choose the transport, how to protect a remote server with OAuth 2.1, and how to apply the security checklist. The capstone brings all of that together in a single project of your own. The evaluation is handled separately, in the Capstone rubric — read it too before starting.

Objective

Build, test, and connect a real MCP server —made by you— that integrates everything from the course: a server that starts, exposes useful tools over real data, runs on the right transport, protects itself if it's remote, applies security, and connects to a real client.

We're not looking for a big project. We're looking for one that works end to end, is well thought out, and is secure. If you pull that off, you already know how to build MCP servers — full stop.

Requirements (detailed checklist)

Check each box only when it's truly done and tested:

[ ] Chosen stack: Python (FastMCP) or TypeScript (official SDK). Just one, whichever you're comfortable with.
[ ] The server starts without errors from a clean terminal.
[ ] It exposes 2 or 3 tools (ideally 3), each with a clear name, a description/docstring that explains what it does, and typed arguments. Remember: the model picks the tool by reading its description.
[ ] The tools wrap a real free API or local data (a CSV, a folder of notes) — nothing made up.
[ ] You use the right transport: stdio if it's local, Streamable HTTP if it's remote.
[ ] If remote: OAuth 2.1, validating the token's issuer, audience, and scope — all three.
[ ] You apply least privilege on each tool (only the permissions it needs, nothing more).
[ ] You treat every server output as untrusted content (data to display, never a command to obey).
[ ] You tested it with the MCP Inspector: you listed and ran each tool with test inputs.
[ ] You connected it to a real client (Claude Code or Claude Desktop) and saw it respond for real.
[ ] You include a short README: what it does, how to run it, and how to connect it.

Project ideas

Pick one of these four (or invent your own, keeping 2–3 tools, real data, and a small scope):

Idea	Suggested tools	Data / API	Transport	Difficulty
Weather assistant	`current_weather(city)`, `forecast(city, days)`	Free public weather API	`stdio` local	Low — ideal for the first project
Quotes dashboard	`price(asset)`, `convert(amount, from, to)`	Keyless API (crypto / stocks / currencies)	`stdio` local	Medium — good effort/impact balance
Notes searcher	`search(text)`, `read(file)`	Local `.md` folder or CSV	`stdio` local	Medium — perfect for practicing least privilege (read-only, never leaving the folder)
Remote server with auth	any of the above	API or local data	Streamable HTTP + OAuth 2.1	High — the most complete and the most impressive

Deliverables

Server code (server.py or index.ts) that starts and exposes the tools.
A short README: description, how to install/run, and how to connect it to a client.
Test evidence: a screenshot or description of the tools working in the Inspector.
Connection evidence: the server responding from Claude Code / Claude Desktop.
If remote — auth note: how the token is obtained and what the server validates (issuer, audience, scope).

Suggested step-by-step plan

Pick an idea and a stack. Start from the mcp-server-starter skill pack (or from mcp-python-starter / mcp-ts-starter) to have the skeleton ready.
Write a single tool that wraps your API or your data, with a clear description and types. Don't start with all three at once.
Test it in the Inspector: npx @modelcontextprotocol/inspector <startup-command>. List it, run it with test inputs, confirm the result.
Add the 2nd (and 3rd) tool by repeating the change → relaunch → verify cycle.
Choose the transport. Local: keep stdio. Remote: move to Streamable HTTP and add OAuth 2.1 (validate issuer, audience, and scope).
Go through the security checklist: least privilege on each tool and output treated as untrusted.
Connect it to a real client (claude mcp add ...) and ask the agent to use a tool.
Write the README and self-assess with the Rubric before submitting.

Tips

Don't chase the perfect project. Pick one from the list, make it work end to end, and only then polish it.
The order that never fails: a tool that works → test it in the Inspector → connect it to a client → add the next one.
Write the descriptions for the model, not for yourself: they are what the model reads to decide which tool to use.
Start local (stdio). The jump to remote + OAuth is the heaviest part; leave it for when the local part already works.
Read the Rubric before starting, not at the end: it tells you exactly what each criterion looks at, so you aim for "excellent" from day one.

When you see it respond from Claude, you'll understand why you did this whole course. Now, for real: build it.

Turning Point Academy · MCP Engineering Course · Module 5 · Final project (capstone)