VMCP сжимает десятки MCP protocol серверов в один шлюз: 30 000 токенов больше не тратятся впустую

MCP protocol появился, чтобы дать языковым моделям доступ к внешним базам, файлам и сервисам, которых у них нет «из коробки». Идея прижилась: по данным Anthropic на декабрь 2025 года, SDK для Python и TypeScript скачивают больше 97 миллионов раз в месяц. Но чем больше серверов подключено, тем острее инженерная боль. Илья Гуляев, разработчик из команды Рег.облака, описал решение в статье на Хабре и выложил исходный код на GitHub.

Какую проблему решает шлюз?

На тестовом стенде автора работало несколько MCP-серверов с почти шестью десятками инструментов. Один только MCP-коннектор для Atlassian (Jira и Confluence) приносит 34 инструмента. Каждый инструмент, это структура из пяти полей: имя, описание для модели, схема входных аргументов, схема результата и служебные пометки. В модель при каждом запросе уходят имя, описание и схема аргументов, и именно они набирают те самые 30 тысяч токенов. Пользователь ещё ничего не спросил, а контекстное окно уже наполовину занято.

Проблема не только в токенах:

• Контекст тает. 30 тысяч токенов на описания, дальше нужно место для истории диалога, пользовательских данных и самого ответа.
• Каждый сервер держит отдельное соединение. Клиент должен проходить фазы инициализации, согласования версий MCP protocol и авторизации с каждым сервером по отдельности.
• Уведомления множатся. Если каталог инструментов на одном из серверов обновился, клиент должен перевыгрузить описания, а это снова токены.

Как устроен VMCP?

Автор поставил GraphQL-шлюз (единая точка входа, через которую клиент обращается ко всем серверам сразу) поверх десятка MCP-серверов. Клиент видит один виртуальный MCP-сервер вместо десятка реальных.

Сам MCP protocol работает поверх двух актуальных транспортов: stdio (локальный процесс) и Streamable HTTP (сетевой, через POST и серверные события SSE). Старый транспорт HTTP+SSE считается устаревшим. Протокол поддерживает сессии с сохранением состояния, но допускает и работу без него.

Типичный цикл ИИ-агента (ИИ-агент, программа, которая сама решает, какой инструмент вызвать и когда) выглядит так:

1. Клиент запрашивает каталог инструментов (tools/list).
2. Каталог встраивается в системный промпт модели.
3. Модель выбирает нужный инструмент.
4. Клиент отправляет вызов (tools/call) с аргументами.
5. Сервер выполняет запрос и возвращает результат.
6. Результат уходит обратно в модель, та решает, что делать дальше.

Шлюз VMCP вклинивается между шагами 1 и 2: он собирает каталоги со всех серверов, но отдаёт клиенту только то, что нужно для конкретного запроса, а не все 60 описаний разом.

Как попробовать?

1. Откройте репозиторий проекта: github.com/hewimetall/vmcp.
2. Склонируйте код и разверните локально по инструкции из README.
3. Подключите свои MCP-серверы к шлюзу и проверьте, сколько токенов уходит на описания до и после.

Есть ли аналоги в России?

Прямого аналога VMCP среди российских продуктов на момент публикации нет. YandexGPT и GigaChat поддерживают вызов внешних функций (function calling), но у них нет публичной реализации MCP protocol и, соответственно, нет проблемы с десятками MCP-серверов в одной инфраструктуре.

Для российских разработчиков, которые строят агентные (агентный, когда модель сама планирует цепочку действий) системы на базе зарубежных моделей через API, проблема раздутого контекста стоит даже острее: каждый лишний токен, это деньги за вызов API или потерянное место в окне для полезного диалога. VMCP работает с любым MCP-совместимым клиентом, поэтому его можно поднять на российском сервере и подключить к любой модели, которая поддерживает MCP protocol.

Что делать с этим прямо сейчас, по ролям?

Автору на Дзене. Если вы используете ИИ-агентов для генерации контента и подключаете внешние источники данных, следите за тем, сколько инструментов загружено в контекст. Два-три сервера работают без проблем, но с ростом числа инструментов модель начинает «забывать» начало разговора.

Разработчику и техническому маркетологу. Проверьте, сколько токенов уходит на описания ваших MCP-серверов, посчитайте стоимость одного запроса до полезной нагрузки. VMCP позволяет сократить эту статью расходов, шлюз открытый и поднимается локально.

Предпринимателю в РФ. Если в вашей компании строят ИИ-автоматизацию с несколькими внешними сервисами, вопрос «куда делся контекст» встанет быстро. Решение опенсорсное, без привязки к конкретному облаку.

Частые вопросы

MCP protocol и function calling, это одно и то же?

Нет. Function calling (вызов внешних функций) работает внутри одной системы: модель вызывает функцию, которая живёт в том же приложении. MCP protocol вынес эту механику в сеть: инструменты стали отдельными сервисами, с которыми клиент общается по стандартному протоколу. Грубо говоря, монолит превратился в набор микросервисов.

30 тысяч токенов на описания, это много?

Для сравнения: у модели GPT-4o контекстное окно составляет 128 тысяч токенов. 30 тысяч на служебные описания, это почти четверть окна, и туда ещё не вошли история диалога, пользовательские документы и сам ответ. Для моделей с окном поменьше ситуация критичнее. А главное, каждый токен стоит денег при работе через API.

Можно ли использовать VMCP с российскими моделями?

Шлюз работает на стороне клиента и не зависит от конкретной модели. Если ваш клиент поддерживает MCP protocol, VMCP встанет между ним и серверами. На практике это значит, что шлюз подойдёт для любой модели, которая умеет работать с MCP, независимо от страны разработчика.

Решение Ильи Гуляева показывает направление, в котором неизбежно пойдёт вся экосистема MCP protocol: чем больше инструментов подключают к моделям, тем важнее слой управления между ними. Код открыт, стенд можно поднять за вечер, и это лучший способ проверить, нужен ли вам такой шлюз, пока ваша инфраструктура ещё не выросла до болезненных размеров.