Tools

Use web search, function calling, deferred tool loading, and route-supported hosted tools to extend model capabilities.

When generating model responses, you can extend model capabilities with tools. The most portable AvalAI pattern is to use /v1/responses with web_search for public current context and custom function tools for your own data, side effects, and approval flows. Other hosted tool families such as file search, computer use, remote MCP, shell, code interpreter, image-generation tools, and tool_search are model- and route-dependent; when a hosted tool is unavailable, wrap the capability in your application and return results through function calling.

The example below uses the web search tool to retrieve current public-web context for a model response.

Include web search results for the model response

Bash

curl https://api.avalai.ir/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $AVALAI_API_KEY" \
  -d '{
"model": "gpt-5.5",
"tools": [{"type": "web_search"}],
"input": "what was a positive news story from today?"
}'

JavaScript

import { OpenAI } from "openai";

const client = new OpenAI({
  apiKey: process.env.AVALAI_API_KEY,

  baseURL: "https://api.avalai.ir/v1",
});

const response = await client.responses.create({
  model: "gpt-5.5",

  tools: [{ type: "web_search" }],

  input: "What was a positive news story from today?",
});

console.log(response.output_text);

Python

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["AVALAI_API_KEY"],
    base_url="https://api.avalai.ir/v1",
)

response = client.responses.create(
    model="gpt-5.5",
    tools=[{"type": "web_search"}],
    input="What was a positive news story from today?",
)

print(response.output_text)

Go

package main

import (
	"bytes"
	"encoding/json"
	"fmt"
	"io"
	"net/http"
	"os"
)

func main() {
	payload := map[string]any{
		"model": "gpt-5.5",
		"tools": []map[string]string{{"type": "web_search"}},
		"input": "What was a positive news story from today?",
	}

	body, err := json.Marshal(payload)
	if err != nil {
		panic(err)
	}

	req, err := http.NewRequest("POST", "https://api.avalai.ir/v1/responses", bytes.NewBuffer(body))
	if err != nil {
		panic(err)
	}
	req.Header.Set("Authorization", "Bearer "+os.Getenv("AVALAI_API_KEY"))
	req.Header.Set("Content-Type", "application/json")

	resp, err := http.DefaultClient.Do(req)
	if err != nil {
		panic(err)
	}
	defer resp.Body.Close()

	responseBody, err := io.ReadAll(resp.Body)
	if err != nil {
		panic(err)
	}

	fmt.Println(string(responseBody))
}

PHP

<?php

$apiKey = getenv('AVALAI_API_KEY');
$payload = [
    'model' => 'gpt-5.5',
    'tools' => [['type' => 'web_search']],
    'input' => 'What was a positive news story from today?',
];

$ch = curl_init('https://api.avalai.ir/v1/responses');
curl_setopt_array($ch, [
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_POST => true,
    CURLOPT_HTTPHEADER => [
        'Authorization: Bearer ' . $apiKey,
        'Content-Type: application/json',
    ],
    CURLOPT_POSTFIELDS => json_encode($payload),
]);

$response = curl_exec($ch);
curl_close($ch);

echo $response;
?>

Available tools

Here's an overview of the tools available through AvalAI's unified API—select one of them for further guidance on usage.

Warning

Availability depends on the selected model and route. Use /v1/responses with web_search and custom function tools for production tool workflows today. Hosted File Search, Computer Use, remote MCP, shell, code-interpreter, and OpenAI skill bundles are availability-dependent in AvalAI; where a hosted tool is not enabled, wrap the capability in your application and expose it as a function tool.

Tool family	OpenAI-compatible shape	AvalAI guidance
Web search	tools: [{"type": "web_search"}]	Best default for current public-web context through /v1/responses.
Function calling	tools: [{"type": "function", ...}]	Use for private data, side effects, approvals, and integrations you own.
File search	tools: [{"type": "file_search", ...}]	Hosted vector stores are under development; use app-side RAG with embeddings today.
Computer use / shell / code interpreter	Hosted tool objects	Treat as availability-dependent; use function tools or your own sandbox/runtime unless AvalAI announces support for the selected model.
Tool search	tools: [{"type": "tool_search"}]	OpenAI documents this for gpt-5.4 and later; verify AvalAI/model support before relying on deferred tool loading.
Image generation tool	tools: [{"type": "image_generation"}] or image endpoints	Prefer AvalAI image endpoints for production image workflows unless the selected Responses route explicitly supports image-generation tools; see the image migration path.
Shell / skills / code interpreter	Hosted runtime tools	Treat as OpenAI-hosted runtime features; use your own sandbox plus function tools unless AvalAI enables the hosted runtime for the selected model.
Remote MCP / connectors	tools: [{"type": "mcp", ...}]	Use only when the route supports it and the server, connector, OAuth scopes, and approval policy are trusted.

