Комментарии 16
А почему надо было самому велик изобретать? Этот (https://gitlab.com/gitlab-org/ai/lazy-mcp), например, не подошел?
Спасибо за ссылку! Да, lazy-mcp я смотрел. Проект классный и бьет ровно в ту же боль: не вываливать на агента весь зоопарк инструментов разом и беречь стартовый контекст.
Но у меня задача стояла шире. Я хотел не просто прикрутить ленивую загрузку к MCP-серверам, а решить проблему комплексно:
Переваривать не только MCP, но и огромные OpenAPI-спеки.
Свести всё это в единый слой с жестким контролем (рулить политиками доступа и отрезать опасные ручки еще до того, как их увидит модель).
Сделать основным режимом быстрый плоский список (
flat), а ленивую подгрузку схем (staged) оставить как запасной вариант для самых тяжелых случаев.
Так что lazy-mcp - отличный сфокусированный инструмент. Просто под мой замес из OpenAPI, десятков серверов и желания жестко контролировать то, что в итоге долетает до VS Code, готового решения я для себя не нашел.
Были бы ещё круче если бы прокси мог детектить результаты команд mcp серверов и перед возвращением значения выполнять преобразование из JSON в toon - так ещё лучше было бы
Надо поверх писать агентный MCP/tool который обрабатывает запрос, дёргает MCP несколько раз и отдает финальный ответ
Спасибо за идеи! Обе фичи - крутые. В текущем релизе v1.0 их пока нет, но с удовольствием забираю обе в бэклог для следующих версий.
@Prikalel (про конвертацию вывода): абсолютно согласен. Сейчас toolc жестко сжимает схемы на входе, но результаты выполнения от серверов возвращает агенту «как есть». Если перехватывать жирные JSON-ответы и на лету конвертить их во что-то компактное перед отдачей в LLM - это сэкономит еще гору токенов на возврате. Забираю в бэклог.
@headliner1985 (про агентную оркестрацию): тоже крутая идея. Сейчас у меня честный stateless-прокси, чтобы не усложнять ядро на старте. А то, что вы описываете - это макро-инструменты: когда модель дергает одну ручку, а шлюз под капотом сам прогоняет нужный цикл вызовов и отдает готовую выжимку, экономя дорогие сетевые раундтрипы к Claude/GPT.
Короче, идеи отличные. Забрал их себе, хочется сделать реально интересный инструмент
одно я не могу понять - это цифры по экономии. если первый коммит на проекте 3 дня назад, а уже успели сэкономить тысячи долларов, то как это удалось? 😳
Хаха, справедливое замечание! 😅 Речь, конечно, про математику сгорания токенов на дистанции, а не про то, что я положил в карман тысячу баксов за выходные.
Два момента:
Про "3 дня назад": это дата первого пуша в паблик. Локально шлюз писался, тестировался и экономил мне токены гораздо дольше.
Откуда такие цифры: агенты отправляют список всех тулзов на каждом шаге. У тебя висит 40k токенов схем, агент делает 40 циклов для решения одной таски = 1.6 млн токенов (около $5 по тарифам Claude).
Шлюз срезает 60-80% этого паразитного трафика на каждом запросе. Если гонять автономных агентов каждый день на рефакторинг, набегают огромные суммы!
Хороший инструмент, взял на заметку. Вопрос. А разве кастомные агенты в GitHub Copilot не решают отчасти задачу перенасыщения модели объемом MCP? Можно хоть под каждую узкую задачу делать свой сетап агента со своим нужным набором MCP. Далее легко переключать их через интерфейс.
Спасибо! Да, узкие агенты частично решают проблему, но остаются три нюанса:
Потеря автономности: усли задача комплексная (посмотреть логи БД -> поправить код -> пушнуть в Git), вам придется руками переключать агентов и таскать контекст между ними. А хочется дать агенту права на всё и уйти пить кофе.
Сжатие самих схем: даже у 2-3 нужных MCP-серверов сырые JSON-схемы весят неприлично много из-за дублирования. toolc не просто прячет лишнее, он компилирует и физически “сплющивает” схемы, делая их плотнее.
Вендор-лок: Copilot - отличная, но закрытая среда. Шлюз же работает везде: в Cursor, Roo Code или вообще с локальной llama.cpp, где каждый токен на вес золота. Для мелких изолированных тасок Copilot - топ. Но для сложных автономных цепочек без шлюза токены улетают в трубу.
Можно сделать кастомного агента под комплексную задачу и выбрать инструменты из разных MCP(GIT, БД, редактирование файлов и т.д.). По опыту, главное, чтобы не больше 60 инструментов было.
Согласен. А точно сжатие не приведет к негативным потерям?
Согласен, это безусловный плюс.
А вы смотрели, как это организовано в antigravity? Сырых Json схем на одобрение там нет, только на запреты пишут в raw. После подключения модель получает компактный список, в ui можно включать/выключать инструменты. Недавно добавили локальные (workspace конфигурации).
Но Ваша реализация - точно получше будет. Включать -выключать десяток MCP в зависимости от проекта и стадии - это такая боль. Особенно когда ui подвисает и приходится перезагружать целиком, в процессе возрастает нагрузка и отваливается доступ к модели, а потом на восстановление контекста при перезапуске сжигает ~15% недельного лимита 😅
Не получилось заставить работать mcp-serve. Если запустить руками - в консоли тишина. Редакторы не могут подключиться, отваливаются по таймауту.
Может как-то можно получить вывод? Что ему не нравится?

Как я спас агентов в VS Code от передоза инструментами, сжав зоопарк MCP-серверов в один Go-бинарник