Tools troubleshooting: catalog, calls, recovery
Diagnose and resolve Duale AI Tools issues including catalog status, blocked or denied calls, temporary pauses, unknown outcomes, and Connection recovery.
This page covers symptom diagnosis, Tool pause recovery, unknown outcome handling, Connection recovery, and support escalation for Tools troubleshooting.
- Symptom-to-check mapping for catalog and call states.
- Tool pause behavior and recovery testing.
- Unknown outcome reconciliation and idempotency guidance.
- Connection recovery without recreation.
- Support escalation details and required information.
Summaries were generated by AI.
Start from what the Dashboard shows under Tools. The Dashboard does not show why a catalog check failed, so each branch below checks what you control: the endpoint, the remote credential, the call policy, and the assignment. Operate Tools defines every state and outcome named here. For an SDK Tool that your own process serves, use the Tool Host section of SDK troubleshooting instead.
Find the symptom
| Symptom | First check | Safe next action |
|---|---|---|
| Catalog status shows Unavailable | Whether the Dashboard read failed | Retry the read; this state says nothing about the remote server |
| Not observed | Endpoint format, remote availability, and credential | Correct the Connection, then let the next check recover it |
| Expired | Last successful check time, remote availability, and access | Restore the server or the credential; checks continue while the Connection is enabled |
| No Tools reported | Whether the remote account can list Tools | Grant only the list access needed, then wait for a successful check |
| A Tool is incompatible | The reason shown in Catalog | A schema reason needs a change on the server; a reserved argument name needs that argument renamed on the server; a revision reason needs a server that negotiates a supported revision |
| A Tool the server lists is not offered | Catalog freshness, compatibility, call policy, and assignment | Fix the first of these that does not allow the Tool |
| Calls are Blocked or Denied | Whether the Connection is enabled, its call policy, and the Agent Identity assignment | Change only the setting that must allow the call. After you disable a Connection, its Tools can stay offered for a short time, and calls to them end as Blocked; calls to a deleted Connection end as Failed |
| A Tool Call reports that the Tool is temporarily paused | Recent technical failures of that Tool | Wait, then test once |
| Outcome unknown | The destination system’s own record | Reconcile before any repeat |
| The answer says that a safety check blocked a step, and the server returned a result | Whether that Tool Result tells the model what to do, for example to drop its Task or reveal its instructions | Change the server so its results return data, not instructions to the model. If the result is benign, check whether your model provider filters its subject. A result that passes on content you do not control can be hidden the same way, which protects the Task |
| The answer says that a safety check blocked a step, and the server never received the call | Whether the Task’s request names the recipient, destination, or change that the call makes | Name them in the request, then continue the Task. Duale AI does not send a call that a safety check blocked |
| Tasks of one Agent Identity stop progressing after a new assignment | Whether the Agent Identity’s Tools grew past its bound | Remove an assignment |
| The confirmed success rate is blank | How many succeeded or failed calls the selected period holds | Select a longer period, or wait for more calls |
A Tool is temporarily paused
Duale AI paused calls to that Tool on that Connection after repeated technical failures, and did not send this call to the server. Understand the MCP call contract states the pause rule and its length. Catalog checks and other Tools on the Connection continue during the pause.
Wait until the pause ends, then test the Tool once with a low-risk Task. Do not send repeated Tasks to force recovery.
Check. The test call ends as Succeeded in the Task view or in Analytics. If it pauses again, check the server’s own logs for the failing requests before you test again.
An outcome is unknown
Duale AI cannot prove the call’s result, and it cannot rule out that the server received the call. The remote operation can have run, or not.
- Read the destination system’s own record of the operation.
- If the operation happened, record it and continue from that state.
- If it did not happen, repeat it only when a repeat is safe.
Make state-changing remote operations idempotent so that a repeat cannot double an effect. Secure integration gives the procedure and the identifiers to keep.
Check. The destination system shows the operation exactly once, or not at all. Stop if you cannot read that record; do not repeat the operation.
Recover without recreating the Connection
When a server is down, Duale AI keeps checking until you disable or delete the Connection. Correct the endpoint or the remote credential: saving the change starts a new check at once. After you fix the server itself, let the next scheduled check refresh the catalog. Deleting and recreating the Connection does not speed recovery, and you must assign the new Connection again.
Check. The catalog shows Active with a recent last successful check.
Ask for support
If the endpoint and credential appear correct and the state does not recover, email technical support. Include the Connection ID, Connection name, current status, approximate time of the problem, and the last successful check time if the Dashboard shows one. Never send the bearer token, API key, or unrestricted logs by email.