Record the workflow and the integration you actually have
Begin with one task, its input, the next owner and the destination record that would prove completion. Then record the AI application, MCP client and server, transport, integration versions and environment. Identify who owns access and who handles failures.
Use the protocol revision supported by the deployed client and server. The official “latest” documentation resolved to revision 28 July 2026 when reviewed on 13 October 2026. That does not establish which revision your software implements or whether an upgrade is supported. Keep the deployed versions with the test evidence.
The checks below are operational recommendations. They help you decide what to investigate or include in a pilot; they are not evidence that an untested integration is safe or ready for production.
Separate authentication from permission to act
For each tool, write down the account and data it may access, whether it reads or changes a record, and the operations the workflow is allowed to perform. Confirm that an unauthorized operation is rejected by the actual application or server controls.
The MCP authorization specification describes transport-level authorization for HTTP-based integrations. It requires access tokens to be validated for the intended MCP server. A successful sign-in or valid token does not, by itself, approve a particular business update. The workflow still needs an allowed-operation policy and the destination’s own permissions.
Decide which changes need a reviewer, which may run under an explicitly approved bounded rule and how a person can stop the workflow. Check that a changed input or destination cannot silently reuse an approval for a different operation. Tool annotations can describe behaviour, but the tools specification says clients must treat them as untrusted unless they come from trusted servers. A label such as “read only” is not your access control.
Use the approved method for credentials and sensitive data. Keep tokens and confidential input out of shared test reports; retain redacted evidence that still identifies the tested account scope, operation and result.
Check discovery after reconnect and access changes
Record the tool list visible to the intended user before the test. Where the server paginates discovery, check that the client reaches every page. Compare the list after a reconnect and after an agreed permission change; do not assume a catalog captured under one account is valid for another.
The tools specification supports pagination and permits an empty tool set. An empty result can be legitimate. The useful question is whether the integration can distinguish a confirmed empty catalog from failed or incomplete discovery, and explain the resulting state to the operator.
If a gateway retains saved entries for diagnosis or recovery, those entries must remain subject to the current access boundary. Retaining a name does not justify calling a tool whose permission has been revoked. Test the behaviour your own integration promises, including what it displays while discovery is unresolved.
The engineering note linked below describes a scoped open-source change concerning empty OAuth discovery and a saved catalog. It documents historical tests and their limits. It is related implementation evidence, not a claim that the same fix applies to your system or that a customer deployment was measured.
Make a tool failure visible as a failed operation
Test a rejected request and an application-level failure as separate cases. The tools specification distinguishes protocol errors from tool execution errors, which can appear in a result with isError set to true. A completed HTTP request is therefore not enough to establish business success.
Keep an attempt reference, the tool and destination involved, a redacted error and the next owner. The status shown to that owner should reflect the evidence: an operation may be confirmed, failed or still unknown. An answer should not claim that a task was created merely because a call was attempted.
Agree timeouts and a route for unresolved operations. The tools specification calls for timeouts and logging for audit purposes. For this workflow, decide which identifiers and versions need to be kept, who can inspect them and how long they are useful. A log without an accessible owner or destination reference may not support recovery.
Reconcile an ambiguous write before retrying it
A write can reach its destination even when the response is lost. Create this situation in an approved test environment and check what the integration does next. Blindly repeating the request may create a duplicate task, message or record.
Where the destination supports idempotency keys, use its documented mechanism and verify its scope and expiry. Otherwise, agree how to look up the original attempt and when an operator must decide. If the lookup cannot establish what happened, preserve an unknown state rather than reporting success or automatically making another write.
Also inspect the consistency guarantees of any state store used to coordinate attempts. For example, Cloudflare documents Workers KV as eventually consistent; changes in other locations may take 60 seconds or more to become visible. It says KV is not ideal for atomic operations or a single read-and-write transaction. This is a storage-specific example, not a property of all MCP integrations. Choose and test the mechanism required by your own workflow.
Agree the cases and the evidence before release
Use approved synthetic or redacted inputs in the permitted environment. Agree expected outcomes before running the cases, then keep the observed result and remaining gaps separately. The table is a starting set of proposed checks; adapt it to the actual tools and consequences.
| Case to exercise | Evidence to inspect | Acceptance question |
|---|---|---|
| Normal operation | Input and approval version, attempt reference and destination record | Did the intended record receive the agreed fields? |
| Missing or invalid input | Validation result and operator-visible status | Did the item stop without an unsupported change? |
| Permission denied or revoked | Actual rejection and the visible account scope | Were further unauthorized operations prevented? |
| Reconnect or changed catalog | Complete discovery results and the resulting tool state | Can the owner see a legitimate change or unresolved discovery? |
| Tool execution error | Tool result, redacted error and owner assignment | Does the workflow report failure instead of success? |
| Write succeeds but response is lost | Original attempt and destination reconciliation | Is retry withheld until the outcome is established or reviewed? |
| Operator takes over | Runbook and observed exception exercise | Can the designated owner resolve or route the item? |
Leave the next owner with a usable operating guide
The handover should identify the allowed operations, access owner, known limits, failure states, recovery steps and escalation route. Keep enough information to repeat the evaluation after a relevant integration or permission change.
Ask the designated owner to run one normal case and one exception using that guide. If the creator must intervene, record what is missing. A reliability review may result in a code fix, a permission correction, a smaller boundary or a documented evidence gap; these are different outcomes and should be reported separately.
I review scoped MCP and AI agent failures as an independent FDE engineer. Begin with one observed problem, what should have happened and the relevant tools. Access, evaluation, deliverables, fees and dates are agreed in a written scope.
The checklist contains proposed operational checks, not results from your systems. The linked engineering note covers independent open-source work; no customer uptime, certification or commercial result is claimed.