Build and test a server

In this module you will

Build an MCP server in three layers (data and rules, tool adapter, transport) so that each layer can be tested on its own.
Write tool descriptions, schemas and error messages that a model can act on, and test that they stay that way.
Set up seven test layers (unit, contract, snapshot, conformance, end-to-end, transport, security) and say what each one catches and what it cannot.
Use mutation testing to find out whether your tests would notice a real bug, instead of assuming they would.
Show that the same server works through four doors (two protocol eras, a child process, and HTTP with OAuth), so you know the server is not tied to one client.
Answer the interview question "how would you test an MCP server?" with measured, specific points.

Modules 1 to 5 each looked at one concern: what a tool should expose, how the protocol is shaped, how it travels, how it asks the person for things, and how it is secured. This module puts them together into the project of the level: your own MCP server, used by an agent and by one other client, with authentication that is handled and tested, and tool errors that tell the model what to do next.

A server is different from most programs because it has two kinds of reader. A machine reads the JSON (does it follow the protocol?). A model reads the words (does the description say when to use this tool? does the error say what to do next?). A test suite that checks only the first kind lets through the mistakes that hurt agents most: a vague description, an error that says only Error: 500, a tool list that quietly changes.

About the examples, and about hand-writing a server

The example is a help desk: 12 tickets in a real SQLite database, 8 tools, three kinds of user. Everything runs offline. Real: the database and its constraints, a real child process speaking over standard input and output, and a real HTTP server on 127.0.0.1. Imitated: the MCP server code itself is my own small teaching implementation (copied from module 2 and extended), not an official SDK; the OAuth world is module 5's simulated network; and the "model" is a script (it picks a tool by counting shared words and follows hints it can parse). A real model is better at some of this and worse at other parts, so the numbers show which servers give any reader something to act on, not how often a real model succeeds. Hard exercise 3 repeats the experiment with a real model, and I did not run it.

In a real project you should use an official SDK and not write the protocol yourself. What carries over from this module is what to test and how, which does not depend on whether the framework is mine or an SDK. The specification pages I used were read on 24 October 2026 under the site's draft path; check them.

Overview