LLM Function Calling and Tool Use Guide

A practical checklist for safe LLM tool use, including schemas, validation, permissions, retries, confirmations, testing, and deployment review.

Function calling lets an LLM choose and request actions such as looking up an order, creating a calendar event, or querying a database, while your application remains responsible for execution. This guide provides a reusable workflow for defining tools, validating arguments, handling retries and duplicate calls, enforcing permissions, returning results, and deciding when a human must confirm an action.

Overview

LLM tool use is best understood as a controlled handoff, not as unrestricted access to your application. The model interprets the user’s request and proposes a tool call. Your server checks that proposal, executes an approved operation, and sends the result back to the model. The model can then answer the user or request another tool.

A reliable architecture separates language decisions from application authority:

User request
    ↓
LLM with tool definitions
    ↓
Tool call: name + structured arguments
    ↓
Server validation and authorization
    ↓
External API, database, or internal service
    ↓
Sanitized tool result returned to the LLM
    ↓
Final response or another approved tool call

This separation is important because a valid-looking JSON object is not proof that an action is safe. The server should validate types, ranges, identity, permissions, and business rules independently of the model. Treat the model’s tool call as an untrusted request, similar to input from a public API client.

Provider interfaces differ in naming and response formats, so check the current documentation for the model and SDK you use. The durable design principles are provider-neutral: use narrow schemas, validate every argument, make side effects explicit, log decisions, and keep execution outside the model.

For broader prompt design context, see this prompt engineering guide. If your workflow uses retrieval, the RAG tutorial explains how retrieved context can fit into an application architecture.

Checklist by scenario

1. Read-only tools

Examples include searching a product catalog, retrieving an account status, or checking available meeting times. These are usually the simplest tools to introduce, but they still need scope controls.

Give the tool one narrowly defined purpose.
Require only the arguments needed for that purpose.
Apply limits to page size, date ranges, query length, and result count.
Filter results to the authenticated user or permitted workspace.
Return a predictable result shape, including an explicit empty-result state.
Set a timeout and define what the model should say when the service is unavailable.

A search tool should not quietly become a general database query tool. Narrow capabilities make prompts easier to test and reduce the impact of an incorrect model decision.

2. Tools that change data

Creating, editing, deleting, sending, or publishing something requires a higher bar. Separate planning from execution where possible. For example, use one tool to draft an email and another to send it, rather than exposing a single tool that both composes and sends.

Mark the operation as read-only, reversible, or destructive in your internal tool registry.
Require an idempotency key for operations that may be retried.
Check ownership and authorization immediately before execution.
Ask for confirmation when the action has material consequences, external visibility, financial impact, or irreversible effects.
Return an operation identifier so the result can be traced.
Make the success and failure states explicit instead of returning an ambiguous message.

3. Multi-step agent workflows

For an agent that can call several tools, define boundaries before adding more capabilities. Set a maximum number of tool rounds, maintain a per-request budget, and stop when the agent repeats a call or makes no measurable progress.

List which tools may be called after each step.
Pass only the context required by the next tool.
Record tool name, normalized arguments, authorization result, latency, and outcome.
Detect duplicate requests using an idempotency key or normalized argument hash.
Return a controlled failure when a dependency times out rather than allowing endless retries.
Provide a clear escalation path when the model cannot complete the task.

Agent memory and retrieval can add useful context, but they should not bypass the same authorization checks. The guide to AI agent memory design is useful when deciding what belongs in short-term context, persistent memory, or retrieval.

4. A practical tool schema

Use a schema that describes the smallest valid request. For example, a calendar availability tool might accept:

{
  "name": "find_available_times",
  "description": "Find available meeting times for the authenticated user's calendar.",
  "parameters": {
    "type": "object",
    "properties": {
      "start_date": { "type": "string", "description": "ISO date, such as 2026-11-03" },
      "end_date": { "type": "string", "description": "ISO date, inclusive" },
      "duration_minutes": { "type": "integer", "enum": [30, 45, 60] },
      "timezone": { "type": "string" }
    },
    "required": ["start_date", "end_date", "duration_minutes", "timezone"],
    "additionalProperties": false
  }
}

