- Connecting models to live data (databases, calendars, internal APIs) without prompt hacks.
- Agents that take actions on behalf of users: create tickets, send emails, run queries.
- Multi-step workflows where the model decides which tools to invoke and in what order.
- Replacing brittle regex parsing with structured function calls for data extraction.
Quick Start
Enable AI models to call external functions with structured parameters.Configuration
Tool Definition
Responses API (/v3/router/responses): flat shape:
| Parameter | Type | Required | Description |
|---|---|---|---|
type | "function" | Yes | Tool type |
name | string | Yes | Function identifier |
description | string | Yes | What the function does |
parameters | object | Yes | JSON Schema for parameters |
/v3/router/chat/completions): nested function wrapper:
| Parameter | Type | Required | Description |
|---|---|---|---|
type | "function" | Yes | Tool type |
function.name | string | Yes | Function identifier |
function.description | string | Yes | What the function does |
function.parameters | object | Yes | JSON Schema for parameters |
Tool Choice Options
| Value | Behavior |
|---|---|
"auto" | Model decides when to use tools |
"none" | Disable tool usage |
"required" | Force tool usage |
{type: "function", function: {name: "tool_name"}} | Force specific tool |
Tool Message Format
This format applies to the Chat Completions endpoint (
/v3/router/chat/completions). On the Responses API, tool results use type: "function_call_output", call_id, and output instead.tool role:
| Parameter | Type | Required | Description |
|---|---|---|---|
role | "tool" | Yes | Message role for tool results |
tool_call_id | string | null | Yes | ID of the tool call being responded to |
content | string | Yes | JSON-stringified result of the tool execution |
The
tool_call_id can be null in certain scenarios, such as when tool results are being provided without a corresponding tool call from the model, or when working with providers that don’t require tool call IDs.Code examples
Function Execution Patterns
Basic Tool Handler
Parallel Tool Execution
Advanced Use Cases
Database Integration
API Integration
Multi-Steps Workflows
Error Handling
Best Practices
Tool design
- Use clear, descriptive function names.
- Provide detailed parameter descriptions.
- Include examples in descriptions.
- Make tools idempotent when possible.
Schema design
Security considerations
- Never expose destructive operations directly.
- Validate all inputs thoroughly.
- Use allowlists for sensitive operations.
- Implement proper authentication.
- Log all tool executions.
Troubleshooting
Tool not being called- Check tool descriptions are clear.
- Verify parameter schemas are correct.
- Ensure tool_choice is set appropriately.
- Try more explicit prompts. Invalid arguments
- Validate JSON Schema thoroughly.
- Add parameter examples.
- Check required fields are marked.
- Simplify complex parameter structures.
- Implement proper error handling.
- Add timeout protection.
- Validate inputs before execution.
- Return structured error messages.
Limitations
| Limitation | Impact | Workaround |
|---|---|---|
| Tool limit | Max ~20 tools per request | Group related functions |
| Parameter size | Large schemas may fail | Simplify parameter structure |
| Execution time | Tools block response | Use async patterns |
| Error propagation | Failures can break workflow | Implement error recovery |
| Model differences | Varying tool calling quality | Test across models |