Автор статьи устал платить за мусорную свалку из сырых API и написал прокси-шлюз на Go, который фильтрует и сжимает информацию для агентов в VS Code.

Шлюз toolc встает между агентом и зоопарком серверов, решая, что показать модели сразу, а что спрятать.

Автор добился экономии в 60% на API-вызовах, используя режим flat, который сжимает информацию и удаляет дубликаты.

Когда вы ставите в VS Code популярные агентные расширения (Cline, Roo Code, Kilo), быстро выясняется одна мерзкая вещь. Мы подключаем к ним новые инструменты быстрее, чем LLM под их капотом способна их адекватно переварить.

Сначала все выглядит безобидно. Вы подключаете к редактору пару MCP-серверов: один для файлов, другой для поиска. Агент радуется, вы радуетесь, всё работает. Но потом начинается:"О, прикручу-ка я еще сервер для базы данных... и GitHub... и внутреннюю Jira... и вон тот OpenAPI-каталог".

В какой-то момент вы открываете свойmcp.jsonи видите там 25 серверов. А агент начинает творить дичь.

На практике этот "зоопарк" приводит к вполне конкретным болям:

• Инструменты начинают конфликтовать именами (у вас три разныхsearch).
• Описания функций (description blobs) становятся настолько длинными, что занимают больше места, чем сам код, который вы просите написать.
• Модель выжигает контекстное окно (и ваши деньги) просто на то, чтобы вспомнить, какие ручки у нее вообще есть.
• Агент путается в монструозных JSON-схемах и начинает галлюцинировать аргументами.

В итоге вы платите космические счета за токены не за "интеллект" GPT или Claude, а за то, что каждый раз показываете им мусорную свалку из сырых API.

Я устал платить за этот мусор и написалtoolc- прокси-шлюз на Go, который встает между агентом и зоопарком серверов, жестко фильтруя и сжимая всё, что видит модель.

Что я сделал

Было:десятки сырых MCP-серверов и OpenAPI-спецификаций, которые напрямую "орут" в контекст модели.

Стало:один компактный слой, который сам решает, что показать модели сразу, что раскрыть только по запросу, а что вообще спрятать от греха подальше (например, ручкуDROP TABLE).

Я не стал писать "убийцу MCP" или очередной тяжелый фреймворк.toolc- это совместимыйruntime-фасад. Для вашего VS Code он выглядит как обычный, но единственный MCP-сервер. Для поддерживаемых локальных MCP stdio серверов и скомпилированных OpenAPI-поверхностей он прячет зоопарк за одним MCP-сервером.

Как это выглядит на практике (Сценарий: VS Code + MCP)

Представьте, что у вас есть стандартный, раздутый конфиг от Cline или Roo Code. Вы просто скармливаете его нашей утилите:

Вопрос, где взять бинарник ?

У вас два пути. Либо забрать готовый бинарник из раздела Releases на GitHub (есть под Windows, Linux, Mac), либо собрать из исходников, если на машине стоит Go: go installgithub.com/aak204/Tool-Catalog-Compiler/cmd/toolc@v1.0.0

Далее утилита читает ваш конфиг, пингует все сервера, собирает их инструменты, выкидывает дубликаты, сжимает маркетинговую воду из описаний и генерирует один новый конфиг.

Вы скармливаете этот новый конфиг редактору, и запускаете шлюз:

Всё. Агент больше не видит хаоса. Он видитодин серверtoolc, который выдает ему аккуратное меню.

Под капотом: три режима жадности

Я перевожу все спецификации (OpenAPI, функции, MCP) в единое внутреннее представление (IR). А дальше компилятор применяет магию, которую я разделил на три режима:

• direct(сырой режим):показываем всё как есть. Нужен только для дебага и бенчмарков, чтобы поплакать над тем, как всё было плохо.
• flat(мой фаворит):основной рабочий режим. Модель получает "плоский", сжатый и дедуплицированный список. Минимум токенов, максимум пользы, ноль лишних запросов.
• staged(параноидальный режим):сначала отдаем модели только короткие названия инструментов (discovery). Если агент решает что-то вызвать, он делает отдельный запрос за точной схемой аргументов. Добавляет задержку сети, но спасает, когда схемы очень сложные или рискованные.

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

