Tool Use и Function Calling

Короткая версия

Tool use нужен, когда модели мало собственных весов и текста в контексте. Тогда она:

1. понимает, что нужен внешний action или данные;
2. выбирает нужный tool;
3. формирует аргументы;
4. получает результат;
5. продолжает reasoning или выдаёт финальный ответ.

В 2026 полезно различать три класса tools:

• Custom tools: ваши функции, API, базы данных, backend actions.
• Built-in tools: web search, computer use, code execution и другие provider-side tools.
• MCP tools: инструменты из стандартизированной MCP-среды.

Практически это значит:

• tool use больше не ограничивается парой функций get_weather() и calculator();
• orchestration вокруг tools стала важнее самих schema;
• качество системы теперь зависит не только от prompt, но и от contract design, permissions и stop conditions.

Чем custom tool отличается от built-in tool?

1. Что такое tool use на практике

Tool use полезнее всего понимать как мост между языком и действиями.

У модели есть цель:

• получить внешние данные;
• сделать вычисление;
• вызвать внутренний сервис;
• запустить bounded action;
• передать работу во внешний tool environment.

Тогда она не должна галлюцинировать ответ "из головы", а должна попросить нужный инструмент.

Это и есть основной engineering value:

• меньше hallucinations на актуальных данных;
• больше deterministic behavior;
• возможность строить agent loops, а не только chat interfaces.

2. Три класса инструментов

Custom tools

Это классический function calling:

• вы описываете имя;
• даёте schema;
• пишете executor;
• валидируете аргументы;
• возвращаете результат модели.

Сценарии:

• CRM lookup;
• internal API;
• SQL or search endpoint;
• billing/status checks;
• bounded write actions.

Built-in tools

Это tools, которые поставляет сам провайдер:

• web search;
• code execution;
• computer use;
• file search;
• provider-side connector tools.

Здесь ownership другой:

• tool contract задаёт провайдер;
• execution идёт не у вас;
• billing и safety model могут отличаться от custom tool path.

MCP tools

MCP добавляет ещё один слой: tool registry и execution surface из внешнего стандартизированного протокола.

Практический эффект:

• модель получает доступ не к hardcoded set ваших функций;
• а к расширяемой внешней tool ecosystem;
• где transport, discovery и capability negotiation уже стандартизированы.

3. Как выглядит текущая provider landscape

OpenAI

Current OpenAI framing уже строится вокруг Responses API и tools, а не вокруг старого launch-era chat.completions as default.

Практически важно следующее:

• есть function calling для custom tools;
• есть built-in tools;
• есть strict schema path;
• есть agent/runtime integrations, где tools живут внутри larger loop;
• есть MCP path в OpenAI Agents SDK.

То есть current OpenAI tool use уже не сводится к "добавьте functions в запрос".

Anthropic

Anthropic historically использует термин tool use, и current Claude stack сильнее завязан на:

• agent loops;
• coding and computer-use scenarios;
• reasoning + tools;
• MCP-centric workflows.

Важно, что в Anthropic ecosystem tools и agent runtime часто живут ближе друг к другу, чем в старых function-calling tutorials.

Google

Gemini current docs подчёркивают:

• function calling как bridge to real-world actions;
• unique id для function calls;
• SDK automation, где часть wiring берёт на себя client library;
• сочетание built-in tools и function calling, особенно в Gemini 3 stack.

Это делает Google path ближе к mixed-tool environment, а не к чисто ручному JSON loop.

4. Где чаще всего ломается tool use

Самые частые failure modes почти никогда не сводятся к "модель не знает, что такое функция".

Обычно ломается одно из пяти мест:

1. модель выбрала не тот tool;
2. модель выбрала верный tool, но плохие аргументы;
3. executor вернул слишком шумный или нестабильный output;
4. loop не понял, что делать после tool result;
5. safety/policy layer не отделён от tool layer.

Поэтому хороший tool use в 2026 строится не вокруг magic prompting, а вокруг:

• ясных schema;
• bounded toolsets;
• валидаторов;
• retries и failure states;
• tracing.

5. Когда tool use лучше workflow, а когда хуже

Tool use полезен, если:

• путь выполнения частично неизвестен заранее;
• нужен выбор между несколькими actions;
• модель должна решать, когда данных недостаточно;
• нужен adaptive loop.

Tool use избыточен, если:

• шаги полностью deterministic;
• одно API нужно вызвать всегда;
• модель не должна выбирать способ действия;
• важнее predictability, чем autonomy.

В таком случае лучше обычный workflow:

• код выбирает шаг;
• модель только формирует текст или structured result;
• tool selection не делегируется LLM.

6. Tool contract важнее prompt magic

Хороший tool contract обычно включает:

• точное имя;
• ясное описание use case;
• строгую schema;
• понятные ограничения;
• предсказуемый output format;
• explicit failure semantics.

Плохой contract выглядит так:

• инструмент называется слишком общо;
• description не говорит, когда его применять;
• schema допускает мусор;
• executor возвращает giant blob без структуры.

7. Safety и approvals

В 2026 опасно обсуждать tool use без governance.

Даже если tool schema идеальна, остаются риски:

• destructive actions;
• data exfiltration;
• over-broad file or DB access;
• prompt injection через tool outputs;
• repeated retries и loops.

Поэтому рядом с tool use обычно должны жить:

• allowlists;
• permission modes;
• tool-level guardrails;
• approval steps;
• trace logs.

8. Tool use и MCP

MCP не заменяет tool use. Он расширяет среду, из которой tools приходят.

То есть:

• function calling отвечает на вопрос "как модель инициирует вызов";
• MCP отвечает на вопрос "как tools и context стандартизированно предоставляются приложению и модели".

Это важное различие:

• можно иметь tool use без MCP;
• можно использовать MCP как источник tools для agent runtime;
• можно строить гибридную систему с custom tools, built-in tools и MCP tools одновременно.

OpenAI-style custom tool

from openai import OpenAI

client = OpenAI()

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_order_status",
            "description": "Return current order status by order id.",
            "parameters": {
                "type": "object",
                "properties": {
                    "order_id": {"type": "string"},
                },
                "required": ["order_id"],
                "additionalProperties": False,
            },
        },
    }
]

response = client.responses.create(
    model="gpt-5.2",
    input="Check order A-44319",
    tools=tools,
)

Current practical point здесь не в синтаксисе, а в том, что tool use в OpenAI лучше мыслить через current Responses API, а не через старый tutorial-only chat.completions baseline.

Gemini-style function calling

from google import genai

client = genai.Client()

get_weather = {
    "name": "get_weather",
    "description": "Return weather for a city",
    "parameters": {
        "type": "object",
        "properties": {
            "city": {"type": "string"},
        },
        "required": ["city"],
    },
}

response = client.models.generate_content(
    model="gemini-3-flash",
    contents="What's the weather in Almaty?",
    config={"tools": [get_weather]},
)

У Gemini current docs отдельно подчёркивают function-call id и SDK automation, поэтому ручной loop там уже не единственная mental model.

Что обычно надо проверять в ревью

У нас 30 внутренних API. Что сломается первым?

Проверьте себя