170 тулов, потом 15 — как рабочие агенты показывают модели меньше способов ошибиться
Саммари
Postman строит агента внутри продукта, которым пользуются 40 млн разработчиков, и первым столкнулся с потолком размера tool surface: как только модель видит больше примерно 40 инструментов, она начинает выбирать неверные, передавать неверные аргументы и вызывать несуществующие тулы. Сегодня агенту доступно больше 170 инструментов, но на каждый запрос их показывается около 15. Статья разбирает, как Postman, NVIDIA KGMON, Reducto, Siemens EDA и Orca Security прошли одну и ту же стену четырьмя приёмами — показывать только нужные этому запросу тулы, заменять узкие чтения одним query-инструментом, придавать тулам форму реальной работы и догружать остальные по требованию, — и честно помечает, где опубликованы before/after-замеры, а где методика не раскрыта.
Из этого следует, что «сколько тулов видит модель на реальном запросе» — метрика уровня SLO: её проще измерить и лечить (фильтрация, слияние, deferred loading), чем вытягивать качество ростом модели, который проблему только смягчает.
На практике для MCP-интеграций правило «один endpoint — одна тулa» удобно на старте и вредно на масштабе: каталог нужно проектировать как контекстный бюджет, а не как опись API.
Важный нюанс: обе «потолочные» цифры (40 у Postman, 30–50 у Anthropic) опубликованы без методики и error rate — это предупреждающая полоса, а не закон, и строить на ней жёсткие SLA нельзя.
Ограничение: часть кейсов (Reducto, Siemens) — рассказы компаний о собственных инструментах без абляций, из них видно направление, но не вклад каждого отдельного приёма.