← СИГНАЛ ИССЛЕДОВАНИЯ
ИССЛЕДОВАНИЯ

Измерено влияние числа инструментов MCP на точность

Автор провела 1932 прогона на топовых моделях и 1404 на дешёвых в Claude Code, Codex и Gemini, чтобы выяснить, как количество инструментов MCP-сервера влияет на точность. Большинство советов сокращать число инструментов не подкреплено измерениями.

Автор исследования проанализировала 91 публичный источник о проектировании MCP-серверов и обнаружила, что 38 из них советуют сокращать число инструментов, а 20 называют конкретные цифры, чаще всего 10–20. Однако только 10 источников реально измеряли, как количество инструментов влияет на точность. Тогда она провела собственный эксперимент: 1932 прогона на топовых моделях и 1404 на дешёвых, в трёх клиентах — Claude Code, Codex CLI и Antigravity, с числом инструментов от 5 до 100.

В эксперименте использовался фейковый сервер на 100 реалистичных инструментов для работы с файлами и документами, включая намеренно похожие названия (pdf_compress, pdf_optimize, image_compress). Агенты выполняли 18 задач с известными ответами, 10 из которых были неоднозначными, при N = 5, 10, 50, 75 и 100 инструментах, по две попытки на каждую. Тестировались модели Opus 5.5, GPT-6.1-sol и Gemini 3.1 Pro.

На топовых моделях точность не снизилась даже при 100 инструментах и похожих названиях. Все прогоны с отдельными инструментами оказались полностью корректными во всех трёх клиентах, как с поиском инструментов в Claude Code, так и без него. Это согласуется с немногочисленными публичными измерениями: в LongFuncEval при росте с 49 до 741 инструмента GPT-4o теряет около 13% точности, а другие модели — 40–85%.

На дешёвых моделях появились вызовы не того инструмента. В Antigravity точность упала до 89%: Gemini не стал читать схему инструмента с несколькими операциями и трижды выполнил не ту. Также выяснилось, что ни один из трёх клиентов по умолчанию не кладёт схемы инструментов в промпт: Claude Code и Antigravity показывают только названия, а Codex ищет определения кодом.

Поиск инструментов в Claude Code ни разу не спрятал нужный инструмент: в каждом прогоне был только один вызов ToolSearch первым действием, и инструменты выбирались по точному имени. При малом числе инструментов (до 19) поиск выходит дороже, чем загрузка всех схем сразу, но на 100 инструментах входных токенов на 59% меньше, хотя стоимость прогона всё равно выше из-за дополнительного вызова.

Группировка инструментов не дала однозначного выигрыша. При загрузке всех схем 7 сгруппированных инструментов стоят столько же, сколько 14 отдельных, при точности 100%. С включённым поиском группировка почти ничего не меняет: 16,1k входных токенов против 17,4k у 50 отдельных инструментов. Экономия заметна только при предварительной загрузке всех схем.

С невнятными названиями (optimize_file, process_image и т.п.) все 276 прогонов прошли правильно, но Claude Code переходил на поиск по ключевым словам и читал больше схем, а Gemini часто открывал не ту схему. Автор заключает, что правило «меньше инструментов — выше точность» на современных топовых моделях в диапазоне до 100 инструментов не подтверждается, а просадка сильно зависит от модели.

mcpclaudegeminiopenaiтестированиеразработка
Первоисточник Читать в Хабр ↗

Материал подготовлен ИИ-редакцией «Сигнала» как пересказ публикации первоисточника. Фактическую точность и подробности проверяйте по оригиналу.

По этой теме ИССЛЕДОВАНИЯ Четыре ИИ-субагента нашли ошибку одиночного агента Хабр · 14 окт, 12:02 ИНСТРУМЕНТЫ Регрессионное тестирование промптов выявило пропуски Хабр · 14 окт, 16:45 ИНСТРУМЕНТЫ Разработчик создал надсмотрщик для ИИ-агентов Хабр · 14 окт, 12:12 ОБЩЕСТВО Линус Торвальдс применяет ИИ в ядре Linux ZDNet · 13 окт, 22:30 ИНСТРУМЕНТЫ Как настроить coding-агент, MCP и разрешения Хабр · 13 окт, 12:31