Skip to main content
When tool calls fail or produce unexpected results, use these patterns to diagnose the issue.

LLM tools wrap the Document API

Every LLM tool call maps to a Document API operation under the hood. superdoc_edit with action: "replace" calls the same function as doc.replace(). This gives you a clear debugging strategy:
  1. Test the Document API directly. Call the underlying SDK method with the same arguments. If it works, the operation is fine: the problem is in the prompt or the tool schema.
  2. If the API call fails, the issue is in the operation itself: check arguments, targets, and document state.
  3. If the API call succeeds but the LLM tool call fails, the model is calling the tool incorrectly. Fix the prompt, add examples, or check the tool schema.
This narrows every issue to one of two layers: the operation or the prompt.

Log tool calls and results

Add logging around dispatchSuperDocTool to see exactly what the model is requesting and what comes back.
What to look for in logs:
  • Tool name: is the model calling the right tool?
  • Arguments: are required fields present? Is the action correct?
  • Targets: are handles/addresses from a recent search, or did the model guess?
  • Result: did the operation return data or an error?

Error shapes

dispatchSuperDocTool throws errors in two categories: Validation errors: bad arguments before the operation runs:
Execution errors: the operation ran but failed:
Both types are returned as strings in err.message. Pass them back as tool results: the model usually self-corrects.

Common failure modes

Inspect tools directly

Dump the tool schemas to verify the SDK loaded correctly:

Max iterations guard

Prevent runaway loops by capping the number of iterations: