What to inspect
Treat tool selection, execution, result handoff and the final answer as separate checkpoints. A model requesting a function does not prove that the function ran. Keep a correlation identifier so each returned result belongs to the right call.
Worked example
Example test: request the status of order DEMO-42. A mock tool returns status=delayed. The final answer must report delayed. Repeat with a tool error and verify that the assistant reports the limitation instead of inventing a delivery date.
Copy the full prompt
Adapt the inputs to your task. Remove private data before sending anything to a model. This page copies text locally; it does not run the prompt.
Write a local test plan for [TOOL INTEGRATION]. Trace the user request, tool-call identifier, validated arguments, tool result and final answer. Use a mock tool and no external writes. Include a success, malformed arguments, a tool timeout, an unknown tool and an out-of-order result. State the expected behavior for each case. Check the current provider API documentation before proposing SDK code.
Review checklist
- Validate arguments before calling the tool.
- Match the result to its call identifier.
- Exercise tool failures as well as success.
- Check the final answer against the actual result.
Keep the resource
Download the complete note ↓Markdown · explanation, example, prompt and checklistDownload the prompt ↓Plain text · ready to adaptOpen the full-size visual ↓SVG · scalable reference diagramDocumentation & scope
This is an original workflow template with an illustrative example. It does not report completed model tests or measured performance. Provider APIs can change; check the linked documentation for your exact integration.