An MCP response is not proof that the job is done
Separate protocol success, tool execution, and the user's intended result when diagnosing an MCP integration.
Imagine asking an agent to create a draft report in a shared workspace. The tool returns a response, the agent announces success, and the report is nowhere to be found. The useful debugging question is where the evidence stopped.
Did the client reach the server? Did the tool execute? Did it create the intended object in the intended account? Those are different claims. An integration that collapses them into one green indicator makes failures harder to find.
Read the result at the right level
The MCP tools specification dated 2026-07-28 distinguishes protocol errors from tool execution errors. A tool execution failure can arrive inside a result with isError: true. The presence of a JSON-RPC result therefore does not establish that the requested operation succeeded.
That revision also distinguishes resultType: "input_required" from resultType: "complete". The first requests additional input; the second supplies the finished tool result, which can still report an execution error. Check the protocol revision your integration implements.
The optional Tasks extension adds resultType: "task", returning a handle for asynchronous work. Task support requires both client and server opt-in. Poll tasks/get until the task reaches completed, failed, or cancelled; all three states are terminal. If the state is input_required, handle the outstanding inputRequests and send responses through tasks/update so work can continue. A completed task supplies the original operation's result, which can still report a tool execution error with result.isError: true. A failed task instead supplies a JSON-RPC error in its error field.
Cancellation is cooperative. A tasks/cancel acknowledgement does not guarantee that the server stopped the work. Check the reported task state and the destination before assuming an external write did not happen.
For an application using this contract, check both the protocol response and the tool result. Then interpret the tool's documented output. An accepted asynchronous job, for example, still needs a later completion check. An object ID establishes identity; it does not establish that the object's contents satisfy the request.
This article proposes a three-level diagnostic record. It is an application design recommendation, not an additional MCP requirement:
| Level | Question | Evidence to retain |
|---|---|---|
| Request | Did the invocation receive a valid response? | Request ID and protocol error, if present |
| Operation | What did the tool report doing? | Error status, object ID, or asynchronous job state |
| Outcome | Does the result satisfy the brief? | Read-back of the intended object and relevant fields |
Follow one report through the system
For the draft-report example, define success before running the task: one draft in the selected workspace, with the requested title, source links, and no publication action.
After creation, use the returned identifier to read the object. Check its workspace and contents. If the connection cannot read it back, retain that limitation in the completion report. Do not replace missing evidence with a confident sentence.
The failure report should point to the stage that needs attention. “The server rejected the tool name” sends you toward discovery or client configuration. “The tool returned a permission error” sends you toward the granted account access. “The draft exists in another workspace” sends you toward target selection.
Each diagnosis suggests a different fix. Retrying the same request without that distinction adds noise and can create duplicate work.
An execution error also does not prove that no external change occurred. If a write's outcome is uncertain, reconcile the destination or follow the provider's documented retry contract before repeating it.
Build the status users need
For this workflow, useful application states might be requested, accepted, created, verified, and needs attention. Choose states that correspond to observable events. A system need not expose every internal transition, but its final success label should have a clear meaning.
Keep raw secrets and unnecessary document contents out of diagnostic records. A useful trace needs enough information to locate the affected operation, not a copy of everything the tool could read.
When comparing agent tools, ask a vendor to demonstrate a failed operation and an accepted-but-unfinished job. Watch what the interface reports and what the agent tells the user. That demonstration reveals whether the product helps you diagnose incomplete work.
For the broader connection plan, read Connect the right tools.
Sources checked October 23, 2026. The diagnostic record is our application design recommendation.