Whether every schema feature is supported depends on the provider and SDK. Confirm supported keywords before deployment, and enforce the same rules in application code. A schema helps the model produce structured arguments; it does not replace runtime validation.

What to double-check

Argument validation

Parse the tool call, verify that the name exists, reject unexpected fields, and validate each value against application rules. Check date order, numeric bounds, allowed identifiers, string length, and encoding. Never construct SQL, shell commands, or URLs by concatenating unchecked model output. Use parameterized queries and allowlists for destinations and operations.

Identity and permissions

Resolve the user and tenant from the authenticated request, not from a model-supplied argument. The model may request an account identifier, but your server must confirm that the current user can access it. Apply least privilege to service credentials and use separate credentials for read-only and write operations where practical.

Confirmation policy

Write down which actions require confirmation. A confirmation should describe the exact action, target, important parameters, and expected consequence. “Proceed?” is weaker than “Send this message to 12 recipients with the subject ‘Renewal reminder’?” Make the user’s approval a separate application event that cannot be inferred from casual conversation.

Retries, timeouts, and duplicate calls

Use bounded retries only for failures that are likely temporary. Read-only requests can often be retried safely; writes require idempotency and careful reconciliation. If a timeout occurs after a write may have reached the provider, query the operation status before trying again. Record a correlation ID across the model request, tool execution, and external API call.

Tool results and prompt injection

Tool output is data, not instructions. A webpage, document, email, or database field may contain text that attempts to redirect the model. Label external content clearly, constrain the next allowed actions, and avoid returning secrets or unnecessary personal data to the model. For document-based workflows, combine tool restrictions with the evaluation practices described in this LLM evaluation guide.

Testing and observability

Test normal requests, missing arguments, malformed values, ambiguous requests, permission failures, timeouts, repeated calls, and conflicting tool results. Measure both task success and safety outcomes: unauthorized attempts blocked, confirmation shown when required, duplicate writes prevented, and useful errors returned. Keep a regression set so a prompt, schema, model, or SDK change does not silently alter behavior.

Common mistakes

Failure mode	Why it happens	Better practice
Malformed parameters	The schema is vague or runtime checks are missing.	Use required fields, narrow enums, strict parsing, and a validation error that the model can understand.
Duplicate calls	The model retries after an unclear response or network timeout.	Use idempotency keys, operation status checks, and a maximum retry count.
Overpowered tools	One generic tool exposes too many capabilities.	Split it into narrow tools with explicit descriptions and separate permissions.
Skipped confirmation	The application treats a tool request as user approval.	Require a distinct confirmation event for consequential actions.
Leaked secrets	Credentials or sensitive API responses are placed in tool output.	Redact results, use scoped credentials, and return only fields needed for the next step.
Unbounded agent loops	There is no step, time, or cost limit.	Set budgets, detect repeated calls, and provide a controlled stop condition.

Another common mistake is testing only the happy path. A workflow that finds the correct record in a demo may still fail when the user lacks access, an API returns partial data, or two tools disagree. Treat tool calling as application integration and test it with the same discipline used for other production endpoints. Related examples of structured workflows appear in this guide to prompt chaining and structured outputs.

When to revisit

Review this checklist whenever a workflow or tool changes, not only when the model changes. Revisit it before seasonal planning cycles if request volume, business rules, calendars, catalogs, or approval policies are likely to change. It is also worth reviewing after an incident, a new integration, a permission change, or a migration to a different provider or SDK.

Before deployment, confirm the following:

Every tool has a narrow purpose, current description, and supported schema.
Runtime validation rejects unknown fields and invalid values.
Authorization is based on the authenticated user and current resource state.
Write operations have idempotency, timeout, retry, and reconciliation behavior.
Confirmation rules are documented and tested with realistic conversations.
Logs contain enough information to debug a call without storing unnecessary sensitive data.
Regression tests cover malformed parameters, duplicate calls, denied access, and unavailable dependencies.
Step, time, and resource limits prevent an agent from running indefinitely.

Keep this list beside the tool registry and update both together. For a wider review of developer platforms and testing options, see the AI developer tools comparison. Reliable LLM app development comes from treating function calling as a permissioned software boundary: the model can propose, but your application must verify, authorize, execute, and explain.