Tools

Purpose and Scope

Tools are the boundary between an LLM-driven LlamaIndex application and actions it can take outside pure text generation. In agent workflows, a tool may be a plain Python function, a wrapper around an external service, a browser or code interpreter capability, or a LlamaIndex query-oriented component exposed for the agent to call. The official agent flow frames tools as part of the loop where an agent receives the latest user input plus chat history, sends tool schemas to the LLM provider, executes selected tool calls, appends results back into the conversation, and repeats until the task is complete.

This page focuses on the repository-backed tool API reference entries supplied for several integrations and on the load-and-search tool pattern in core. It is not a catalog of every tool package in the monorepo. Instead, it explains the shared mental model: a ToolSpec packages one or more callable tools, an agent receives a list of tools, and the tool result becomes context for the next agent step. That model lets you reason about local Python functions, external APIs, browser automation, code interpreters, and retrieval-backed tools using one integration shape.

Sources: docs/api_reference/api_reference/tools/agentql.md, docs/api_reference/api_reference/tools/airweave.md, docs/api_reference/api_reference/tools/artifact_editor.md, docs/api_reference/api_reference/tools/arxiv.md, docs/api_reference/api_reference/tools/aws_bedrock_agentcore.md, docs/api_reference/api_reference/tools/azure_code_interpreter.md, llama-index-core/llama_index/core/tools/tool_spec/load_and_search/README.md

Relevant Source Files

• docs/api_reference/api_reference/tools/agentql.md documents the AgentQL tool reference module and exposes AgentQLBrowserToolSpec plus AgentQLRestAPIToolSpec.
• docs/api_reference/api_reference/tools/airweave.md documents the Airweave tool reference module and exposes AirweaveToolSpec.
• docs/api_reference/api_reference/tools/artifact_editor.md documents the artifact editor tool reference module and exposes ArtifactEditorToolSpec.
• docs/api_reference/api_reference/tools/arxiv.md documents the Arxiv tool reference module and exposes ArxivToolSpec.
• docs/api_reference/api_reference/tools/aws_bedrock_agentcore.md documents Bedrock AgentCore tool surfaces and exposes AgentCoreBrowserToolSpec, AgentCoreCodeInterpreterToolSpec, and AgentCoreRuntime.
• docs/api_reference/api_reference/tools/azure_code_interpreter.md documents the Azure code interpreter tool reference module and exposes AzureCodeInterpreterToolSpec.
• llama-index-core/llama_index/core/tools/tool_spec/load_and_search/README.md explains the core LoadAndSearchToolSpec wrapper, including its loader and reader split for large tool outputs.

Core Primitives

The most important primitive is the tool itself: a callable capability with a name, description, and input schema that an agent can present to an LLM. In a simple workflow, you can pass ordinary Python functions directly to a FunctionAgent, provided the function signature and docstring are descriptive enough for tool calling. A ToolSpec is the next level of structure. It groups related capabilities from a package or service and usually provides a method such as to_tool_list() so the agent receives concrete callable tools rather than the spec object itself.

A ToolSpec should be read as an adapter between LlamaIndex and a domain-specific capability. The supplied API reference pages show this naming convention clearly: ArxivToolSpec adapts Arxiv-oriented functionality, ArtifactEditorToolSpec adapts artifact editing behavior, and AirweaveToolSpec adapts Airweave-backed behavior. AgentQL has separate browser and REST API specs, which signals that tool packages can expose more than one operational mode when the same service supports different interaction styles. Bedrock AgentCore likewise separates browser, code interpreter, and runtime surfaces.

Sources: docs/api_reference/api_reference/tools/agentql.md, docs/api_reference/api_reference/tools/airweave.md, docs/api_reference/api_reference/tools/artifact_editor.md, docs/api_reference/api_reference/tools/arxiv.md, docs/api_reference/api_reference/tools/aws_bedrock_agentcore.md

How Agents Call Tools

A tool-enabled agent operates as a controlled loop rather than a single prompt. The agent starts with the user message and any memory or chat history. It sends the available tool schemas along with that context to the LLM. The model can either answer directly or return one or more tool calls. When tool calls are returned, the runtime executes the corresponding functions, records their outputs in the conversation, and invokes the model again with the updated history. This lets the LLM decompose a task into observations and decisions without giving it unrestricted execution authority.

