Guide
Investigate an MCP tool call without mistaking permission for success
The agent says it closed a support ticket. The customer still sees the ticket as open. The gateway recorded a permitted Model Context Protocol (MCP) call.
All three statements could be true. The call may have been allowed and still failed before the ticket changed. Follow the request into the ticketing system before deciding whether to retry.
The following case is hypothetical. The records are summarized for explanation; they are not captured Dome events or a completed product test.
Start with the ticket and time window
The question is: did support agent A cause ticket T-1042 to close during the incident window, and under what authority?
Start with the known workspace, agent ID, ticket reference, and time range. Avoid querying only successful-looking rows. A denial, execution error, or missing completion may explain the discrepancy.
Use the audit evidence contract for field semantics and completeness. This example follows one request from the agent to the ticketing system.
What does each record actually tell you?
| Illustrative evidence | Supported conclusion | Still unknown |
|---|---|---|
| Agent A attempted the ticket-close tool | The recorded workload requested that operation | Whether it was permitted or dispatched |
| Governing record is allowed and carries loaded-policy provenance | The recorded decision permitted the request under that policy | Whether the backend accepted or committed it |
| Completed phase carries an upstream timeout error | The governed call ended with an execution problem | Whether the backend committed before the timeout |
| Application reports failure to the user | The client did not receive a usable success result | The ticket's authoritative state |
| Backend history shows no committed closure for the correlated operation | The inspected backend evidence does not show that change | Whether another request or path changed the ticket |
The last row requires actual backend evidence. It cannot be filled by interpreting result=allowed more optimistically.
Find who called and which rules applied
Retrieve the relevant operation using the audit query tools. Save the query scope and filters with the case.
Identify the stable agent actor. If represented identity appears, preserve its verification context. Do not infer a human from a display name or an application message.
When the governing event carries policy provenance, inspect the bundle versions and effective-policy identity recorded for that decision. Today's rules may differ. If the event did not reach loaded-policy evaluation, report the actual refusal or failure stage rather than attributing it to a rule that was never applied.
Dome's audit model keeps configuration changes and runtime decisions in the same workspace trail. Use that to check whether a nearby policy deployment explains the behavior, without assuming temporal proximity proves causation.
Follow the attempt, completion, and any retries
Use the operation identifier to join attempted and completed phases. A completed lifecycle phase means the operation record reached completion; its independent error information may still show that execution failed.
Next inspect related requests using trace or activity correlation as appropriate. Look for application retries. Two attempts might refer to the same ticket but have different backend outcomes.
If an activity ID is caller-asserted, it remains a useful grouping aid, not verified proof that every event belongs to an authorized delegation chain. Keep that qualification in the case notes.
Check whether the ticket changed
Ask the ticket service for the corresponding request or transaction evidence. Use its identifiers and timestamps, and record the join method if there is no shared identifier.
For an uncertain timeout, the safe next action is not necessarily to retry closure. First establish whether the original request committed, whether the backend supports idempotency, and what state the ticket is now in.
If you can't inspect the backend, say: “The call was permitted, but we haven't established whether the ticket changed.” Name who can retrieve the missing record. Don't fill the gap with the agent's success message.
Write a finding another investigator can check
For this illustrative sequence, an appropriately bounded finding would be:
Agent A's recorded ticket-close request was permitted under the recorded policy. The call then ended with an upstream timeout. The inspected backend history does not show a committed closure for the correlated operation. The application should reconcile current ticket state before retrying.
Attach the event IDs, query window, completeness information, policy reference, backend records, and unresolved gaps. Another investigator should be able to reproduce the finding without access to the original investigator's memory.
Keep the decision about retrying attached to the ticket's current state, not just the gateway's permission record.