The mechanism
Testing an MCP integration has several layers. Pure-function tests check business logic. Contract tests check schemas and result shapes. Transport tests check framing, headers and lifecycle. Host tests check permission presentation and compatibility. Model evaluations check selection and interpretation. A passing test in one layer does not establish the others.
The official Inspector provides ways to exercise servers, including explicit protocol-era behavior. Use a compatible, pinned installation in a disposable project after reviewing its current instructions. Launching a server through an inspector still executes code with local permissions; a test UI is not an isolation boundary.
Begin with deterministic fixtures and forbidden-effect assertions. They are cheaper, easier to reproduce and more diagnostic than asking a model whether the server “looks good”.
Worked example
This is a test plan, with honest initial statuses. Each row needs a concrete expected outcome and retained evidence. The downloadable capstone implements only a subset of local fixture checks and is explicitly not a full MCP conformance suite.
lookup: existing, missing, malformed, returned-copy isolation
wire: required metadata, response correlation, complete result
security: denied write, foreign object, untrusted instruction
transport: stdout framing, HTTP header/body consistency
integration: discovery and tool call against pinned SDK [not run]
model: correct selection and evidence-bound answer [not run]Practice: predict, inspect, explain
Offline exercise. Choose one failure per layer and write the smallest test that detects it. For example, a malformed ID needs no model; a missing method header needs an HTTP integration fixture. Record expected output before execution so the test cannot be reinterpreted after it fails.
Expected observation: the resulting plan explains exactly what evidence is missing. Run the provided offline lab and preserve its test output. Keep SDK, network and model checks marked not run until an approved environment actually executes them.
Troubleshooting and trade-offs
A test that only asserts “no exception” may miss wrong data or forbidden side effects. A mock transport can hide framing defects. A live model can hide deterministic bugs by avoiding the affected tool. Use narrow fixtures for diagnosis, then representative integration checks. Do not run arbitrary server installation commands from an untrusted catalog as part of testing.
Interview practice
Why use Inspector after unit tests?
It exercises the protocol-facing interface and transport behavior that pure functions do not cover. Both layers are necessary for different reasons.
What does the offline capstone prove?
Only the documented deterministic invariants of its synthetic fixture model. It does not certify SDK compatibility, authentication, distributed behavior or model quality.
Completion check
Assign every proposed test to a layer and state one important limitation of the executed fixture checks.
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.
- Official documentation: Inspector
- Official documentation: Protocol eras
- Official documentation: Recipes
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.