For developers, the practical consequence is that tool design is prompt design and API design at the same time. Names should be specific, descriptions should explain when the tool is useful, and function inputs should be narrow enough for the model to fill reliably. A browser tool, code interpreter tool, and search tool may all be available in the same agent, but each should communicate a distinct purpose. The API reference entries in this area are therefore best read alongside agent configuration: they identify the concrete ToolSpec classes you can add to an agent, while the agent controls when and how they are invoked.

Sources: docs/api_reference/api_reference/tools/agentql.md, docs/api_reference/api_reference/tools/aws_bedrock_agentcore.md, docs/api_reference/api_reference/tools/azure_code_interpreter.md, llama-index-core/llama_index/core/tools/tool_spec/load_and_search/README.md

Load-and-Search Tool Pattern

LoadAndSearchToolSpec is a core wrapper for tools that return too much information to fit comfortably in the model context. Instead of asking the agent to consume a large raw tool result directly, the wrapper splits the capability into two tools: load, which calls the wrapped function and loads the returned data into an index, and read, which searches that index for a specific query. This pattern converts a bulky one-shot tool output into a retrieval workflow that the agent can use incrementally.

The README example wraps a Wikipedia tool selected from WikipediaToolSpec().to_tool_list(), then passes LoadAndSearchToolSpec.from_defaults(tool).to_tool_list() into a FunctionAgent configured with an OpenAI LLM. The important design idea is not specific to Wikipedia. Any tool that returns long documents, large search results, or content near the context-window limit can be made more agent-friendly by first loading the content, then querying only the relevant portions. This keeps the agent loop focused on task-relevant evidence rather than raw payload management.

from llama_index.core.tools.tool_spec.load_and_search import LoadAndSearchToolSpec
from llama_index.core.agent.workflow import FunctionAgent
from llama_index.tools.wikipedia.base import WikipediaToolSpec
from llama_index.llms.openai import OpenAI
 
wiki_spec = WikipediaToolSpec()
tool = wiki_spec.to_tool_list()[1]
 
agent = FunctionAgent(
    tools=LoadAndSearchToolSpec.from_defaults(tool).to_tool_list(),
    llm=OpenAI(model="gpt-4.1"),
)
 
await agent.run("who is ben affleck married to")

Sources: llama-index-core/llama_index/core/tools/tool_spec/load_and_search/README.md

API Components

The supplied tool API reference pages are generated documentation entrypoints for integration packages under llama_index.tools.*. They identify the public classes that users should import from those packages and add to agent workflows. In compact form, the visible exported members are:

This reference shape is useful when selecting an integration. If your agent needs scholarly paper lookup, start with ArxivToolSpec. If it needs browser-style extraction through AgentQL, compare AgentQLBrowserToolSpec with AgentQLRestAPIToolSpec. If it needs code execution, the Azure and Bedrock code interpreter specs indicate provider-specific implementations of that capability. If it needs a more complete Bedrock AgentCore environment, the presence of AgentCoreRuntime alongside ToolSpec classes suggests that runtime management is part of that integration’s public surface.

Sources: docs/api_reference/api_reference/tools/agentql.md, docs/api_reference/api_reference/tools/airweave.md, docs/api_reference/api_reference/tools/artifact_editor.md, docs/api_reference/api_reference/tools/arxiv.md, docs/api_reference/api_reference/tools/aws_bedrock_agentcore.md, docs/api_reference/api_reference/tools/azure_code_interpreter.md

Implementation Guidance

Choose the smallest tool surface that gives the agent the action it needs. A single Python function is appropriate for deterministic application logic such as arithmetic, formatting, or internal lookups. A ToolSpec is appropriate when the capability belongs to an integration package, requires setup, or exposes several related operations. A load-and-search wrapper is appropriate when the problem is not calling the service but managing the volume of data returned by the service. Separating those cases makes agents easier to observe, test, and constrain.

When wiring tools into an agent, start by verifying the tool list before adding complex prompts or multi-agent orchestration. Check that each generated tool has an understandable purpose, that required credentials or provider configuration are available, and that failure cases return information the agent can use. For context-heavy tools, prefer the loader-reader split early; it is easier to design retrieval-friendly outputs than to retrofit a long raw response after the agent starts exceeding context limits or hallucinating over irrelevant content.

Next Steps

After understanding tools, read the agents overview and agent configuration pages to see how tools interact with LLMs, memory, prompts, and workflow-compatible agent classes. Then move to MCP tools if you need to connect agents to external Model Context Protocol servers, or to query engines if the tool you want to expose is a retrieval interface over an index. For large outputs, keep LoadAndSearchToolSpec in mind as the bridge between arbitrary tool execution and RAG-style indexed reading.