Контроль токенов определений MCP в агентах
Обновлено September 19, 2026 · впервые опубликовано September 19, 2026
Подключение ИИ-агента к нескольким серверам Model Context Protocol (MCP) добавляет тысячи входных токенов на каждом ходе еще до того, как модель прочитает хотя бы одно слово запроса пользователя. Каждый зарегистрированный инструмент добавляет JSON-схему с именами функций, описаниями параметров, перечислениями и ограничениями типов. В корпоративном рабочем пространстве с 6 подключенными MCP-серверами (GitHub, Postgres, Slack, Jira, Brave Search, Filesystem) эта вступительная часть занимает от 4,500 до 12,000 входных токенов на каждый вызов API. При 30 ходах в рамках одной задачи статичные накладные расходы составляют от $0,35 до $1,20 чистой избыточности схем.
Анатомия налога на схемы MCP
Model Context Protocol задает стандартный интерфейс JSON-RPC между клиентом и сервером для возможностей языковых моделей. Однако модели не могут узнать о доступности инструмента без явной передачи схемы в системном промпте или в блоке определений инструментов. Когда инженер подключает MCP-сервер для базы данных с 24 инструментами для изучения схемы и выполнения SQL, полная JSON-схема должна передаваться модели на каждом ходе вывода, чтобы она могла выбирать вызовы инструментов. Поскольку стандартная тарификация API учитывает все входные токены в каждом запросе, неуправляемый каталог инструментов MCP создает немедленный линейный базовый налог на все операции агента.
Почему определения инструментов MCP стоят так много токенов?
Каждое определение инструмента MCP требует подробных метаданных: имен параметров, вложенных свойств, описаний и заголовков спецификации JSON Schema. Один подробный инструмент запроса к базе данных часто занимает от 350 до 600 токенов. При десятках инструментов из нескольких ведомственных MCP-серверов начальное контекстное окно заполняется статичными контрактами инструментов, а не историей диалога.
Три архитектуры для устранения накладных расходов MCP
Инженерные команды, которые эксплуатируют парки продуктивных агентов, применяют три стратегии снижения раздутия токенов инструментов:
- Точки кэширования промптов: размещайте статичные определения инструментов MCP перед любой динамической историей диалога и ставьте явную точку кэширования сразу после блока инструментов. На моделях Anthropic, OpenAI и Google Gemini с TTL кэша 5 минут или 1 час попадания в кэш снижают входную стоимость схемы инструментов на 75-90% начиная с первого хода.
- Двухэтапная динамическая регистрация инструментов: не открывайте все инструменты MCP глобально. Используйте легковесную модель-маршрутизатор или семантический индекс, чтобы определить нужный домен инструментов по запросу пользователя, и динамически добавляйте в полезную нагрузку агента выполнения только 3-5 релевантных схем.
- Сжатие схем и минификация описаний: удаляйте избыточное форматирование, убирайте markdown из строк JSON Schema и заменяйте длинные пояснения полей компактными определениями типов. Агрессивная минификация обычно уменьшает объем определений инструментов на 35-50% без ухудшения точности выбора инструмента.
Как инженерные команды могут снизить накладные расходы токенов MCP?
Команды снижают накладные расходы MCP, ставя точки кэширования промптов после объявлений инструментов, применяя двухэтапную семантическую маршрутизацию инструментов и минифицируя избыточные описания свойств JSON-схемы.
Может ли кэширование промптов устранить расходы на токены схем MCP?
Кэширование промптов не устраняет задержку обработки токенов полностью, но оно снижает стоимость повторяющихся токенов определений инструментов до 90% на моделях, поддерживающих кэширование префикса, при условии что блок определений инструментов остается неизменным между последовательными ходами.
По теме
Хотите применить это к своему стеку? Принесите счета провайдеров, логи шлюза и ключевые рабочие процессы — мы определим драйверы затрат и пути экономии. Заказать бесплатный аудит →