MCP-серверы: когда точность перестает зависеть от количества инструментов
Долгое время сообщество ИИ-разработчиков придерживалось аксиомы: чем меньше инструментов предлагает сервер MСP, тем выше точность агента. Новые измерения охватывают широкий спектр моделей и клиентов, опровергая эту догму для современных нейросетей и подсказывая новые правила игры для экономичных решений.
# Когда «меньше — значит лучше» перестает работать
В эпоху интеграции искусственного интеллекта с внешними системами через протокол Model Context Protocol (MCP) вопрос масштабируемости инструментов становится критическим. Почти все существующие рекомендации по дизайну MCP-серверов сходятся в одном пункте: минимизируйте количество доступных инструментов. Авторы советуют ограничиваться десятком функций или использовать сложные механизмы отложенной загрузки схем.
Однако количественные данные часто уступают место качественным догадкам. Проанализировав почти сто исследований, автор материала отмечает, что лишь малая доля из них проводила реальные тесты. Большинство советов основано на теоретических моделях или устаревших кейсах, где лимиты клиентов или специфика промптов накладывали искусственные ограничения.
Экспериментальное исследование: 1932 прогона на топовых моделях
Для получения объективных данных проведен масштабный эксперимент. Исследователь создал симуляцию сервера с сотней реалистичных инструментов, часть из которых имеет схожие названия, имитируя реальные сценарии использования. Тестирование проводилось в трех различных клиентах:
1. Claude Code (Opus 5.5) 2. Codex CLI (GPT-6.1-sol) 3. Antigravity (Gemini 3.1 Pro)
Испытания охватывали диапазон от 5 до 100 инструментов. В каждом сценарии выполнялось по 18 задач с известными решениями, по два повторения каждого теста. В итоге было проведено 1932 прогона на мощных моделях и дополнительные 1404 на бюджетных решениях.
Ключевые выводы для топовых моделей Результаты на высокопроизводительных моделях оказались неожиданными: качество выполнения задач не зависело от количества инструментов. Точность оставалась стабильной и высокой даже при предоставлении модели доступа к стами функциям.
В режиме по умолчанию, когда клиент использует поиск инструментов (показывая модели только названия, а не полные описания), Claude Code демонстрировал высокую эффективность. Модель корректно выбирает нужную схему по названию, редко ошибаясь даже среди 100 вариантов. Исключение составило лишь один случай из семидесяти, где названию было трудно сопоставить функцию.
Авторы эксперимента подчеркивают важность различий в работе клиентов. Например, Codex CLI не передает схемы в промпт изначально, а ищет их кодом. Это означает, что модель сначала принимает решение на основе названия, а затем подгружает описание. В таких условиях четкие названия становятся критически важными.
Проблема невнятных названий
Эксперимент выявил тонкий момент: если названия инструментов расплывчаты (например, optimize_file и optimize_document), это не влияет на точность, если модели сразу доступны полные описания. Однако при использовании режима поиска, когда модель видит только заголовки, неясные названия резко увеличивают количество ошибок выбора.
В таких случаях модель вынуждена загружать множество схем, пытаясь угадать нужную по ключевым словам. Это приводит к росту потребления токенов и увеличению стоимости вычислений, но не к потере точности на топовых моделях.
Скрытая цена инструментов: экономический аспект
Если точность не падает, значит ли это, что можно добавлять неограниченное количество инструментов? Ответ кроется в стоимости. Главный фактор, влияющий на экономику, — это то, как клиент доставляет данные модели.
В режиме поиска (по умолчанию в Claude Code и Antigravity) каждое взаимодействие требует дополнительных вызовов API для загрузки схем. Это увеличивает входные токены на ранних этапах, но при большом количестве инструментов экономия на контексте окупает дополнительные запросы.
На примере Claude Code: при работе с 5 инструментами использование поиска дороже, чем загрузка всего контекста сразу. Однако при 100 инструментах количество токенов сокращается на 59%, что делает режим поиска экономически выгодным.
Уязвимость бюджетных моделей Ситуация меняется кардинально при работе с менее мощными моделями, такими как Claude Haiku, GPT-Reserve или Gemini Flash. На этих архитектурах количество инструментов действительно влияет на точность, но не так, как прогнозировали раньше.
На бюджетных моделях впервые фиксируются ошибки выбора инструментов (вызов функции, не соответствующей задаче). Глубокие модели могут игнорировать похожие названия благодаря развитому контекстному окну, в то время как простые архитектуры часто ошибаются, особенно когда количество доступных функций превышает 40–50.
Кроме того, на дешевых моделях растет количество лишних вызовов API. Модель начинает чаще перепроверять выбор, что съедает экономию от сокращения контекста. Группировка инструментов (несколько операций в одной функции) также по-разному влияет на бюджетные и топовые модели: то, что помогает одной, может мешать другой.
Рекомендации для разработчиков MCP-серверов Анализ данных позволяет сформировать четкие правила проектирования серверов:
* Не сокращайте инструменты ради точности на топовых моделях. Если ваша целевая аудитория использует мощные нейросети, количество функций не влияет на их способность выполнять задачи корректно. * Оптимизируйте для стоимости и контекста. Ограничение набора инструментов или использование отложенной загрузки необходимо для снижения стоимости промптов и уменьшения нагрузки на контекстное окно. * Будьте внимательны к названиям. Названия инструментов — это первая информация, с которой сталкивается модель. Используйте четкие, описательные имена (действие + объект), избегая двусмысленностей. В режиме поиска плохие названия приводят к ошибочной загрузке схем. * Проверяйте на целевых клиентах. Поведение модели зависит от того, как клиент доставляет данные. То, что работает в Claude Code, может не подходить для Codex или Antigravity. * Измеряйте свой сервер. Теоретические рекомендации не всегда применимы к реальным сценариям. Проведите собственные бенчмарки на вашем оборудовании и с вашими данными.
Технический нюанс: при использовании группировки функций убедитесь, что она работает в клиентах, которых используют ваши пользователи. Для некоторых клиентов группировка экономит токены, для других — увеличивает задержку.
Таким образом, фокус смещается с количества инструментов на их качество, читаемость и соответствие требованиям клиентов. Разработчикам стоит пересмотреть стратегии проектирования MCP-серверов, опираясь на факты, а не на устоявшиеся мифы.