MCP tools — это инструменты, которые MCP-сервер отдаёт модели: у каждого есть имя, короткое описание задачи и схема входных данных, по которой модель понимает, что и в каком формате передать. Разработчик компании решает, какой набор инструментов показать агенту, и от этого решения зависит, справится агент с задачей или запутается в похожих названиях. Хорошее описание инструмента умещается в одно предложение без двусмысленности — по нему модель и выбирает, что вызвать.
Три части инструмента
MCP tools — инструменты сервера с тремя обязательными частями: имя, описание задачи и схема входных данных; агент выбирает инструмент по тексту описания задачи, а имя функции в коде служит меткой только для сервера.
Имя инструмента — техническая метка для сервера, а модель ориентируется на описание: короткий текст, где сформулировано, что делает инструмент и когда его вызывать. Слабое или общее описание — источник половины ошибок агента: модель путает похожие инструменты и выбирает случайный вместо нужного для конкретного шага задачи.
Схема входных данных — третья часть: она описывает, какие поля инструмент ждёт и в каком типе (текст, число, список), и без неё модель гадает, передавать параметр строкой или объектом.
Схему входных данных обычно описывают в стандартном машиночитаемом формате, который понимает клиент MCP, — формат уже часть протокола, и разработчику незачем придумывать свой синтаксис заново для каждого сервера.
Tools, resources и prompts
MCP-протокол предлагает серверу три типа примитивов, и tools — только один из них: tools описывают действие, которое агент запускает сам; resources — данные, которые сервер отдаёт для контекста, без запуска действия; prompts — готовые шаблоны запроса, которые сервер подсказывает клиенту.
| Примитив | Что делает | Кто инициирует |
|---|---|---|
| tools | выполняет действие с результатом — запрос к API, запись в базу, вызов внешнего сервиса | агент, по решению модели во время диалога |
| resources | отдаёт данные для контекста — файл, запись, список записей | клиент MCP, по явному запросу пользователя или программы |
| prompts | подсказывает готовый шаблон запроса под типовую задачу | пользователь, через меню клиента MCP |
Разница между tools и resources путает разработчиков чаще всего: resources отдают данные пассивно, а tools меняют состояние системы или запускают внешний вызов — и именно поэтому опасные tools просят подтверждение у человека, а resources идут без него.
Название примитива в документации протокола иногда расходится с тем, как его называет конкретный клиент MCP в интерфейсе, — принцип везде общий, а подпись в конкретном приложении сотрудник сверяет по факту.
Что такое MCP в целом и зачем он бизнесу — разобрано в статье Что такое MCP и зачем он нужен бизнесу; здесь речь только про один слой протокола — про сами инструменты и то, как их проектируют для конкретной системы.
Клиент MCP видит все три примитива в одном списке при подключении к серверу и уже дальше решает, что показать модели: часть resources подключают только по явному запросу пользователя, и контекст диалога остаётся компактным на каждом шаге благодаря такому точечному отбору данных.
Как модель выбирает
Модель выбирает инструмент по описанию задачи и по названиям полей в схеме — то же самое, что сотрудник делает, читая подписи на кнопках в незнакомой программе: у модели те же подписи выглядят как список текстовых описаний.
Похожие описания сбивают модель с той же вероятностью, что и похожие подписи на кнопках сбивают человека: если два инструмента объясняют себя почти одинаковыми словами, модель путает их местами при повторных попытках выполнить задачу.
Разработчик компании обычно начинает с короткого списка инструментов под одну задачу и расширяет его постепенно — сервер, который сразу предлагает модели полсотни действий, почти всегда путает выбор сильнее, чем узкий набор из пяти-шести пунктов под конкретный процесс.
- Узкое действие на каждую операцию — вместо одного инструмента, который делает всё с базой данных сразу
- Понятные имена — глагол и объект в имени инструмента («создать_запись» ясен модели сразу, а «действие_один» оставляет угадывать смысл)
- Подтверждение для опасных действий — удаление, оплата, отправка наружу проходят через отдельный шаг согласия человека, прежде чем инструмент выполнит вызов
- Журнал вызовов — каждый вызов инструмента с параметрами и результатом сохраняется, и по этому журналу разбирают спорный случай позже
Ошибки набора
Слишком много инструментов в одном наборе — частая ловушка: агенту предлагают двадцать похожих действий сразу, и модель тратит попытки на угадывание, хотя могла бы сразу решать саму задачу.
- Слишком много инструментов — десяток похожих действий в одном наборе путает модель сильнее, чем помогает
- Неоднозначные имена — два инструмента с похожим названием и разным эффектом заставляют модель гадать, какой вызвать
- Отсутствие проверки входа — инструмент принимает любые данные без проверки формата, и ошибка агента доходит до системы компании напрямую
Проверка входа — тот самый барьер, который решает, дойдёт ли ошибка модели до системы компании или остановится на входе в инструмент.
Проверка на реальных запросах сотрудников — самый быстрый способ найти слабое описание до того, как его найдёт модель посреди рабочей задачи: десяток типичных формулировок прогоняют через набор инструментов ещё на этапе сборки сервера.
Какой инструмент в вашей системе агент вызывает чаще остальных?
Набор под систему
Сборка MCP-сервера своими руками, где разработчик описывает первые инструменты, разобрана в статье свой MCP-сервер: как дать Claude доступ к вашим данным — там же пример минимального сервера по шагам. Готовый сервер под 1С со своим набором инструментов под документы и операции компании собран в статье MCP для 1С.
Набор инструментов агента для управления браузером — отдельная большая тема, где узкие действия и подтверждение опасных шагов работают по тому же принципу: разбор — в статье Playwright MCP: браузер под управлением ИИ-агента.
Документация инструмента обновляется вместе с кодом сервера — если описание расходится с реальным поведением действия, модель раз за разом выбирает инструмент по устаревшему тексту и получает результат, далёкий от того, что задумал разработчик.
Первый сервер держите на пяти-шести инструментах с узким действием в каждом и подтверждением перед опасным шагом — расширяйте набор только после того, как модель перестаёт путать первые пять между собой.
Проектирование набора инструментов под конкретную систему компании — часть работы на этапе внедрения ИИ, где разработчик решает вместе с командой, какие действия агенту доверяют сразу, а какие оставляют человеку.