Choosing a tool surface

Use the smallest surface that gives the model the capability it needs:

• Public current context: use web_search on /v1/responses, then inspect web_search_call items when your app needs sources or query metadata.
• Private data or side effects: keep the integration in your application and expose a narrow function tool with strict JSON Schema.
• Large private knowledge bases: use app-side RAG with embeddings today; move to hosted file_search only after the selected AvalAI route supports vector stores.
• Many related actions: group tools by domain in a namespace, keep each namespace focused, and consider tool_search only after confirming model support.
• Third-party services: prefer official remote MCP servers or connectors, restrict imported tools with allowed_tools, and require approval for writes or sensitive reads.
• Hosted runtimes: treat shell, code interpreter, skill bundles, and computer-use tools as route-dependent; if unavailable, run the runtime yourself and return results through function_call_output.

GPT Actions vs AvalAI function tools

OpenAI GPT Actions are a ChatGPT/Custom GPT surface: a builder attaches OpenAPI-described REST endpoints, authentication, and instructions to a GPT, and ChatGPT converts natural language into the JSON payload for those endpoints. In AvalAI, do not document GPT Actions as an API route. Use the same design discipline with /v1/responses function tools or trusted MCP servers:

GPT Actions concept	AvalAI implementation
OpenAPI operation schema	JSON Schema on a function tool, or a small MCP server with explicit tool schemas.
Data retrieval action	Read-only backend function such as lookup_order, search_docs, or get_forecast.
Consequential action	Write or purchase function that always requires app-side approval before execution.
OAuth/API-key action auth	Keep credentials in your backend; never put bearer tokens or refresh tokens in model-visible prompts.
Action response	Return compact raw JSON for the model to summarize, rather than prewritten natural-language prose.

Authentication mapping for Actions-style ports

OpenAI Actions support None, API key, and OAuth authentication in the ChatGPT builder. When you port that design to AvalAI, move the auth decision into your backend and expose only the safe tool shape to the model:

• No auth: use only for public, read-only data where anonymous traffic is acceptable. Add rate limits and abuse monitoring before exposing it through a model.
• API key: keep provider or service keys server-side. The model should call a function such as lookup_shipping_rate; your backend attaches the API key after validating arguments.
• OAuth: complete the user sign-in flow in your app, store refresh tokens in your secret store, and pass only the short-lived access token to the downstream service. For MCP connector-style tools, send the access token through the documented authorization field on each request.
• State and redirect safety: if you reuse an Actions-style OAuth design, preserve the OAuth state check, register the exact redirect URLs for the surface you operate, and log auth failures without exposing secrets to the model.
• Signed-out to signed-in upgrade: keep unauthenticated discovery separate from personalized or write-capable actions. For example, expose search_public_docs without auth, but require sign-in and approval for create_ticket or send_email.

When porting an Actions-style integration to AvalAI, keep endpoints narrow, descriptions short and literal, validate arguments before network calls, handle 429 and 5xx with backoff, and make long-running work asynchronous. OpenAI Actions production notes also assume public HTTPS/TLS endpoints, a roughly 45-second action timeout, text-only request/response payloads, and payload sizes below 100,000 characters; for AvalAI function tools, use those limits as conservative design guardrails even when your own backend could accept more.

Code interpreter and hosted-runtime fallback

OpenAI's hosted Code Interpreter lets a model write and run Python in an ephemeral sandbox, attach input files, and return generated files as annotations. In AvalAI, use that hosted shape only after the selected /v1/responses route explicitly supports tools: [{"type": "code_interpreter", ...}]. Otherwise, expose your own runtime as a custom function tool:

• Keep execution server-side in a locked-down container; do not expose raw shell or arbitrary network access to the model.
• Define a narrow function such as run_python_analysis with explicit inputs for code, allowed files, time limit, and expected artifact type.
• Validate code and arguments before execution, enforce CPU/memory/time/file limits, and make retries idempotent.
• Persist uploaded files and generated artifacts in your own storage; return stable URLs, file IDs, summaries, stdout, and stderr through function_call_output.
• Treat generated charts, CSVs, and notebooks as untrusted output until your application scans, signs, or approves them.
• If the OpenAI-style hosted container becomes available for your route later, keep the same artifact and approval policy; only swap the runtime implementation.

