HTTP 200 confirms a successful HTTP response under the endpoint’s contract. It does not, by itself, confirm that an AI agent completed the user’s task. A tool can return a valid response containing a rejected operation, an empty result, a queued job, or information about the wrong object.
Agent monitoring needs separate records for transport status, tool result, business outcome, and the final claim made to the user.
Four questions for one tool call
| Layer | Question | Example |
|---|---|---|
| Transport | Did the client receive a valid response? | HTTP 200 |
| Tool | Did the requested tool operation succeed according to its contract? | Lookup returned successfully |
| Business outcome | Did the intended task reach the required state? | Refund remains pending |
| User communication | Did the assistant describe that state accurately? | Assistant incorrectly says “refunded” |
These layers can disagree without any network exception. A monitoring system that collapses them into one boolean discards the evidence needed to explain the disagreement.
Example: accepted is not completed
Imagine a document-export tool returning:
{
"job_id": "export_208",
"status": "queued",
"download_url": null
}The response can be valid and useful. The agent should explain that the export is queued and provide the appropriate way to check it. “Your file is ready” would be premature.
A checker needs the tool contract to distinguish these states. It should not treat every null URL as a failure because null is expected while the job is pending. Conversely, it should not treat a nonempty job_id as proof that a file exists.
For long-running actions, join later status events to the original request using a stable operation ID. The asynchronous monitoring guide covers that lifecycle.
MCP has more than one error channel
The MCP tool specification describes tool execution errors returned within a tool result using isError, separately from protocol-level errors. A client that only records transport success loses this distinction.
For your integration, inspect the protocol result, structured tool output, and domain-specific status. Do not assume a library’s generic “success” attribute means the task succeeded. Document exactly which boundary produced that attribute.
This is not specific to MCP. REST, queue-based workflows, and custom function tools all need a clear result contract.
Design a result that is hard to misread
Use explicit states rather than a catch-all success: true. A proposed application response might include operation_id, state, reason_code, and subject_id. Define terminal states and the conditions for transitions. Keep display text separate from machine-readable state.
| State | Safe interpretation |
|---|---|
| Accepted | The request entered the workflow |
| Pending | Work remains outstanding |
| Completed | The defined terminal condition has been confirmed |
| Rejected | The operation did not proceed under the contract |
| Unknown | The system cannot currently establish the outcome |
These names are illustrative. Use the provider’s actual states and an explicit mapping rather than renaming them until important distinctions disappear.
Test the adapter, not just the happy path
Build fixtures for a business rejection inside a successful HTTP response, an empty lookup, a queued action, an inconsistent object ID, and a malformed payload. Add a network timeout whose external outcome is unknown. That last case must not automatically trigger another side effect.
Check what reaches the agent after the adapter processes each response. The raw provider response may be correct while a wrapper reduces every 200 to “done.” A trace of both the raw status metadata and the normalized result can expose that bug without storing the entire sensitive payload.
Agnost’s tool-call view connects execution records to conversations. Supply the business outcome when it is necessary to judge the task; transport telemetry cannot substitute for it.
For a reproducible example, the synthetic detector exercise includes a business error with no execution exception. For a stronger user-facing safeguard, connect final completion language to the verified action receipt.