This is the procedure for an agreed engagement, not a claim that every test category below is already automated or has been demonstrated. Test feasibility is confirmed before accepting the scope.
01 / Authorization
Agree the boundary first.
The written scope names the target, the decision needed, up to two client or fallback paths, and up to 20 cases. It records who can authorize the work, allowed endpoints and operations, evidence recipients, exclusions, timing and stop conditions.
A public URL is not permission to test private data or invoke tools. Use an authorized test tenant and least-privilege access wherever possible. State-changing, chargeable or production operations need explicit written permission; if a safe test is not feasible, exclude it or record it as blocked.
Stop if authorization is withdrawn or disputed, unexpected sensitive data appears, an unapproved production effect occurs, or an agreed request or cost limit is reached. Notify the named contact and resume only after the safe path is agreed in writing.
02 / Reproducibility
Record the conditions.
Record the server release or commit where available, endpoint, host and client versions, operating environment, protocol version, transport, authentication method, test identity and permissions. Keep secrets out of this record. Unknown versions stay unknown.
Pin each expected result to a dated specification, the named client's documentation, a platform requirement, or an explicitly agreed local contract. Record the exact source URL, version and access date. A current requirement is not automatically a requirement for an older implementation.
The official MCP specification, version 2026-07-28 is a reference, not a universal test target. The applicable version is selected in the scope. Client and marketplace requirements are sourced separately.
03 / Execution
Define the check before running it.
Every case has an ID, prerequisite, permitted operation, input, expected result, evidence requirement and stop limit. Capture the actual result with a UTC timestamp. Record timeouts, retries and environmental failures instead of quietly replacing them with a successful attempt.
- Protocol and transport: version-appropriate connection, negotiation, discovery, request handling and supported transport behaviour.
- Identity and access: the named sign-in path, allowed and denied roles, and expiry or refresh only where authorized and safely testable.
- Tools and errors: advertised inputs, valid calls, agreed invalid-input cases, outputs and failure responses.
- Named-client behaviour: execute in the actual client and version. A scripted HTTP request alone is not a client-compatibility test.
- Workflow outcomes: agree the task, dataset, prompt, expected outcome and trial count. Verify the output and permission boundaries, not just that a tool returned successfully. Report varying outcomes and all attempts; do not imply determinism.
Only the agreed categories are included. Load testing, penetration testing, source-code auditing and implementation are outside this offer.
04 / Interpretation
Keep unknowns visible.
- PASS
- The executed case met its stated expectation in the recorded conditions.
- FAIL
- The executed case did not meet its stated expectation. State the observation and its bounded impact.
- BLOCKED
- A prerequisite prevented completion. Record what is missing; do not count this as a pass or an observed product failure.
- UNKNOWN
- Evidence is absent or insufficient to reach a conclusion. This is not a pass.
- NOT APPLICABLE
- The requirement does not apply to the agreed target, with the reason recorded. It is excluded, not passed.
A finding's priority is separate from its case result. A protocol pass is not proof of workflow success. A platform readiness decision is separate from individual cases and remains conditional on missing evidence. No universal score, certification, security assurance or marketplace approval is issued.
05 / Traceability
Make the conclusion inspectable.
Link the review, case, finding and evidence IDs. Record relevant request and response excerpts, timestamps, environment, expected result and actual outcome. Distinguish direct observation from inference and document what could not be checked.
The index identifies the delivered artifact, its redaction status and a SHA-256 hash where practical. Hash the delivered, redacted file and label it accordingly. A hash helps detect file changes; it does not establish independence, completeness or timestamp authenticity.
Keep only the evidence needed to support the finding. Do not describe harness logs as packet captures or label a simulated response as a customer observation.
06 / Data handling
Keep private evidence private.
Do not send credentials, tokens or private evidence through the enquiry form or ordinary email. Agree a buyer-controlled secure access route before testing. Minimize capture, redact secrets, separate buyer files and share only with recipients named in the scope. Revoke or return access when the work ends.
Raw private test evidence is normally deleted 30 days after delivery; the final report and redacted index are normally retained for 12 months. Credentials are not retained after their relevant test. Any different agreed or required retention is recorded in the scope. See the privacy notice for the full record categories and request process.
07 / Handoff
Deliver a decision and a re-test boundary.
The pack includes the environment and scope, case outcomes, a dated requirements matrix where applicable, evidence index, findings, limitations and concrete acceptance checks. Check IDs, artifact integrity, counts, redactions and conclusions before delivery.
One agreed re-test is included within 30 days of delivery. Record the changed version and a new run, preserve the original result, repeat the affected cases and agreed regression checks, and report what remains unresolved. New clients or requirements need new scope. There is no continuous monitoring subscription included.
Price, timing and agreement formation remain as stated in the service information. An enquiry does not authorize testing or trigger payment.
08 / Demonstration
What the sample actually proves.
The sample uses a fictional document reader on a local machine. Five HTTP requests were captured: four met the local contract and one failed because of a deliberately seeded missing-input error. A sixth workflow was blocked and was not executed.
It demonstrates a report and evidence structure. It is not a conformant MCP implementation, real-client test, OAuth test, customer engagement, independent certification or proof of commercial demand. The homepage's interactive examples are separate illustrations, not additional executed cases in this PDF.
The ZIP contains five JSON capture records, their manifest and a reading note. It contains no customer data or real credentials. The original test source is not included; its hash in the manifest is a provenance reference, not an independently verifiable source package.