Call a tool when the result can change the answer
Useful tool calls resolve material uncertainty. A current documentation lookup can establish an API contract. A test run can establish behavior. A calculator can remove arithmetic error. A repository search can show where a symbol is actually used.
ReAct frames actions as a way to gather information from an environment while reasoning about a task. Toolformer shows that tool selection also includes timing, arguments, and using the returned result. Both point toward the same principle: a call should have an expected information gain or authorized effect.
Before calling, the agent should be able to state what the result will establish. After calling, it should compare the returned evidence with that expectation. This prevents tool activity from becoming a performance that looks capable but does not improve the answer.
Source figure
Toolformer filters API calls by whether they help prediction
Figure 2 from Toolformer shows its training pipeline: sample candidate API calls, execute them, retain calls that reduce prediction loss, and insert the useful calls into training text. This is the paper's training method, not a production authorization model.
Schick et al., Figure 2The contract should be narrower than the model
A model can produce arbitrary text, but a tool should accept a small typed schema. A focused name and description help selection; required fields reduce ambiguity; bounded outputs keep the next model step inspectable. Errors should be structured enough to support safe recovery.
- Name the fact established or action performed.
- Reject unknown fields and oversized values.
- Return provenance, status, and a concise result.
- Make retries explicit and idempotent where possible.
| Contract element | Good question | Failure it prevents |
|---|---|---|
| Description | What exact fact or effect does this tool provide? | Calling the wrong capability |
| Input schema | Which fields are required and what ranges are valid? | Ambiguous or oversized requests |
| Permission | Who may call it and under which conditions? | Unauthorized action |
| Result schema | How are status, evidence, and errors represented? | Treating failure as success |
| Retry policy | Is repetition safe and when should it stop? | Duplicate side effects and loops |
Separate observation from mutation
Read tools collect evidence without intentionally changing the target system. Write tools create, update, send, spend, deploy, or delete. Keeping these categories separate makes it possible to grant broad observation while reserving consequential operations for explicit approval.
A preview tool can bridge the two. It calculates the proposed mutation, affected resources, and expected validation without applying the change. The user or policy engine can inspect that preview before invoking a smaller commit tool with the approved parameters.
For coding work, search, file reading, and test discovery are observational. Editing a file is a mutation, even when it is locally reversible. Pushing a branch, merging code, modifying infrastructure, or publishing a package has a wider consequence and should cross a stronger authorization boundary.
Internet tools cross a trust boundary
Prompt injection is possible because models process instructions and external data in the same natural-language channel. OWASP recommends treating external content as untrusted, separating instructions from data, validating outputs, and applying least privilege to connected tools.
An HTTP tool should allow public HTTPS targets, validate every redirect, block local and private network ranges, cap response size, and enforce timeouts. Secrets should be stored outside user-authored URLs and headers. A fetched page may provide evidence, but it does not gain authority to rewrite the user's goal or platform policy.
Content sanitization alone cannot guarantee safety because an injection can be expressed in ordinary language. The stronger architecture assumes that untrusted text may contain persuasive instructions and prevents that text from gaining credentials or permissions through deterministic runtime boundaries.
The trust boundary around an internet tool
Every transition narrows authority. Remote content can become evidence for the model, but it never directly becomes an authorized tool command.
Untrusted network
Public URL and response
The page may be useful, incorrect, malicious, oversized, or designed to redirect toward internal services.
Transport guard
Validate the request
Require HTTPS, block private addresses, recheck redirects, and enforce byte and time limits.
Content boundary
Label evidence as data
Extract the permitted content with source identity and keep its instructions below platform and user authority.
Model decision
Reason with the evidence
Use supported facts, reject conflicts with higher-priority instructions, and propose any next action explicitly.
Permission gate
Authorize a separate tool
The runtime validates the chosen action, typed parameters, user permission, and approval requirement.
Defense-in-depth interpretation of OWASP guidance for indirect prompt injection and tool least privilege.
Errors should teach the loop how to recover
A useful error distinguishes invalid input, denied permission, unavailable dependency, timeout, rate limit, and execution failure. Returning one generic failure string encourages blind retries because the agent cannot tell which part of its plan must change.
Retries are appropriate for transient failures when the operation is idempotent or protected by an idempotency key. They are not a default response to validation errors or denied authority. In those cases, the loop should revise the input, choose a different path, or ask the user.
Cap repeated attempts and preserve the last useful evidence. A stopped tool loop should report what was tried, what failed, and what new input or authority would unblock the task. That is more useful than consuming the remaining budget on nearly identical calls.
Verify effects in the environment
After a write action, inspect the resulting state. For code, review the diff and run targeted tests. For an API mutation, read back the changed record. For a deployment, check health and logs. The model's statement that an action succeeded is not evidence of success.
Stop when additional calls are unlikely to change the conclusion, the goal has been verified, or the next operation requires more authority. This keeps tool use purposeful and makes cost and risk easier to understand.
Logs should connect the proposal, authorization, call, result, and verification without exposing credentials or sensitive payloads. This chain lets developers reproduce failures and lets users understand which external systems affected the final answer.
Sources and further reading
Claims and figures in this article were checked against these original papers and official project resources.
- 1ReAct: Synergizing Reasoning and Acting in Language Models
International Conference on Learning Representations, 2023
- 2Toolformer: Language Models Can Teach Themselves to Use Tools
Advances in Neural Information Processing Systems, 2023
- 3LLM Prompt Injection Prevention Cheat Sheet
OWASP Cheat Sheet Series, 2025