Standard Tools

Web search Include data from the Internet in model response generation.

File search Search the contents of uploaded files for context when generating a response.

Computer use Create agentic workflows that enable a model to control a computer interface.

Function calling Enable the model to call custom code that you define, giving it access to additional data and capabilities.

Code Interpreter Run Python in a hosted sandbox when the selected /v1/responses route supports it, or use an app-managed Python function fallback.

Shell Run non-interactive terminal commands in a hosted container when enabled, or through your own locked-down shell runtime.

MCP and Connectors Connect to remote MCP servers or connector-style SaaS tools with OAuth, allowed_tools, approvals, and strict trust boundaries.

Google/Gemini Specific Tools

Gemini models (particularly gemini-3.5-flash, gemini-3.1-pro-preview, gemini-3.1-flash-lite, gemini-2.5-pro, and gemini-2.5-flash) support several specialized tools:

[Code Execution] Allows Gemini to use code to solve complex tasks. When this tool is enabled, no other tools can be used simultaneously.

# Example: Code execution with Gemini
response = client.chat.completions.create(
    model="gemini-3.1-pro-preview",
    messages=[{"role": "user", "content": "Calculate the first 10 Fibonacci numbers"}],
    tools=[
        {"codeExecution": {}},
    ],
)

Responses API migration path for this example

codeExecution is a Gemini-specific Chat Completions tool shape. Do not migrate it by inventing an unrelated function tool. For lightweight calculations, use /v1/responses directly with a Responses-capable model. If you need a sandboxed code runtime, keep the Gemini Chat example until the target Responses model and AvalAI tool support expose an equivalent hosted code tool.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["AVALAI_API_KEY"],
    base_url="https://api.avalai.ir/v1",
)

response = client.responses.create(
    model="gpt-5.5",
    instructions="Show concise working when calculation helps verify the answer.",
    input="Calculate the first 10 Fibonacci numbers.",
)

print(response.output_text)

Migration notes:

• messages → input for the user request.
• Gemini tools=[{"codeExecution": {}}] has no direct Responses equivalent in this AvalAI example.
• For Responses tools, use documented tool objects such as web_search, file_search, computer, or custom function tools when the selected model supports them. Keep computer_use_preview only for legacy preview integrations that still depend on the older model.
• Inspect response.output by item type when tools run; use response.output_text for the final text.

[Google Search] Enables Gemini models to retrieve up-to-date information using Google Search. This tool can only be used in combination with the urlContext tool.

# Example: Google Search with Gemini
response = client.chat.completions.create(
    model="gemini-3.1-pro-preview",
    messages=[
        {
            "role": "user",
            "content": "What are the latest developments in quantum computing?",
        }
    ],
    tools=[
        {"googleSearch": {}},
    ],
)

Responses API migration path for this example

googleSearch is a Gemini-specific Chat Completions tool shape. In /v1/responses, use the AvalAI/OpenAI-compatible web_search tool with a Responses-capable model instead of carrying over the Gemini tool object.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["AVALAI_API_KEY"],
    base_url="https://api.avalai.ir/v1",
)

response = client.responses.create(
    model="gpt-5.5",
    input="What are the latest developments in quantum computing? Cite sources.",
    tools=[{"type": "web_search", "search_context_size": "medium"}],
)

print(response.output_text)

Migration notes:

• messages → input.
• Gemini tools=[{"googleSearch": {}}] → Responses tools=[{"type": "web_search"}] when the selected model supports web search.
• Add include=["web_search_call.action.sources"] when your UI needs structured source metadata in addition to text citations.
• Inspect response.output for web_search_call items and final message items.

[URL Context] This experimental feature allows Gemini models to read and use URLs as context. The model looks for URLs in the user content and reads them, resulting in increased input token consumption.

# Example: URL Context with Gemini (can be combined with Google Search)
response = client.chat.completions.create(
    model="gemini-3.1-pro-preview",
    messages=[
        {
            "role": "user",
            "content": "Summarize this article: https://example.com/article",
        }
    ],
    tools=[
        {"urlContext": {}},
    ],
)

Responses API migration path for this example

