A configured MCP server, a visible tool, and a verified result are three different things. Keeping separate acceptance criteria for them makes integration failures easier to locate and prevents an application from reporting work that has not happened.
This checklist starts with a small, authorized read. It is a documentation-based procedure, not a report of a live integration test. The examples below are illustrative and contain no observed results.
1. Record the transport and protocol revision
Identify the host application, its MCP client, and the intended server. These are separate participants: the host manages clients, and each client communicates with a server. Record their identities rather than treating a friendly display name as sufficient evidence. See the official architecture overview.
Check the configured transport. MCP's built-in transports are stdio, using a client-launched subprocess, and Streamable HTTP, using HTTP POST requests to an MCP endpoint. A running process or reachable endpoint establishes only one part of the path. Consult the transport specification for the binding your implementation uses.
Version matters here. The current 2026-07-28 revision uses per-request protocol metadata, with optional client discovery through server/discover; servers must implement discovery. Earlier, initialization-based revisions use an initialize handshake. Do not diagnose a modern client by assuming that it must emit a legacy handshake, or apply modern metadata rules to a legacy exchange. Record the revision actually supported by both implementations. The compatibility specification explains the distinction.
2. Check the principal and permitted scope
Protocol compatibility does not establish which application records the caller may access. Before the acceptance call, identify the intended user, organization, and application role. Use an approved test record or synthetic fixture within that user's permitted scope; do not probe another user's records to see whether access works.
MCP authorization is optional. Its authorization specification covers HTTP-based transports; stdio implementations should obtain credentials from the environment instead of following that HTTP flow. For implementations following the HTTP authorization specification, tokens must be intended for the receiving MCP server. Scope selection should follow least privilege. An HTTP 401 and a 403 are also different signals: the former can indicate required authorization or an invalid token, while the latter can indicate insufficient permissions. See the authorization specification.
Record the identity and relevant permission result, never the credential itself. A successful login does not justify requesting broader access for this test.
3. Discover a suitable tool
Use tools/list to inspect the exact tool name, description, and inputSchema. Follow pagination when needed. The returned tool set can depend on the authorization presented on the request. Discovery describes what is exposed; it does not demonstrate that an invocation returned useful data. See the tools specification.
If readOnlyHint is present and true, it describes a tool as not modifying its environment. It is an annotation, not an enforced security boundary. Tool annotations are hints, and clients should never make tool-use decisions based on annotations from untrusted servers. Review the operation and enforce access controls independently. The schema reference defines these annotations.
4. Make one bounded call
Illustrative scenario: a test server exposes get_record, and its schema accepts a record identifier. Select an approved synthetic identifier, request only the necessary fields if the tool supports that option, and state the expected result before calling. The name is hypothetical; use the real tool's schema rather than inventing its arguments.
Invoke the selected tool with tools/call. Inspect the returned content and, when provided, structuredContent. If an outputSchema is declared, validate the structured result against it. These are protocol features described in the tools specification, not evidence that this illustrative call was executed.
5. Classify failures before changing the test
The tools specification distinguishes two mechanisms. An unknown tool or a malformed call request can produce a JSON-RPC protocol error. A tool execution failure, including a business-rule or value-validation failure, can instead return a normal result with isError: true.
Therefore, receiving a JSON-RPC result is not enough to mark the call successful. Record the error category and explanation. Correct the relevant configuration or input; do not react to every failure by reconnecting, broadening permissions, or repeating an unrelated business action.
6. Accept the data, then name the outcome precisely
For the illustrative record read, check the returned identifier, expected organization, requested fields, and any freshness information the application provides. Compare against the approved fixture or another authorized source. A structurally valid response can still contain the wrong record, stale information, or less data than the task requires.
A compact acceptance note can record:
| Check | Evidence to retain |
|---|---|
| Compatibility | Transport, supported revision, server identity |
| Permissions | Principal and approved test scope |
| Invocation | Exact tool name, bounded arguments, timestamp |
| Result | Error status and validated response fields |
| Acceptance | Comparison source, remaining uncertainty |
Exclude secrets and unrelated personal data from that note. Keep each conclusion proportional to its evidence: tool discovery passed; a particular read returned; the returned data matched the fixture.
A read-only check establishes none of the outcomes of a later write. Likewise, an application receipt saying “accepted” or “queued” must not be relabeled “published.” Verify the later workflow's state using its documented status mechanism. This final distinction is an application-level acceptance practice, not a publication guarantee supplied by MCP.
AI-assisted disclosure: This article was drafted with AI assistance and checked against the linked official MCP documentation. All examples are illustrative. No live integration, customer system, or publication workflow was tested for this article.
Top comments (0)