Цена контекста: как спрятать большой MCP за тремя командами

В сентябре 2026 года OpenCode был подключён к LEM сразу с профилями библиотечного оператора и 1С-агента. Клиент получил весь разрешённый каталог и вложил схемы инструментов в каждый запрос. Пользователь ещё не просил искать функцию или сравнивать версии — но модель уже должна была прочитать правила десятков возможных действий.

В этой комбинации было 96 инструментов. Их описание после преобразования в формат вызовов модели занимало 29 575 токенов. Вместе с другими MCP, системной инструкцией OpenCode и служебным контекстом короткий запрос вырос до 55 985 входных токенов и выполнялся 97,6 секунды на GPU. Это авторское измерение конкретного исторического контура; полный протокол в открытом доступе не опубликован.

Формально модель могла принимать длинный запрос. Практически служебные схемы конкурировали с постановкой задачи, кодом и найденными доказательствами. Чем длиннее вход, тем больше времени требуется на его первичную обработку. Информация из середины длинного контекста также может использоваться хуже, чем данные в начале и конце — этот эффект известен как lost in the middle, «потеря в середине».

Для небольшой модели и агрессивно сжатых весов риск выше: ей нужно одновременно удержать десятки похожих имён, выбрать правильную процедуру и не перепутать аргументы. LEM должен был не просить модель стать умнее, а детерминированно убрать лишний выбор там, где его может сделать система.

Локальный сервер llama.cpp перед генерацией превращал JSON Schema инструментов в служебную грамматику допустимого ответа. Наборы из 83 и 96 инструментов завершались ошибкой построения grammar через 123,84 и 142,94 секунды. Тот же endpoint без инструментов отвечал за 1,23 секунды; bootstrap из девяти инструментов — за 0,98 секунды.

Причиной были не только общий объём, но и две конкретные конструкции схем: предельный размер массива 2000 и регулярное выражение версии с сокращением \d в сложной схеме. Их отдельно исправили, но сам архитектурный вывод остался: даже полностью совместимый каталог не стоит заранее передавать модели целиком.

Хороший MCP обязан объяснить назначение инструмента, необходимые аргументы, ограничения, продолжение долгой операции и границы прав. Если убрать эти сведения, агент начнёт угадывать: вызовет импорт вместо чтения, потеряет operationId или придумает поле, которого нет.

Удалить редко используемые инструменты тоже нельзя. Каталог LEM продолжал расти: проверка репозитория фиксировала 160 инструментов 26 сентября и 161 после следующего библиотечного изменения. Проблема была не в богатой функциональности, а в том, что вся она одновременно показывалась каждой модели.

Профиль — это короткое меню действий для конкретной роли. Общая работа с кодом, 1С, библиотечный корпус и администрирование получают разные наборы. Для публичного демонабора достаточно чтения библиотек; импорт, проектный корпус и административные операции не должны появляться в меню агента.

Важно: профиль не выдаёт права. Он только сокращает tools/list — технический список команд, который видит клиент. Каждый реальный вызов всё равно проходит авторизацию LEM. Поэтому короткое меню для читателя нельзя считать разрешением на импорт или изменение.

Даже профиль 1С оставался слишком большим. Поэтому guided-режим — направляемый режим работы — публикует только lem_route, lem_execute и lem_continue. Внутренние инструменты не исчезают: их полные схемы, проверки и обработчики остаются на сервере.

Первая команда, lem_route, выбирает подходящее действие по формулировке задачи и просит уточнение при неоднозначности. Точное имя инструмента имеет приоритет. В техническом ответе selectionId обозначает выбранный маршрут и шаблон следующего вызова. Затем lem_execute проверяет параметры и выполняет штатную операцию, а lem_continue читает следующую страницу или продолжает длительную задачу по её идентификатору operationId.

Для новой задачи сначала вызови lem_route. Выполни возвращённый nextCall через lem_execute. Если ответ содержит operationId или nextCursor, продолжай через lem_continue.

Слабой модели не нужно помнить внутренние названия, просматривать сотню схем и самой решать, какой статус опрашивать. Система берёт на себя механический выбор, валидацию и продолжение. Модель остаётся там, где действительно нужна: понимает цель, заполняет предметные аргументы, сопоставляет доказательства и формирует решение.

Это не обещание, что любая локальная модель станет равна сильной облачной. Это инженерный способ не тратить её ограниченный контекст на каталог возможностей. После изменения клиента, модели, способа сжатия весов или состава инструментов измерение нужно повторить.