Skip to lesson
supraj.dev THE ENGINEERING HANDBOOKS
LEARN / BUILD / VERIFY2026 edition · checked 06 Oct

CHAPTER 28 / 30 · Build with evidence

Capstone: a bounded ParcelOps contract lab

Run deterministic fixture checks and assemble an honest integration evidence packet.

4 min read + practiceWorked exerciseInterview practice

The mechanism

The capstone brings the book’s boundaries together in one offline exercise. A synthetic reader returns a copied incident record. Request checks enforce the required modern metadata for the subset we model. Approval checks bind a proposed write to an exact intent. Cache keys include authorization context.

The downloadable Python file uses only the standard library. It performs no model call, network request, filesystem scan or incident write. Its assertions teach application invariants; it is not a full MCP implementation, a JSON Schema validator or a conformance certification.

Keep the optional SDK server from chapter 6 as a separate integration track. Only after installing a compatible official SDK in an approved disposable project should you test real discovery, transport behavior and a host connection.

Synthetic fixtures
Deterministic checks
Retained output
Explicit evidence limits

Worked example

Download the lab from this site and run it in a scratch directory using a supported Python 3 runtime. The command executes only the local fixture tests. Inspect the file first. Do not interpret the test count as coverage of every protocol requirement.

python3 parcelops_contract_lab.py
# Download: /handbook/mcp-servers/parcelops_contract_lab.py
# Expected: unittest reports the implemented fixture checks and OK.
# SDK / HTTP / OAuth / model integration: not run by this command.

Practice: predict, inspect, explain

Offline exercise. Run the lab, retain its output and read each assertion. Change one fixture so a required metadata field is missing, then predict which test would detect it. Restore the original fixture afterward. Add a separate proposed test for a real HTTP header/body mismatch; do not claim the offline metadata check covers that transport.

Expected observation: the suite establishes a narrow set of deterministic behaviors. Create an evidence packet containing the file hash, runtime version, test output, scope and unrun integration checklist. The optional SDK and model paths remain explicitly untested until actual runs occur.

Troubleshooting and trade-offs

If a test fails, inspect the assertion and input before loosening it. If the local interpreter is too old for the file, use a supported runtime in the disposable project rather than altering system Python. A successful run does not validate package provenance, authentication, concurrency or production limits. Those are separate acceptance gates.

Interview practice

Why avoid a model in this capstone?

The selected invariants are deterministic and can be tested without cost or probabilistic behavior. Model selection and answer quality deserve a separate evaluation set.

What makes the evidence packet credible?

Exact artifacts, versions, commands, observed output, explicit scope and honest unrun items. It should let another engineer reproduce the same local checks.

Completion check

Run the fixture suite and explain at least four important capabilities it does not test.

Sources and version notes

This edition targets MCP 2026-07-28, checked 6 October 2026. SDK examples are version-sensitive and labelled when not executed. Synthetic fixtures are learning material, not protocol conformance evidence.

YOUR NEXT STEP

Make the understanding yours.

Use the completion check above. Mark this chapter when you can explain the mechanism and its limits.

Self-assessed reading progress. This does not certify that a lab ran or a system is secure.