urlContext is a Gemini-specific Chat Completions tool shape. In /v1/responses, either fetch the URL in your application and pass the extracted text as input, or pair the prompt with web_search when the model should retrieve current public web context.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["AVALAI_API_KEY"],
    base_url="https://api.avalai.ir/v1",
)

response = client.responses.create(
    model="gpt-5.5",
    input="Summarize this article if it is publicly accessible: https://example.com/article",
    tools=[{"type": "web_search", "search_context_size": "medium"}],
)

print(response.output_text)

Migration notes:

• messages → input.
• Gemini tools=[{"urlContext": {}}] has no same-name Responses tool object.
• For deterministic production summaries, fetch and sanitize the page server-side, then pass the extracted content to input.
• Use web_search when freshness and public web retrieval matter more than deterministic ingestion.

Note

Tool compatibility restrictions for Gemini models:

• When code execution is enabled, no other tools can be used
• Function declarations can only be used alone
• Google Search can only be combined with URL Context

Alibaba/DashScope Specific Tools

Alibaba's Qwen models (including qwen3.7-max, qwen3.7-plus, qwen3.6-plus, qwen3.6-flash, and legacy qwen3-max snapshots) support web search through the DashScope platform:

[Web Search (enable_search)] Enables Qwen models to retrieve up-to-date information from the web. Unlike other providers, Alibaba uses the enable_search parameter instead of the tools array.

# Example: Web Search with Alibaba Qwen3.7 Max
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["AVALAI_API_KEY"], base_url="https://api.avalai.ir/v1"
)

response = client.chat.completions.create(
    model="qwen3.7-max",
    messages=[
        {"role": "user", "content": "What is the current stock price of Alibaba?"}
    ],
    extra_body={"enable_search": True, "search_options": {"search_strategy": "agent"}},
)

print(response.choices[0].message.content)

Responses API migration path for this example

extra_body={"enable_search": true} is a DashScope/Qwen Chat Completions extension. Do not copy that provider-specific parameter into /v1/responses. For a Responses-first implementation, use the standard web_search tool with a Responses-capable model.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["AVALAI_API_KEY"],
    base_url="https://api.avalai.ir/v1",
)

response = client.responses.create(
    model="gpt-5.5",
    input="What is the current stock price of Alibaba? Cite sources and include the timestamp you found.",
    tools=[{"type": "web_search", "search_context_size": "medium"}],
)

print(response.output_text)

Migration notes:

• messages → input.
• DashScope extra_body.enable_search → Responses tools=[{"type": "web_search"}] for Responses-capable models.
• Keep the Chat Completions example when you specifically need Qwen/DashScope enable_search behavior.
• Inspect response.output for web_search_call items and final message items.

Note

For Alibaba web search:

• Current Qwen3.7 and Qwen3.6 models such as qwen3.7-max, qwen3.7-plus, qwen3.6-plus, and qwen3.6-flash support web search; legacy qwen3-max snapshots may also support it depending on availability
• The search_strategy must be set to "agent" for international regions
• Web search results are added to the prompt, increasing input tokens

Tool Pricing

Each tool has its own separate pricing in addition to the base API model pricing for input/output tokens. The tokens used for built-in tools are billed at the chosen model's per-token rates, plus additional costs specific to each tool:

Tool	Cost
Code Interpreter	$0.03 per session
File Search Storage	$0.10 GB/day (1GB free)
File Search Tool Call (Responses API only*)	$2.50 per 1k calls (*Does not apply on Assistants API)
Web Search	Web search tool pricing is inclusive of tokens used to synthesize information from the web. Pricing depends on model and search context size.

Web Search Pricing

Model	Search context size	Cost
gpt-5.5 / gpt-5.4 / gpt-5.4-pro	low	$30.00 per 1k calls
	medium (default)	$35.00 per 1k calls
	high	$50.00 per 1k calls
gpt-5.4-mini / gpt-5.4-nano	low	$25.00 per 1k calls
	medium (default)	$27.50 per 1k calls
	high	$30.00 per 1k calls
qwen3.7-max / qwen3.7-plus / qwen3.6-flash (Alibaba)	agent	$10.00 per 1k calls

For complete pricing information, please refer to the Pricing page.

Usage in the API

When making a request to generate a model response, you can enable tool access by specifying configurations in the tools parameter. Each tool has its own unique configuration requirements—see the Available tools section for detailed instructions.

Based on the provided prompt, the model automatically decides whether to use a configured tool. For instance, if your prompt requests information beyond the model's training cutoff date and web search is enabled, the model will typically invoke the web search tool to retrieve relevant, up-to-date information.

