Function calling: the model proposes, your application authorizes
Design narrow tools, validate arguments and permissions, execute the allowed action and return its real result.
In brief
In function calling, the model proposes a tool and arguments. Your application decides whether to run it, performs the action and returns a result. A model-generated call is not evidence that the action happened.
Keeping these stages separate prevents a fluent answer from being mistaken for a completed booking, lookup or update.
Give tools one understandable job
A tool that reads an authorized order’s status is easier to constrain than a generic tool that executes arbitrary commands. Define allowed identifiers and inputs, and keep credentials on the server. Do not trust a resource identifier merely because the model supplied it.
Check before acting
Verify the signed-in user can access the target, validate argument ranges and reject unexpected fields. For a change such as sending or purchasing, use the appropriate deliberate user authorization. A prompt saying “be careful” is not an enforcement mechanism.
Return the real result
Include the successful result or actionable error, not a fabricated placeholder. Use idempotency or equivalent duplicate protection for write actions when available, and bound retries. A network timeout can leave the action’s state uncertain; inspect that state before blindly repeating a consequential call.
Before you act
Arguments can be valid JSON and still request an unauthorized resource. Permission, validation and confirmation for consequential changes belong in the application.
What to do next
- Describe a narrow tool with defined arguments and an explicit action.
- Validate the request, user access and any required confirmation before execution.
- Run the allowed action once, return its actual outcome and handle failure without inventing success.
