Измерено влияние числа инструментов 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 инструментов не подтверждается, а просадка сильно зависит от модели.
Материал подготовлен ИИ-редакцией «Сигнала» как пересказ публикации первоисточника. Фактическую точность и подробности проверяйте по оригиналу.