You can explicitly control or guide this behavior by setting the tool_choice parameter in the API request.

Responses tool-loop item model

/v1/responses returns a typed output array instead of a single Chat Completions message. Treat each item as part of the tool loop and preserve the items your next request depends on.

Output item	What it means	What your app should do
message	Final or intermediate assistant content	Render the text, or keep it when replaying state manually.
reasoning	Hidden or summarized reasoning state from reasoning models	Keep it with subsequent tool outputs when the route returns it; dropping it can reduce reliability.
web_search_call	The model used hosted web search	Inspect query/action/source metadata when your UI needs auditability; otherwise read the final message or output_text.
function_call	The model wants your application to run a custom function	Parse arguments, execute trusted code, then send a matching function_call_output with the same call_id.
function_call_output	Your application's result for a previous function call	Include it in the next Responses request so the model can finish the answer.
tool_search_call / tool_search_output	Deferred tools were searched and loaded	In hosted mode, inspect loaded tools; in client mode, return tool_search_output yourself before expecting function calls.
mcp_list_tools / mcp_call	A remote MCP server listed tools or ran one	Cache/validate listed tools, require approval for sensitive actions, and treat outputs as third-party data.
image_generation_call	A hosted image-generation tool ran	Prefer AvalAI image endpoints unless your selected Responses route explicitly supports this item.

If you use previous_response_id, AvalAI/OpenAI-compatible state can carry much of this forward for supported routes. If you replay state yourself, append the previous typed items plus new tool outputs in order.

Tool design checklist

OpenAI-compatible tool requests can mix built-in tools and your own function tools, but every tool definition is part of the model input. Keep the initial tool surface small, use clear names and parameter descriptions, and avoid asking the model for arguments your application already knows.

• Use tool_choice: "auto" for normal routing, "required" when at least one tool must run, and "none" when you want a text-only answer.
• Use parallel_tool_calls: false when tools mutate state, require approval, or must run in a strict sequence.
• Use max_tool_calls on routes that support it to cap hosted built-in-tool work. Treat it as a total cap across built-in tool calls, not a separate limit per tool.
• Request optional tool details with include only when your UI, audit log, or debugger needs them, such as web_search_call.action.sources, code_interpreter_call.outputs, file_search_call.results, or computer-output image URLs.
• For many custom functions, expose the likely tools first; use tool_search only after confirming the selected AvalAI model supports deferred loading.
• Use namespaced tools for large domains such as CRM, billing, or document operations; prefer fewer than 10 functions per namespace when possible.
• If tools are discovered outside the normal tools array, add them with an additional_tools input item and preserve its position when replaying conversation state.
• Treat hosted OpenAI-only tools such as remote MCP, shell, or code-interpreter style runtimes as availability-dependent. When they are not exposed through your selected AvalAI model, wrap the capability in your own function tool instead.
• Inspect typed Responses output items such as tool_search_call, tool_search_output, web_search_call, function_call, mcp_list_tools, mcp_call, image_generation_call, and message; use output_text only when your app needs the final text.

Deferred tool loading with tool_search

OpenAI's tool-search pattern lets large applications group functions into namespaces and mark rarely used functions with defer_loading. This keeps the initial prompt smaller while still letting the model load the right tool later. In AvalAI, use this only after confirming the selected model and route expose tool_search; otherwise, keep the same grouping in your backend and send only the likely functions for that turn.

Tool search has two operating styles:

• Hosted search: declare the full inventory in the request, add {"type": "tool_search"}, and let the API load the relevant deferred tools. This is best when the candidate tools are already known.
• Client-executed search: configure tool_search with execution: "client"; the model emits a tool_search_call, your app searches its own registry, then returns tool_search_output with the loaded tools. This is better for tenant-specific or project-specific tool catalogs.

For namespaces, defer_loading belongs on the functions inside the namespace, not on the namespace itself. Keep namespace names and descriptions short and clear, and keep each namespace small enough that the model can choose it confidently.

Production notes:

• OpenAI documents tool_search for gpt-5.4 and later. In AvalAI, still verify the exact /v1/responses route and model before deploying it.
• Prefer namespaces or MCP servers over many standalone deferred functions. With a namespace, the model initially sees only the namespace name and description; with an individual deferred function, it still sees the function name and description and mostly defers the parameter schema.
• Loaded tools are injected near the end of the model context to preserve prompt cache. Avoid changing the loaded tool set mid-conversation unless you intentionally want to invalidate that cache path.
• In hosted mode, tool_search_call / tool_search_output use execution: "server" and call_id: null. In client-executed mode, echo the exact tool_search_call.call_id in your tool_search_output.
• If your application loads tools outside normal tool search, use an additional_tools input item at the correct conversation point and preserve that item position when replaying state.

