Tool use and function calling

The concept

Tool use lets a model request an external action instead of answering only from text. Function calling is one common API pattern: the model emits a structured call, your application runs the function, and the result goes back to the model or directly to the user.

The prompt tells the model when a tool is appropriate. The tool schema tells it what arguments are possible. If the rules should apply across a whole product assistant, put them in a system prompt.

The current approach

Describe tools in operational language. Give each tool a narrow purpose, clear argument names, and a real boundary.

Use get_invoice_status only when the user asks about a specific invoice or charge.
Do not use it for general billing-policy questions.

OpenAI, Gemini, and Claude all document current tool or function-calling flows, but the product shape differs. The durable prompting rule is the same: separate “what the tool does” from “when the assistant should use it.”

For an end-to-end product prompt, see system prompt design for products.

A practical example

You help support agents investigate account questions.

If the user asks about account status, request lookup_account with the account_id.
If the user asks for policy, answer from the policy document and do not call tools.
If the account_id is missing, ask for it instead of guessing.

That instruction gives the model a decision rule before it sees the function schema.

What to avoid

• Giving a tool a broad name like handle_request.
• Letting the model invent arguments that the function cannot accept.
• Using a tool when the answer should come from static policy.
• Treating tool use as a safety boundary. Your application still needs permission checks and server-side validation.