Tool Use in LLMs

Large language models are powerful at understanding and generating text, but a model by itself has important limitations. It may not know current information, cannot automatically access your application's database, and cannot directly perform operations such as sending an email or checking inventory.

Tool use solves this problem by giving an LLM access to controlled external capabilities. The model can decide that a tool is needed, generate the required arguments, and request its execution. The application then runs the tool and provides the result back to the model.

Tool use is a fundamental building block for modern AI applications, including assistants, search systems, coding tools, customer-support systems, and AI agents.

What Is Tool Use in LLMs?

Tool use is the ability of a language model to interact with external functions, APIs, databases, services, or other software capabilities through a structured interface.

The model does not normally execute these tools itself. Instead, it produces a structured request describing which tool should be used and which arguments should be passed. The application is responsible for validating and executing that request.

User request
      ↓
     LLM
      |
      | Tool request
      ↓
 Application
      |
      | Execute
      ↓
 External tool
      |
      | Result
      ↓
 Application
      ↓
     LLM
      ↓
 Final answer

Why Do LLMs Need Tools?

A language model generates responses from the information available to it through its training and current context. Tools extend the system beyond those limitations by providing access to external information and capabilities.

The important distinction is that tools do not magically give the model unrestricted access to the outside world. They provide specific capabilities selected and controlled by the application developer.

Common Types of LLM Tools

Almost any controlled software capability can be exposed as a tool. The most useful tools usually have a narrow purpose and predictable inputs and outputs.

• Web and internal search.
• Database queries.
• External API requests.
• Calculators.
• File retrieval.
• Code execution in a sandbox.
• Calendar operations.
• Email and messaging systems.
• Product and inventory systems.
• Application-specific business functions.

How LLM Tool Use Works

The exact protocol depends on the model provider, but the general workflow is similar across modern AI APIs.

• The application defines the available tools.
• The tool definitions are sent to the model together with the user's request.
• The model determines whether a tool is necessary.
• The model selects a tool and generates its arguments.
• The application receives the tool request.
• The application validates the request.
• The application executes the tool.
• The result is returned to the model.
• The model generates the final answer or requests another tool.

A Simple Tool Example

Imagine an application that provides weather information. The backend contains a function called getWeather that accepts a city name.

async function getWeather(city: string) {
  const response = await fetch(
    `https://example.com/weather?city=${encodeURIComponent(city)}`
  );

  return response.json();
}

The application can expose this function to the model through a tool definition.

{
  "name": "getWeather",
  "description": "Get the current weather for a city",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string"
      }
    },
    "required": ["city"]
  }
}

If the user asks for the weather in London, the model can request something conceptually equivalent to the following tool call.

{
  "name": "getWeather",
  "arguments": {
    "city": "London"
  }
}

The Model Chooses the Tool

When several tools are available, the model can select the one that best matches the user's request. For example, an application could expose searchProducts, getProduct, and checkInventory.

"Find the availability of the laptop with ID 123"

                LLM
                 |
          Selects a tool
                 ↓
          checkInventory
                 |
          { productId: 123 }

The model's ability to select tools based on their descriptions is what makes tool use flexible. The application does not necessarily need a large collection of manually coded intent rules.

Tool Definitions and Schemas

A tool definition describes the interface available to the model. It normally includes a name, description, and schema for its arguments.

• Use a clear and specific name.
• Describe what the tool does.
• Explain important parameters.
• Specify required fields.
• Use appropriate data types.
• Avoid ambiguous parameters.
• Keep the interface as small as practical.

Tool Use and Function Calling

Function calling is one of the most common technical mechanisms for implementing tool use. A function call gives the model a structured way to request a specific application function with arguments.

The terms are sometimes used interchangeably in AI documentation. In practice, tool use is the broader concept, while function calling is a common implementation technique.

Tool Results

After a tool executes, its result is passed back to the model. The model can then use that information to answer the user or determine another action.

{
  "tool": "getWeather",
  "result": {
    "city": "London",
    "temperature": 18,
    "condition": "Cloudy"
  }
}

The model can use the returned information to produce a natural-language response. Importantly, the application should control exactly what information is returned to the model.

Keep Tool Results Focused

Tool results become part of the model's context. Returning unnecessary data increases token usage and can make it harder for the model to identify the relevant information.

For example, a customer lookup tool might need to return an order status but not the customer's complete account record, internal audit information, private identifiers, or unrelated metadata.

• Return only information required for the next step.
• Remove unnecessary sensitive fields.
• Keep large results paginated or summarized.
• Use predictable response structures.
• Validate external API responses before passing them to the model.

Sequential Tool Use

A model may need to use several tools one after another. The result of one operation can provide information required by the next operation.

User request
     ↓
searchProducts()
     ↓
Product ID
     ↓
