# Tool use: как Claude вызывает твои функции

Канонический URL: https://zero2claude.ru/blog/api-tool-use
Дата: 2026-08-18
Теги: api, инструменты, разработчикам, claude

Claude по API знает только то, что было до обучения. Tool use даёт ему руки: ты описываешь функции, он сам решает, когда их позвать.

Ты подключил Claude к своему приложению через API, и всё шло отлично — пока пользователь не спросил: «А какая сейчас погода в Казани?» Модель честно ответила, что не знает: её обучили давно, окна за сервером у неё нет, текущую погоду взять неоткуда. То же самое с курсом валют, с балансом на счёте, с тем, что лежит в твоей базе данных прямо сейчас.

Дело не в том, что Claude глупый, — он просто заперт внутри текста. Рассуждать умеет, а вот сам сходить в интернет, заглянуть в базу или отправить письмо — нет. Тут и появляется **tool use**: механизм, который даёт модели руки. Ты описываешь доступные функции, а она решает, когда их позвать.

<Cover src="/blog/api-tool-use.jpg" alt="Мозг, тянущийся к набору инструментов на верстаке" />

## Кто что делает: разделение ролей

Самое важное и при этом самое неочевидное в tool use: **Claude не выполняет твои функции сам**. Он только просит их выполнить. Код запускаешь ты — в своём приложении, на своём сервере. Звучит странно? Разложим по ролям.

Представь, что ты диспетчер, а Claude — толковый, но безрукий консультант на телефоне. Соображает отлично, но встать со стула не может. Поэтому диалог идёт так:

- **Ты (в коде) говоришь Claude:** «Вот список того, что ты умеешь попросить: узнать погоду, найти заказ по номеру, отправить письмо. У каждого инструмента такое-то имя и такие-то параметры».
- **Claude думает и отвечает:** «Чтобы ответить пользователю, мне нужна погода в Казани. Позови, пожалуйста, инструмент `get_weather` с городом Казань».
- **Ты выполняешь** свою настоящую функцию `get_weather("Казань")` — обычный код, который пишешь сам, — и получаешь, скажем, `+18, дождь`.
- **Ты возвращаешь результат Claude:** «Вот что вернул инструмент: +18, дождь».
- **Claude формулирует** человеческий ответ: «Сейчас в Казани +18 и дождь, захвати зонт».

Ключевая мысль: модель не лезет в твой код напрямую и не выдумывает результат. Она лишь **называет, что хочет вызвать и с какими аргументами**. Выполнение и контроль остаются за тобой.

## Как ты описываешь инструмент

Чтобы у Claude появились руки, ты при запросе передаёшь список инструментов. Каждый инструмент — это, по сути, три вещи: **имя**, **описание словами** (зачем он нужен) и **список параметров**. Вот как это выглядит для погоды:

```json
{
  "name": "get_weather",
  "description": "Узнать текущую погоду в указанном городе",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "Название города" }
    },
    "required": ["city"]
  }
}
```

`input_schema` пусть не пугает — это просто формальное описание: какие поля бывают и какие из них обязательны. А вот `description` важнее, чем кажется: именно по нему Claude решает, **когда** инструмент уместен. Чем понятнее объяснишь словами, тем точнее модель будет его звать — и тем реже дёрнет не вовремя.

<Callout type="tip">
Пиши `description` так, будто объясняешь новому стажёру, когда нажимать эту кнопку, а когда нет. Хорошо: «Найти заказ по номеру. Использовать, только если пользователь назвал номер заказа». Плохо: «поиск заказа». Лишняя ясность в описании экономит кучу неверных вызовов.
</Callout>

## Зачем это нужно на практике

Tool use превращает Claude из умного собеседника в деятельного помощника. Сводится всё к двум классам задач.

**Свежие и приватные данные.** Модель знает только то, что было до обучения, и понятия не имеет о твоей базе. Через инструменты ты открываешь ей доступ к актуальному: курс валют на сегодня, статус доставки конкретного заказа, остаток на складе, профиль пользователя. Claude перестаёт фантазировать и начинает отвечать фактами — потому что факты приносишь ему ты.

**Действия, а не только слова.** Инструмент может не просто что-то возвращать, а *делать*: создать запись в календаре, отправить письмо, завести задачу в трекере, оформить возврат. Тогда из твоего приложения вырастает настоящий ассистент: пользователь пишет «перенеси встречу на завтра», Claude зовёт инструмент `move_meeting`, а твой код реально двигает событие.

И весь фокус в том, что **ты решаешь, насколько отпустить поводок**. Хочешь — выполняешь вызов автоматически. Хочешь — показываешь пользователю «Claude собирается отправить письмо, подтвердить?» и ждёшь нажатия. Раз код выполняешь ты, последнее слово на каждом шаге тоже за тобой.

<Callout type="note">
Один запрос может потребовать нескольких инструментов подряд: сначала Claude попросит найти заказ, получит ответ, потом попросит проверить статус доставки и только затем сформулирует итог. Это нормальный цикл «вызов → результат → снова к модели», и крутится он, пока задача не решена. Твой код тут как петля: вызвал — вернул ответ — снова спросил модель.
</Callout>

## Главное в трёх строчках

Если убрать все детали, tool use держится на одной идее:

- Ты **описываешь** функции словами — имя, зачем, какие параметры.
- Claude **решает**, какую и когда позвать, и называет аргументы.
- Ты **выполняешь** свой код и **возвращаешь** результат — а он превращает его в ответ.

Модель остаётся мозгом, который рассуждает, а руками всё делает твой код. Похоже на магию, но под капотом — обычный обмен сообщениями. Тот же запрос по API, с которым ты уже знаком, просто с добавленным списком инструментов.

Хочешь потрогать это руками — от первого запроса до полноценного tool use? Мы разбираем API по шагам и без воды.