Tools

Tools are capabilities exposed to an LLM that let it request actions beyond text generation (e.g., query a system, read/write data, run code) and receive results back as context. A tool call is typically structured (tool name plus arguments). Tools differ in who defines them and who executes them.

Details

Types of tools

Function tools are defined by the application developer: the developer specifies a name, description, and parameter schema, then passes these to the model at inference time. When the model generates a structured output containing the selected function name and a JSON arguments payload, the developer's code (typically an agent runtime) parses this output, executes the corresponding function, and feeds the result back into the model's context for the next turn. The model relies on its general tool-calling ability combined with the in-context schema description; it has no built-in knowledge of any specific function tool.

Provider APIs typically offer controls such as parallel function calls (multiple invocations in a single turn), forced calls (constraining the model to call a specific function), and streaming of partial function-call arguments.

Provider-defined tools have schemas and interfaces standardized by an inference provider or model developer, but are executed by the developer's code. The model is specifically trained on these tool interfaces, so it has built-in knowledge of their semantics and expected input/output formats. The developer opts in to enabling them and handles execution in their own environment (e.g., a local sandbox).

Provider-executed tools are both defined and executed by the inference provider. The developer enables them via the API, but execution happens server-side during inference; the model's tool calls and resulting outputs are handled entirely within the provider's infrastructure before the response is returned. The model is specifically trained on these tools.

All three types rely on tool-calling ability learned during training (fine-tuning on structured tool-call formats). Function tools depend only on this general ability plus the schema provided at inference time (which consumes context), while provider-defined and provider-executed tools also involve targeted training on each tool's specific semantics. An agent runtime or client typically orchestrates the call-and-return loop between model and tools.

Common tools

• Web search tools
• Code execution tools
• Computer use tools
• Shell tools
• Retrieval tools in agentic RAG

MCP standardizes how agents discover and connect to external tool providers, decoupling function-tool implementation from the agent.

Because tools bridge the gap between model outputs and real-world actions, they are a primary attack surface for threats such as tool misuse (authorized but harmful tool calls), unauthorized code execution (code injection through execution tools), data exfiltration (data extraction via tool calls), and supply chain attack (malicious or backdoored tool integrations). Tool execution approval is a common mitigation that requires human confirmation before high-risk tool calls are executed.

Examples

• Function tools: a developer-defined get_weather(city) or query_database(sql) tool
• Provider-defined tools (developer-executed): Anthropic's computer use, bash/shell, and text editor tools
• Provider-executed tools: OpenAI web search, code interpreter, and file search; Google's grounding with search

Synonyms

tool use, tool calling, function calling, action