checkInventory()
     ↓
calculateShipping()
     ↓
Final answer

This pattern allows the model to adapt to intermediate results instead of requiring the developer to hard-code every possible path through the workflow.

Parallel Tool Use

Some tools can be executed independently. When the model requests multiple independent operations, the application may execute them concurrently.

const [weather, exchangeRate] = await Promise.all([
  getWeather("London"),
  getExchangeRate("USD", "EUR"),
]);

Parallel execution can reduce latency, but it is appropriate only when the operations do not depend on one another and can safely run at the same time.

Tool Use for Search

Search is one of the most useful tool categories for LLM applications. A search tool can provide current information or retrieve documents that are not present in the model's original context.

User:
"Find the latest documentation about feature X."

LLM
 ↓
searchDocumentation("feature X")
 ↓
Search results
 ↓
LLM
 ↓
Final answer

Search tools are also commonly used as part of retrieval-augmented generation and AI agents.

Tool Use for Databases

Applications can expose controlled database operations instead of giving the model unrestricted database access. This allows the developer to define exactly what information can be retrieved or modified.

async function getOrderStatus(orderId: string) {
  return database.orders.findUnique({
    where: { id: orderId },
    select: {
      status: true,
      updatedAt: true,
    },
  });
}

This is safer than allowing a model to generate arbitrary SQL because the application controls the query, selected fields, authorization rules, and database operation.

Tool Use for APIs

External APIs allow an LLM application to access services such as weather, maps, payments, shipping, search, analytics, or business systems.

The model does not need to understand the entire external API. The application can expose a small tool with only the parameters and behavior required by the AI workflow.

LLM
 ↓ getShippingQuote({ origin, destination })
Backend
 ├── Authenticate request
 ├── Validate arguments
 ├── Call shipping API
 ↓
Shipping service
 ↓
Backend → LLM

Tool Use for Code Execution

Some AI applications provide a controlled code-execution environment. This can be useful for calculations, data analysis, transformations, and tasks where executing code is more reliable than asking the language model to perform every operation mentally.

Tool Use and AI Agents

Tool use is a fundamental capability of AI agents. An agent can repeatedly select tools, observe their results, and determine what action should happen next.

Goal
 ↓
LLM
 ├── Tool A
 │    ↓
 │  Result
 ↓
LLM
 ↓
Tool B
 ↓
Result
 ↓
Final

A single tool call does not necessarily make an application an agent. Agentic behavior usually involves iterative decision-making, where later actions depend on previous observations.

Tool Use and RAG

Retrieval-augmented generation can also be implemented using tools. Instead of placing an entire knowledge base in the model context, the application can provide a search or retrieval tool that returns relevant information when needed.

This approach can reduce unnecessary context and allows the system to retrieve information dynamically. The retrieval tool can search documents, vector databases, keyword indexes, or hybrid search systems.

Validate Tool Calls

Tool calls generated by a model should always be treated as untrusted input. Even when the tool schema is strict, the backend must independently validate the request before executing it.

function validateArgs(args: unknown) {
  if (!args || typeof args !== "object") {
    throw new Error("Invalid arguments");
  }

  const value = (args as { orderId?: unknown }).orderId;

  if (typeof value !== "string" || !value.trim()) {
    throw new Error("Invalid order ID");
  }

  return value.trim();
}

Runtime validation is necessary because TypeScript types do not validate data received from an external process or model at runtime.

Authorization Must Be Separate

A model can request an operation, but it should never determine whether the user is authorized to perform that operation.

LLM requests tool
        ↓
Validate arguments
        ↓
Check authenticated user
        ↓
Check permissions
        ↓
        ├── Allow → Execute
        └── Deny → Stop

This is especially important for tools that expose private data or perform actions with side effects.

Read Tools vs Action Tools

Not all tools have the same risk level. A tool that retrieves public documentation is very different from a tool that deletes a database record.

Higher-risk tools should have stronger authorization, validation, logging, and often explicit user confirmation.

Prompt Injection and Tool Use

Tool-enabled systems introduce additional security concerns because untrusted content can influence model decisions. For example, a malicious document retrieved by a search tool could contain instructions designed to make the model request another tool.

The application should therefore treat retrieved documents, web pages, user input, and other external content as data rather than trusted instructions. Sensitive tool execution must always pass through independent application-level controls.

Tool Errors

Tools can fail for many reasons: invalid parameters, authentication problems, network errors, service outages, timeouts, rate limits, or application bugs.

A controlled tool error can sometimes be returned to the model so it can choose another approach. The error should not expose secrets, stack traces, internal infrastructure details, or other sensitive information.

Tool Timeouts and Resource Limits

Every external operation should have reasonable resource limits. Otherwise, a slow service or unexpected model behavior can keep an AI request running indefinitely.