Кстати, парсить гигантские спецификации оказалось тем еще квестом. Когда я попытался скормить компилятору официальную OpenAPI‑спеку Stripe (а это монстр на мегабайты YAML/JSON с кучей рекурсивных ссылок), мой парсер просто сожрал десятки гигабайт памяти и упал с Out of Memory (OOM). Пришлось писать жесткие depth guards (ограничители глубины), лимитировать экспансию нод и переиспользовать ссылки (shallow ref-shell reuse), чтобы компилятор не пытался развернуть бесконечную рекурсию. Теперь Stripe переваривается за миллисекунды и жрет всего ~48 МБ памяти.

Меньше слов, больше метрик (или почему я сэкономил 60% денег)

Я инженер, поэтому прогнал всё это через жесткие бенчмарки на реальных спецификациях (включая GitHub API на 1100 эндпоинтов и монструозный Stripe API). Использовал OpenRouter и четыре топовые модели (Qwen-3.6-plus, GLM-5.1, GPT-5.4, Claude Sonnet 4.6).

Самый приятный график - этостоимость на миллион вызовов.

Вот сухие цифры по экономии:

Цена без нас (direct)

Цена с нами (flat)

Сэкономили

qwen/qwen3.6-plus

z-ai/glm-5.1

openai/gpt-5.4

anthropic/claude-sonnet-4.6

Я не сделал модели умнее. Я просто перестал заваливать их мусором в системном промпте. За счет режимаflatобъем контекста (token proxy) падает драматически, а Success Rate у сильных моделей часто остается высоким, но не является универсальными 100% на всех сценариях.

Галлюцинации и боль (Случай с GLM)

Я не буду врать, что "всё всегда работает идеально". У меня был интересный кейс сz-ai/glm-5.1.

На ранних прогонах эта модель вела себя как студент после бессонной ночи: обрывала ответы, уходила в "размышления" и забывала вернуть JSON, ломала контракты.

Я начал копать. Выяснилось, что:

1. Я сам косячил, скармливая ей один и тот же системный промпт для разных шагов оркестрации. Claude это прощал, а GLM сыпалась.
2. Ей тупо не хватало лимита токенов на завершение (completion budget).

Я вынес это в отдельный изолированный эксперимент (dist/glm-controlled). Развел контракты промптов, поднял лимиты. В итоге Success Rate в режимеflatвырос с0.78до0.92.

Вывод: компиляция каталогов спасает от шума, но если модель "капризная", ей все равно нужны индивидуальные профили (request shaping). Магии не бывает.

Что дальше? (И чего я НЕ обещаю)

Я не строю "Control Plane для всего AI". Это был бы буллшит.

Сегодняtoolcотлично справляется с:

• Локальными MCP-серверами черезstdio.
• Скомпилированными OpenAPI-поверхностями.
• Защитой контекста редакторных агентов.

Чего яНЕобещаю прямо сейчас:

• Магической поддержки удаленных MCP-транспортов (пока только локалка).
• Полноформатного рантайма для обычных функций (generic functions).
• Production-ready шлюза для OpenAI-compatible форматов (это в планах).

Если ваш агент в VS Code захлебывается от количества подключенных серверов, а счета за API вызывают нервный тик - попробуйте поставить между ними мой шлюз. Вам не придется переписывать код или сносить инфраструктуру. Вы просто уменьшите уровень шума.

Исходники, графики и инструкция по установке - всё лежит на GitHub. Я выложилv1.0.0, который закрывает главную боль с локальными MCP и OpenAPI. Но архитектура позволяет сделать из этого ультимативный Control Plane для любых агентов. Если вы пишете на Go, страдаете от зоопарка тулзов и у вас есть идеи - залетайте в репозиторий. Буду рад любым PR, баг-репортам и просто критике кода. Давайте сделаем этот инструмент еще мощнее вместе!

Репозиторий toolc на GitHub