Ịkpọ oku ngwaọrụ

The application or provider executes the operation and returns a result. A model proposing a tool call is different from that call succeeding, and both are different from the user’s overall task being completed.

Isi ihe na-ewe

• Validate authority as well as argument shape.
• Design safe retries for side effects.
• Verify the resulting state.

Define each tool’s purpose, input schema, output shape, and side effects. A narrowly scoped operation is easier to validate than a general command interface. The tool description should explain when the operation is appropriate without granting the model authority beyond the user’s request. Validate inputs and permissions in application code. A well-formed argument can still identify the wrong account, destination, or amount. Keep secrets out of tool descriptions and return only information the requesting user is allowed to access. Handle errors and uncertain outcomes explicitly. A network timeout may occur before or after an external action completes. Use operation identifiers or a read-back check where possible so a retry does not duplicate a completed action. After execution, supply an accurate result and verify the intended state. Treat text returned by a website or document as untrusted content; it cannot authorize new actions merely because it arrived through a tool. Test cancellation, malformed responses, revoked access, and partial completion as part of the full tool-use loop.

1. Imagine a task-creation tool accepts request identifier demo-17. The response times out after the task is created.
2. Look up demo-17 before creating another task. If the service supports idempotency, reuse the same identifier for the retry.
3. Report completion only after confirming the resulting task and its contents.

This constructed example separates uncertain transport from the external action’s actual outcome.