{
  "model": "gpt-5.5",
  "input": "List open orders for customer CUST-12345.",
  "tools": [
    {
      "type": "namespace",
      "name": "crm",
      "description": "CRM tools for customer lookup and order management.",
      "tools": [
        {
          "type": "function",
          "name": "get_customer_profile",
          "description": "Fetch a customer profile by customer ID.",
          "parameters": {
            "type": "object",
            "properties": {
              "customer_id": {
                "type": "string"
              }
            },
            "required": [
              "customer_id"
            ],
            "additionalProperties": false
          },
          "strict": true
        },
        {
          "type": "function",
          "name": "list_open_orders",
          "description": "List open orders for a customer ID.",
          "defer_loading": true,
          "parameters": {
            "type": "object",
            "properties": {
              "customer_id": {
                "type": "string"
              }
            },
            "required": [
              "customer_id"
            ],
            "additionalProperties": false
          },
          "strict": true
        }
      ]
    },
    {
      "type": "tool_search"
    }
  ],
  "parallel_tool_calls": false
}

Remote MCP and connector safety

Remote MCP servers and OpenAI-hosted connectors are powerful because they can expose third-party tools, data, and actions directly to the model. In AvalAI, treat these surfaces as model- and route-dependent: if type: "mcp" or a hosted connector is not enabled for your selected model, keep the integration in your own backend and expose only the safe operation as a custom function tool.

When remote MCP or connector access is enabled:

• Connect only to trusted servers, preferably official servers operated by the service provider itself.
• Use least-privilege OAuth or API tokens, store them outside prompts, and rotate them like any other production secret.
• Send OAuth authorization values on each request that needs them; do not assume hosted Responses state will store secret tokens for later turns.
• Limit the imported surface with allowed_tools; do not expose every server tool when the workflow needs only one or two actions.
• Require approval for sensitive actions such as payments, account changes, data deletion, email sends, or writes to external systems. Continue approved calls with previous_response_id or by replaying the previous typed output items.
• Review and log the data sent to third-party MCP servers, especially when prompts include user-provided or retrieved content.
• Validate domains before embedding URLs or images returned by MCP tools, because tool outputs can contain untrusted links.
• Preserve mcp_list_tools output items in state where the route supports them to avoid re-listing tools on every turn; otherwise cache and validate tool definitions in your application layer.

For request shapes, connector OAuth notes, approval handling, and a function-tool fallback, see MCP and Connectors.

Agents SDK and app-managed agents

OpenAI's tools guide maps the same tool concepts into the Agents SDK: attach hosted tools or function tools to a specialist agent, or expose a specialist agent as a callable tool for a manager agent. In AvalAI docs, treat this as an orchestration pattern rather than a separate hosted capability. Use it when your runtime and SDK configuration can target the selected AvalAI-compatible route; otherwise keep orchestration in your application and call /v1/responses directly.

When adapting an Agents SDK workflow to AvalAI:

• Keep the same tool contracts you would use in /v1/responses: strict JSON Schema for function tools, clear descriptions, and narrow outputs.
• Put approval, tenancy, secrets, and side-effect checks in your application or agent runtime, not in the model prompt.
• If a specialist agent is exposed as a tool, describe its boundary precisely and return compact summaries rather than full traces.
• Continue to inspect typed response items (function_call, mcp_call, web_search_call, message) when debugging; the SDK abstraction should not hide audit and billing needs.
• Fall back to direct Responses calls when the SDK does not expose the AvalAI base URL, model, or route-specific options you need.

Function calling

In addition to built-in tools, you can define custom functions using the tools array. These custom functions allow the model to call your application's code, enabling access to specific data or capabilities not directly available within the model.

Learn more in the function calling guide.

Related Resources

Standard Tools

• Web Search Guide
• File Search Guide
• Code Interpreter Guide
• Shell Guide
• Computer Use Guide
• MCP and Connectors
• Function Calling Guide
• Responses API Reference

Google/Gemini Tools

• Google Models Documentation
• Model-Specific Parameters

Alibaba/DashScope Tools

• Alibaba Models Documentation
• Web Search Capabilities Example