Capstone — Evaluation rubric
Curso MCP Engineering · M5
This is the printable rubric to self-assess your final project before submitting it. Each row is a criterion; read the three levels and honestly place where you are. Aim for excellent in everything you can — the rubric tells you exactly what to look at. It's the same filter your capstone is evaluated with, so use it as a final checklist.
How to read it
It's six criteria × three levels. Good is already a passing project; excellent is the one you can show off with pride. If any criterion lands on insufficient, go back to the brief and close it before submitting. You don't need "excellent" in everything to have a great project — but no criterion should land on insufficient.
Criterion 1 — The server works
| Insufficient | Good | Excellent |
|---|---|---|
| Doesn't start, throws errors on startup, or exposes no tools. | Starts without errors and exposes 2–3 tools that respond to normal inputs. | Starts clean, 2–3 solid tools, and handles odd or invalid inputs without breaking (clear errors, not a crash). |
Criterion 2 — Tool design
| Insufficient | Good | Excellent |
|---|---|---|
| Confusing names, no description or no types; or the data is made up. | Clear names, description/docstring and typed arguments; they wrap real data (API or local). | Descriptions so clear that the model picks the tool without hesitation, precise types, and errors returned in a way that's useful for the agent to recover. |
Criterion 3 — Right transport
| Insufficient | Good | Excellent |
|---|---|---|
| Wrong or misconfigured transport for the case (e.g. HTTP for something purely local). | stdio for local or Streamable HTTP for remote, correctly chosen for the case. | Justified choice; local doesn't pollute stdout (logs don't break the protocol) and remote validates the Origin header. |
Criterion 4 — Auth and security
| Insufficient | Good | Excellent |
|---|---|---|
| Remote server without auth, or tools with broad permissions "just in case." | Local secure by design; if remote, OAuth 2.1 validating the token. | OAuth 2.1 validates issuer, audience and scope (all three); least privilege on each tool and output treated as untrusted content. |
Criterion 5 — Testing with the Inspector
| Insufficient | Good | Excellent |
|---|---|---|
| Not tested, or only checked that "it started and that's it." | Each tool listed and run in the MCP Inspector with test inputs. | Change → relaunch → verify cycle documented, and edge cases tested (empty, invalid, extreme inputs). |
Criterion 6 — Documentation
| Insufficient | Good | Excellent |
|---|---|---|
| No README, or no explanation of how to run it. | README with what it does, how to run it and how to connect it to a client. | Clear and reproducible README (someone else runs it without help) + evidence of testing (Inspector) and of connection to a real client. |
Summary table (everything in one view)
| Criterion | Insufficient | Good | Excellent |
|---|---|---|---|
| The server works | Doesn't start or exposes no tools. | Starts and exposes 2–3 tools that respond. | Starts clean and handles odd inputs without breaking. |
| Tool design | Confusing names, no types, made-up data. | Clear names, description and types; real data. | The model picks without hesitation; precise types; useful errors. |
| Right transport | Wrong or misconfigured transport. | stdio local or Streamable HTTP remote, well chosen. | Justified; doesn't pollute stdout; validates Origin. |
| Auth and security | Remote without auth, or broad permissions. | Local secure; remote with OAuth 2.1. | Validates issuer, audience and scope; least privilege; untrusted output. |
| Testing with the Inspector | Not tested, or "it started and that's it." | Each tool listed and run with tests. | Cycle documented; edge cases tested. |
| Documentation | No README or no how-to-run. | README with what it does, how to run and connect. | Reproducible README + evidence of testing and connection. |
To remember
- Good = passing. You don't need "excellent" in everything to have a great project; just avoid any insufficient.
- The most neglected criterion is auth and security: if your server is remote, validating issuer, audience and scope is not optional.
- The course's mother rule is also evaluated: every server output is data to display, never a command to obey.
- Before submitting, go through this rubric row by row. It's the same filter it's evaluated with.
Turning Point Academy · MCP Engineering Course · Module 5 · Final project (capstone)