• Set network timeouts.
• Limit response sizes.
• Limit the number of tool calls.
• Limit the total agent execution time.
• Set retry limits.
• Control concurrent operations.
• Set spending or token budgets where appropriate.

Avoid Tool Loops

A model can occasionally repeat the same tool call or become stuck between tools. This is particularly relevant in agentic applications.

LLM -> Search -> LLM -> Search -> LLM -> Search -> ...

A maximum number of steps or tool calls prevents this behavior from consuming unlimited resources.

Tool Selection Problems

The model may sometimes choose an inappropriate tool even when the available tools are correctly defined. Tool descriptions, overlapping capabilities, ambiguous names, and excessive numbers of tools can all make selection harder.

• Use distinct tool names.
• Avoid overlapping tool responsibilities.
• Write descriptions around actual use cases.
• Expose only tools relevant to the current workflow.
• Use precise parameter descriptions.
• Test ambiguous user requests.

Too Many Tools Can Hurt Reliability

It can be tempting to expose every application capability to the model. However, a large tool catalog increases the number of possible choices and can make tool selection more difficult.

A better approach is often to expose a small, well-designed set of high-level tools. If an application has hundreds of operations, a separate routing or orchestration layer may be more appropriate than presenting every operation to one model at once.

Designing Effective Tools

• Give each tool one clear responsibility.
• Prefer meaningful high-level operations over unnecessary low-level functions.
• Keep parameters minimal.
• Use strict schemas.
• Return concise results.
• Make errors predictable.
• Document important constraints in the tool description.
• Keep dangerous operations separate from read-only operations.

Tool Use in a Web Application

For a typical web application, tool execution should happen on the server rather than directly in the browser. The browser communicates with the application's backend, and the backend communicates with the AI provider and external services.

Browser
   ↓ User request
Next.js / Backend
   ↓ AI request
LLM provider
   ↓ Tool request
Backend
   ├── Database
   ├── External API
   ├── Internal service
   ↓
LLM provider
   ↓
Browser

Keeping tool execution server-side allows the application to protect API keys, enforce authentication, validate arguments, control permissions, and centralize business logic.

Tool Use and Streaming

Tool use can be combined with streaming responses. The model may stream text or tool-call information, while the application processes tool events and continues the model interaction after the tool has completed.

This requires more complex event handling than ordinary text streaming because the application must distinguish normal generated content from structured tool-call events and manage the additional execution step.

Observability

Tool-enabled applications should record enough information to understand what happened during an execution. A single user request can involve multiple model calls and external operations.

Execution traces are particularly useful. A trace can contain the model decision, selected tool, arguments, validation result, tool response, subsequent decision, and final output.

Testing Tool Use

Tool-enabled systems should be tested at both the model and application levels. It is not enough to test whether the model usually chooses the correct function.

• Test normal requests.
• Test ambiguous requests.
• Test missing arguments.
• Test invalid argument types.
• Test unauthorized users.
• Test unavailable tools.
• Test external service failures.
• Test repeated tool calls.
• Test prompt injection attempts.
• Test high-risk actions.

Common Mistakes

• Allowing the model to execute arbitrary code.
• Trusting model-generated arguments without runtime validation.
• Using the model as an authorization mechanism.
• Exposing secrets through tool results.
• Giving the model unrestricted database access.
• Exposing too many overlapping tools.
• Using vague tool descriptions.
• Returning huge tool results.
• Ignoring tool timeouts.
• Allowing unlimited tool calls.
• Failing to log important tool executions.
• Automatically retrying operations that have side effects.

Best Practices

• Treat model-generated tool calls as untrusted input.
• Execute tools on the server.
• Use explicit tool allowlists.
• Validate every tool name and argument.
• Enforce authorization independently of the model.
• Keep tools focused and predictable.
• Return only necessary data.
• Protect secrets and sensitive information.
• Use timeouts and resource limits.
• Limit the number of tool calls.
• Log and trace important executions.
• Test failure and adversarial scenarios.
• Require confirmation for sensitive actions when appropriate.

Frequently Asked Questions

Conclusion

Tool use allows LLM applications to go beyond text generation by connecting language models to external capabilities. A model can request a search, database operation, API call, calculation, or application action, while the surrounding software remains responsible for executing and controlling that operation.

The basic pattern is straightforward: define tools, provide their schemas to the model, receive a tool request, validate it, execute the operation, return the result, and let the model continue the interaction. Multiple tool calls can then be combined into more complex workflows.

Reliable tool use requires careful engineering. Model output should be treated as untrusted input, authorization must remain outside the model, sensitive tools need additional safeguards, and execution should be protected with validation, timeouts, limits, and monitoring.

Once these foundations are in place, tool use becomes one of the most important building blocks for AI agents and applications that need to interact with real-world data and software systems.