Сколько инструментов можно дать ИИ-агенту через MCP-сервер? Популярное правило «не больше 10–20» почти не опирается на измерения. В опубликованном 15 октября 2026 года замере (3336 прогонов) топовые модели в Claude Code, Codex CLI и Antigravity во всех прогонах с отдельными инструментами выбрали верно — при наборе от 5 до 100 инструментов, а дешёвые модели ошибались редко. Число инструментов сильнее влияет на стоимость токенов, чем на точность, а выбор нужного инструмента определяют различимые названия и описания. Лимит стоит выбирать по замеру на своём сервере и своих моделях.
Материал подготовлен AIrassvet 16 октября 2026 года по исследованию, опубликованному на Хабре 15 октября 2026 года, с открытым набором данных на GitHub, и по документации Model Context Protocol и OWASP. Он адресован разработчикам и архитекторам ИИ-агентов, ИТ-директорам и владельцам продуктов, которые проектируют MCP-серверы или подключают агентов к корпоративным системам. Мы не повторяли эксперимент: все цифры принадлежат автору исследования, выводы для бизнеса и чек-лист — методика редакции. AIrassvet не аффилирован с автором исследования и разработчиками упомянутых клиентов; раздел в конце статьи описывает услуги издателя.
Содержание
- Кратко
- Откуда взялся лимит на число инструментов
- Как проводили замер
- Что показал замер на наборах до 100 инструментов
- Сколько стоит каждый инструмент
- Группировка, названия и дешёвые модели
- Правила проектирования MCP-сервера
- Как проверить свой сервер
- Частые вопросы
- Первоисточники и метод проверки
Кратко
- Лимит «10–20 инструментов» взят не из замеров. Из 91 разобранного источника конкретное число называли 20, но только 3 из этих чисел авторы получили своим измерением.
- На топовых моделях точность не падала. Opus 5.5, GPT-6.1-sol и Gemini 3.1 Pro правильно выбирали инструменты во всех прогонах с отдельными инструментами — от 5 до 100, включая неоднозначные задачи и похожие названия.
- Растёт стоимость, а не число ошибок. В Claude Code без поиска инструментов каждый лишний инструмент добавлял около 429 входных токенов за прогон, а на 100 инструментах прогон занимал 48,6 тыс. токенов.
- Названия и описания важнее количества. Невнятные названия не привели к ошибкам, но заставляли модели читать больше схем, а Gemini иногда вызывал не тот инструмент с пустыми аргументами.
- Число инструментов — не то же самое, что права агента. Ограничивать нужно в первую очередь опасные действия, а не длину списка.
Откуда взялся лимит на число инструментов
MCP-инструмент — функция, которую MCP-сервер предлагает ИИ-агенту: «найти файл», «создать счёт», «проверить статус заказа». Агент видит список инструментов, их названия и описания и решает, какой вызвать.
Автор исследования разобрал 91 материал о проектировании MCP-серверов: 21 раздел официальной документации, 28 блогов вендоров, 20 независимых блогов, 2 ветки форумов и 20 научных статей (Хабр, 15.10.2026). Что в них советуют:
- 38 источников рекомендуют сокращать число инструментов;
- 22 предлагают держать видимый набор маленьким через поиск или отложенную загрузку;
- 8 советуют «режим кода», где один-два инструмента выполняют код;
- выставлять всё подряд не советует никто.
Конкретные цифры называют 20 источников, и они сильно расходятся: 5–8 (Workato), 5–15 (Phil Schmid), меньше 10 на пространство имён и меньше 20 (OpenAI), 10–20 (Gemini, Speakeasy), 30–50 (документация Claude), «40 — точка перегиба» (Archestra). Связь числа инструментов с точностью измеряли только 10 источников из 91.
Два самых цитируемых утверждения не подтвердились. Фраза «модели ломаются на 30 инструментах» восходит к статье RAG-MCP, где считали число MCP-серверов в промпте, а не число доступных инструментов. Ограничение «Cursor не принимает больше 40 инструментов» перестало действовать в январе 2026 года.
Как проводили замер
Методика исследования (Хабр, данные на GitHub):
| Параметр | Значение |
|---|---|
| Сервер | Тестовый, 100 правдоподобных инструментов для файлов и документов; часть названий похожа (pdf_compress, pdf_optimize, image_compress) |
| Варианты | Отдельные инструменты; 7 сгруппированных инструментов на 50 операций; невнятные названия |
| Задачи | 18 задач с известными ответами, из них 10 неоднозначных; по 2 попытки |
| Размеры набора | 5, 10 … 50, 75 и 100 инструментов |
| Клиенты и топовые модели | Claude Code (Opus 5.5), Codex CLI (GPT-6.1-sol), Antigravity (Gemini 3.1 Pro) |
| Дешёвые модели | Claude Haiku 5.5, GPT-Reserve, Gemini 3.8 Flash |
| Объём | 1932 прогона на топовых моделях и 1404 на дешёвых |
| Проверка | По журналу вызовов сервера; реальной работы с файлами нет |
Важная деталь: по умолчанию ни один из трёх клиентов не кладёт все схемы инструментов в промпт. Claude Code и Antigravity показывают модели только названия, а нужные схемы подгружают по запросу; Codex ищет определения кодом. Поэтому модель выбирает инструмент сначала по названию.
Что показал замер на наборах до 100 инструментов
На топовых моделях каждый прогон с отдельными инструментами оказался полностью корректным — от 5 до 100 инструментов, во всех трёх клиентах, в Claude Code и с поиском инструментов, и без него. Сюда вошли неоднозначные задачи и 50 дополнительных похожих инструментов на размерах 75–100.
Это согласуется с немногими публичными замерами, которые нашёл автор: просадка сильно зависит от модели. В LongFuncEval при росте с 49 до 741 инструмента GPT-4o теряет около 13% точности, а другие модели — 40–85%. В MCP-Bench топовые модели держатся при сотне лишних инструментов, а слабые проседают.
Вывод для бизнеса: на современных топовых моделях сокращать список ради точности в диапазоне до 100 инструментов не обязательно. Но это не значит, что так будет на любой модели, в любой предметной области и при длинных диалогах — ограничения мы перечислим ниже.
Сколько стоит каждый инструмент
Входные токены — среднее по 36 прогонам на ячейку, все прогоны правильные (Хабр):
| Клиент | Как инструменты попадают к модели | Токенов за прогон: 5 / 50 / 100 инструментов | Каждый лишний инструмент за прогон |
|---|---|---|---|
| Claude Code (Opus 5.5), поиск включён (по умолчанию) | Только названия, схемы через ToolSearch | 13,8 тыс. / 17,4 тыс. / 19,9 тыс. | ~79 токенов |
| Claude Code (Opus 5.5), поиск выключен | Все схемы в промпте | 9,3 тыс. / 27,9 тыс. / 48,6 тыс. | 429 токенов |
| Codex CLI (GPT-6.1-sol) | Режим кода, схемы ищутся кодом | 45,3 тыс. / 61,4 тыс. / 78,2 тыс. | 408 токенов |
| Antigravity (Gemini 3.1 Pro) | Только названия, схема по запросу | 15,7 тыс. / 20,5 тыс. / 18,6 тыс. | не растёт |
Два наблюдения из исследования:
- Пока инструментов мало — примерно до 19, — поиск инструментов в Claude Code из-за лишнего вызова обходится дороже, чем загрузка всех схем сразу. На 100 инструментах с поиском входных токенов на 59% меньше.
- Меньше токенов не всегда значит дешевле. По прайсу прогон на 100 инструментах с поиском стоил $0,047 против $0,038 без поиска: кешированный вход дешёвый, а поиск добавляет ещё один вызов.
Для компании это значит, что стоимость агента зависит не только от модели, но и от клиента, в котором он работает, и от того, как этот клиент загружает инструменты. Считать бюджет нужно по реальным журналам, а не по числу инструментов в документации. Подробнее о распределении задач между моделями разной цены — в статье о роутере моделей.
Группировка, названия и дешёвые модели
Группировка. Когда все схемы загружены (Claude Code без поиска), 7 сгруппированных инструментов стоили столько же, сколько 14 отдельных, при точности 100%. С включённым поиском разница почти исчезала: 16,1 тыс. токенов против 17,4 тыс. у 50 отдельных инструментов. В Antigravity точность на группировке упала до 89%: Gemini 3.1 Pro не читал схему инструмента с несколькими операциями, угадывал названия операций и три раза выполнил не ту.
Невнятные названия. При тех же описаниях, но названиях вроде optimize_file или process_image все 276 прогонов прошли правильно. Однако Claude Code с невнятными именами переходил на поиск по ключевым словам и читал в несколько раз больше схем, а Gemini иногда открывал схему не того инструмента или пытался вызвать не тот инструмент с пустыми аргументами. Тестовый сервер такие вызовы отклонял, а настоящий мог бы выполнить.
Технические ограничения. Названия, которые примет любой клиент, состоят из букв, цифр, _ и - и укладываются в 64 символа; API Claude отвергает точки. Claude Code вызывает инструмент как mcp__<server>__<tool>, поэтому длинное имя сервера съедает часть лимита. Перечисление из чисел (enum) в схеме API Gemini не принимает — запрос со всеми схемами отклонялся целиком.
Дешёвые модели. На Claude Haiku 5.5, GPT-Reserve и Gemini 3.8 Flash правильными оказались 1288 из 1296 прогонов с отдельными инструментами. GPT-Reserve в 4 прогонах вызвал не тот инструмент начиная с 40 инструментов; три из четырёх промахов Gemini Flash были ошибками API из-за того же enum. Дешёвые модели дороже на инструмент: GPT-Reserve тратил 655 токенов на каждый лишний инструмент против 408 у GPT-6.1-sol и делал 2,6 вызова на задачу против 1,7 на 100 инструментах. Haiku дважды передал неверные аргументы в цепочке из трёх шагов на сгруппированных инструментах.
| Ситуация | Что учитывать |
|---|---|
| Топовая модель, до 100 инструментов | Точность в замере не падала; оптимизируйте ради стоимости |
| Дешёвая модель | Редкие вызовы не того инструмента начиная с 40 инструментов; растёт число вызовов и токенов |
| Сгруппированные инструменты | Эффект зависит от модели: проверяйте в клиентах ваших пользователей |
| Похожие или невнятные названия | Больше чтений схем и риск неверного вызова; называйте по действию и объекту |
| Старые и небольшие открытые модели | В замер не входили; по источникам из обзора просадка видна именно на них |
Правила проектирования MCP-сервера
Правила ниже — методика редакции по выводам исследования и требованиям безопасности.
- Называйте инструменты по действию и объекту:
invoice_create,order_status_get, а неprocessилиhandle. Название — первое, что читает модель. - Пишите различимые описания. Для похожих инструментов прямо указывайте, чем они отличаются: «склеивает PDF-файлы», «собирает PDF из изображений».
- Укладывайтесь в технические рамки: буквы, цифры,
_и-, не больше 64 символов вместе с префиксом сервера; без точек; перечисления — строками. - Не группируйте вслепую. Если объединяете операции в один инструмент, проверьте результат на моделях и клиентах, которыми пользуются ваши сотрудники или клиенты.
- Разделяйте чтение и запись. Отдельные инструменты на чтение и изменение данных нужны не ради точности, а ради прав: так проще выдавать доступ и проверять журнал.
- Ограничивайте опасные действия, а не длину списка. OWASP выделяет избыточные полномочия агента (LLM06 Excessive Agency) как отдельный риск: лишняя функция с правом удаления опаснее десятка лишних функций на чтение.
- Сокращайте список ради денег, а не на глаз. Если токены дорогие, начните с аналитики работающего сервера: какие инструменты не вызываются, какие схемы читаются чаще всего.
Как проверить свой сервер
Исследование опубликовано вместе с отчётом, results.csv и журналами каждого прогона, а автор предлагает прогнать тот же бенчмарк на своём сервере. Порядок проверки (методика редакции):
- Составьте 15–20 задач с известным правильным ответом, включая неоднозначные и задачи, где легко перепутать похожие инструменты.
- Прогоните их на моделях и клиентах, которые реально используют ваши сотрудники или клиенты, минимум по два раза.
- Сравните варианты: полный набор и урезанный, отдельные и сгруппированные инструменты, с поиском инструментов и без.
- Для каждого варианта зафиксируйте долю верных вызовов, вызовы не того инструмента, неверные аргументы, число вызовов на задачу и входные токены за прогон.
- Повторяйте замер при смене модели или клиента и при добавлении новых инструментов.
Как собрать собственный набор задач для оценки моделей, мы разбирали в статье «Свой бенчмарк для выбора LLM», а как безопасно проверять агента до запуска — в материале о песочнице для ИИ-агента.
Частые вопросы
Сколько инструментов можно дать ИИ-агенту через MCP?
Универсального лимита нет. В замере октября 2026 года топовые модели не ошибались при 5–100 инструментах, а дешёвые изредка вызывали не тот инструмент начиная с 40. Лимит стоит определять тестом на своих задачах, моделях и клиентах.
Снижает ли большое число инструментов точность агента?
На топовых моделях в этом замере — нет. Просадка зависит от модели: по публичным исследованиям слабые и старые модели теряют точность заметно сильнее, поэтому для них список стоит проверять отдельно.
Почему с ростом числа инструментов растёт стоимость?
Схемы инструментов попадают в контекст модели. В Claude Code без поиска инструментов каждый лишний инструмент добавлял около 429 входных токенов за прогон. Клиенты, которые загружают схемы по запросу, растут медленнее.
Нужно ли группировать инструменты?
Не обязательно. В замере группировка почти не сэкономила токенов при включённом поиске инструментов, а в одном клиенте снизила точность до 89%. Если группируете, проверьте результат на моделях ваших пользователей.
Как правильно называть MCP-инструменты?
По действию и объекту, буквами, цифрами, подчёркиванием и дефисом, не длиннее 64 символов с учётом префикса сервера и без точек. Похожим инструментам нужны описания, которые прямо объясняют разницу.
Безопасно ли давать агенту сто инструментов?
Безопасность определяется не числом, а правами. Инструменты на чтение и запись стоит разделять, а действия с удалением, деньгами и внешней отправкой — подтверждать человеком.
Первоисточники и метод проверки
Метод: 16 октября 2026 года мы прочитали исследование на Хабре, выписали методику, результаты по точности и токенам и ограничения, проверили доступность репозитория с данными и сверили формулировку риска избыточных полномочий с OWASP. Эксперимент AIrassvet не повторял, сырые данные из репозитория не пересчитывал; правила проектирования, порядок проверки и таблица ситуаций — методика редакции.
- Хабр, 15.10.2026: замер от 5 до 100 инструментов MCP в Claude Code, Codex CLI и Antigravity — обзор 91 источника, методика, точность, токены, группировка, названия, дешёвые модели, ограничения.
- GitHub: отчёт, results.csv и журналы прогонов.
- OWASP: LLM06:2025 Excessive Agency.
Ограничения исследования, которые называет автор: инструменты тестовые, предметная область одна (файлы), моделей шесть; старые и маленькие открытые модели не проверялись; задачи прямые, вытеснение контекста в длинных диалогах не измерялось; невнятные названия проверялись только с хорошими описаниями; в токены входят накладные расходы клиентов; не все размеры прогнаны во всех клиентах.
Как AIrassvet помогает проектировать инструменты ИИ-агентов
Набор инструментов определяет, что агент может сделать в ваших системах, сколько стоит каждый его шаг и какие права он получает. На сайте AIrassvet описаны направления, которые относятся к этой задаче напрямую:
- разработка ИИ-агентов, интегрированных с корпоративными системами и каналами связи, включая проектирование инструментов и их описаний;
- агентная автоматизация действий в ERP, 1С и браузере — с разделением инструментов на чтение и запись;
- тестирование до запуска: набор задач с известными ответами, проверка выбора инструментов и аргументов на нужных моделях;
- аудит процессов: какие операции агенту действительно нужны и какие из них требуют подтверждения человеком.
Первый шаг — выбрать один процесс, для которого планируется агент, перечислить системы и операции, которые ему понадобятся, ограничения по безопасности и критерий, по которому набор инструментов будет считаться рабочим.
Итог: считайте не инструменты, а ошибки и токены
Правило «не больше 10–20 инструментов» оказалось скорее взаимным цитированием, чем результатом измерений. В октябрьском замере топовые модели правильно работали со 100 инструментами, а число инструментов сильнее сказывалось на стоимости токенов, чем на точности.
Практический вывод: называйте инструменты по действию и объекту, пишите различимые описания, разделяйте чтение и запись, а лимит определяйте тестом на своих моделях и клиентах. Ограничивать в первую очередь нужно опасные права агента, а не длину списка.
