Deploy and review
Run the final test matrix
Test discovery and representative success, validation, absence, security, and transport cases across local and remote servers.
8 minute lesson
Unit tests can verify search logic, but an MCP server also needs contract tests through a real transport.
Add this table to TESTING.md and record the result of each row:
| Area | Test | Expected |
|---|---|---|
| Discovery | List tools, resources, prompts | 2 tools, 1 resource, 1 prompt |
| Search | Query deploy | One matching note |
| Validation | Empty query | Rejected before handler |
| Lookup | Unknown ID | Clear error result |
| Resource | Read notes://catalog | Valid JSON catalog |
| Prompt | Render topic deploy | One review message |
| Boundary | Request hidden/local data | No capability exposes it |
| Transport | Repeat locally and remotely | Equivalent capability results |
| Protocol | Record negotiated revision | Expected modern or legacy era |
| Output | Compare text and structured data | Same successful payload |
| Injection | Read hostile practice note | Returned only as note data |
| HTTP path | Request a different route | 404 |
| Authorization | Missing, invalid, wrong-scope token | 401, 401, 403 |
The authorization row applies when the endpoint is protected. For a public practice-data deployment, mark it “not implemented: public demo” rather than pretending it passed.
Run the matrix against stdio first, local HTTP second, and deployed HTTP last. Record exact arguments and results, not only “works.”
Repeat negative calls after each transport change. Success can survive a broken validation or error path.
Record these test conditions beside the table:
- SDK and Inspector versions
- negotiated protocol revision
- commit or deployment version
- date and endpoint
- whether authorization was enabled
A screenshot is optional. The saved arguments and results are the evidence that matters.
Lesson completed