Capstone: Ship a Production MCP Server — Tool Use, Function Calling & MCP

This lesson has one deliverable: a working MCP server, not a description of one. The brief is a document-library MCP server -- server name document-library-mcp-server, kebab-case, per the naming convention this course has used since lesson 13 -- exposing exactly three tools (search_documents, read_document, record_review_note), one resource, and one prompt. Everything from lesson 0's case for tools at all through lesson 33's catalogue of anti-patterns to avoid converges here into one artifact you actually ship, end to end: design the tool boundaries, implement the server, harden it against the inputs a real caller will eventually send, test it without a model, run a small selection eval, instrument it, and write the versioning and go-live discipline that keeps it alive after day one.

Acceptance criteria, stated upfront and concretely, the way a real spec should be written rather than discovered after the fact. First, search_documents takes a natural-language query and an optional tag, and returns at most 20 ranked matches -- id, title, snippet -- never the full corpus, regardless of how broad the query is. Second, read_document accepts only a document id previously returned by search, and rejects anything shaped like a path, an absolute path, or a traversal attempt with a structured error, not a stack trace or a leaked file. Third, record_review_note accepts a doc_id, a note, a rating, and a caller-supplied idempotency key, and calling it twice with the same key produces exactly one stored note, not two. Fourth, a resource exposes the library's catalogue for the host to read directly, with no tool call and no model turn spent on it. Fifth, a prompt template is offered for drafting a review. Sixth, a 14-prompt tool-selection eval scores at or above 90% before the catalogue ships. None of these is aspirational -- each one is checked by a test or a script later in this lesson.

The build runs in the order production tool catalogues actually get built in, not the order a tutorial would prefer: design the boundaries first, because a schema and a description are far cheaper to change before code depends on them than after; implement against that design; harden the implementation against the inputs an honest caller sends by accident and the inputs a dishonest one sends on purpose; prove both halves work without ever spending a model call on the proof; then, and only then, wire up observability and a shipping discipline for a catalogue that will keep changing after today.

Analogy🏏Cricket

🏏 Think of it like cricket: before a franchise's death-overs specialist walks in for the twentieth over, the captain doesn't hand over a vague "go get some wickets" -- MS Dhoni, famous for exactly this kind of specificity behind the stumps, would set a concrete brief before a ball is bowled: yorker-length at leg stump to the left-hander, two fielders back on the square boundaries, one man protecting long-on, bowl to this precise plan and we win from here. That brief is checkable the moment the over ends -- either the ball landed where it was supposed to and the field held the shape it was meant to hold, or it didn't, and everyone watching, not just the captain, can tell which happened without needing to ask. A vague brief -- "bowl well" -- can never be checked this way, because nothing about it says in advance what "well" was supposed to look like. This capstone is written as Dhoni's brief, not the vague one: search returns at most twenty ranked results, read rejects a bad id with a named error instead of a crash, a repeated write produces exactly one note, and a fourteen-prompt eval clears ninety percent -- criteria fixed before the first line of server code is written, so finishing the over and knowing whether it went to plan are the same moment, not two separate questions.