Протокол Model Context Protocol (MCP) упрощает подключение инструментов к ИИ-агентам, но масштабирование каталогов создаёт практическую проблему: агенту приходится получать и обрабатывать всё больше описаний доступных функций. В препринте Cartograph, опубликованном на arXiv 28 сентября 2026 года, исследователи предлагают промежуточный федеративный прокси, который не передаёт модели полный список инструментов сразу.
Вместо 374 отдельных определений агент видит три прокси-инструмента. Они принимают запрос, находят подходящий сервер и только затем раскрывают нужные описания. На развёртывании из 22 серверов авторы измерили 475 токенов для обмена, связанного с поиском пяти лучших результатов, против 42 450 токенов при указанном ими сценарии полной загрузки каталога.
Это не измерение общей стоимости работы агента во всех сценариях, а сравнение конкретного этапа обнаружения инструментов. Тем не менее для систем с большим числом MCP-серверов разница показывает, какую часть контекстного бюджета можно сэкономить за счёт отложенной выдачи.
Вместо полного каталога — прогрессивное раскрытие
Обычная схема обнаружения MCP-инструментов предполагает, что клиент получает описания подключённых функций и использует их при выборе вызова. Пока каталог небольшой, такой подход относительно прост. Но при добавлении серверов растут объём контекста, время обработки и вероятность того, что похожие инструменты начнут конкурировать друг с другом.
Cartograph меняет эту логику с линейного обхода каталога O(n) на прогрессивное раскрытие O(k), где вторая величина обозначает объём результатов, который действительно требуется для текущего запроса. Агент сначала обращается к прокси, затем получает наиболее релевантные серверы и инструменты, а не весь набор определений.
В описанном авторами тесте это означает видимость трёх специальных прокси-инструментов вместо 374 исходных. Такой слой не заменяет сами MCP-серверы и не исполняет их функции автоматически: его задача — организовать поиск и контролировать, какие метаданные попадут в контекст агента.
Подписанные карточки и контроль происхождения описаний
Первый компонент Cartograph — capability cards, или карточки возможностей. Это компактные описания серверов и их функций, подписанные с помощью Ed25519. По замыслу авторов, карточка создаётся под контролем оператора, который разворачивает сервис, а не берётся напрямую из произвольного рекламного или издательского описания.
Подпись позволяет проверить целостность карточки и связать её с конкретным оператором. Однако она не доказывает, что описание полностью соответствует реальному поведению инструмента. Оператор может подписать неточную, неполную или слишком оптимистичную информацию. Поэтому криптографическая аутентификация в Cartograph отвечает за происхождение и неизменность данных, но не является независимой проверкой качества.
Для ранжирования система также сохраняет сведения о происхождении описаний, использованных при конкретном запросе. Это может пригодиться при разборе ошибочного выбора: разработчик сможет установить, какая карточка повлияла на выдачу и на каком уровне возникла проблема — в описании, поиске сервера или выборе отдельного инструмента.
Rift ищет опасно похожие инструменты
Второй механизм получил название Rift. Он предназначен для анализа конфузионных кластеров — групп инструментов, которые могут выглядеть похожими для модели или пользователя и потому приводить к неправильному выбору.
По данным препринта, Rift объединяет три уровня анализа:
- плотностную кластеризацию похожих описаний;
- анализ запаса между результатами для конкретного запроса;
- диагностику отдельных токенов, влияющих на сходство.
На авторском наборе система обнаружила 49 конфузионных кластеров. Четыре из них были отнесены к категории высокого риска и появились в карточках, созданных на этапе начальной генерации. Это важная деталь: компактные описания экономят контекст, но чрезмерно похожие формулировки могут ухудшить маршрутизацию.
Исследователи отдельно сравнили 119 описаний, созданных языковыми моделями. В этом эксперименте удалось убрать кластер с нулевой дистанцией, однако смешивание карточек, подготовленных разными режимами генерации, наоборот, могло снизить качество поиска. Результат указывает на зависимость системы не только от алгоритма ретривера, но и от единообразия самих метаданных.
Двухэтапный поиск дал R@5 0,816
Третий компонент Cartograph — двухступенчатый ретривер. Сначала он ранжирует MCP-серверы, а затем ищет подходящие инструменты внутри выбранных серверов. Такой порядок сокращает пространство поиска и не требует сравнивать запрос со всеми функциями одновременно.
На 49 запросах из набора, составленного авторами исследования, Cartograph показал показатель R@5, равный 0,816. Это означает, что нужный результат попадал в пятёрку предложенных вариантов с указанной частотой. Для сравнения использовалась базовая схема на основе совпадения по ключевым словам и коэффициента Жаккара; она получила R@5 0,592.
Разрыв выглядит заметным, но его нельзя автоматически трактовать как преимущество в реальных рабочих нагрузках. Бенчмарк был подготовлен авторами, а в представленных материалах нет независимого воспроизведения на публичном наборе запросов. Неизвестно также, насколько результаты изменятся при других языках описаний, более неоднородных каталогах или большом числе серверов.
Накладные расходы составили 5 миллисекунд
Авторы измерили задержку шлюза в десяти прогонах и сообщили о среднем увеличении на 5 мс, или 0,8%, по сравнению с прямыми вызовами MCP через stdio. В рамках этого эксперимента дополнительный слой маршрутизации не стал заметным источником задержки.
Однако такой результат относится к измеренной конфигурации: 22 серверам, 374 инструментам и конкретной реализации прототипа. Он не показывает, как изменится время ответа при удалённых серверах, сетевых сбоях, сложной аутентификации или параллельной работе нескольких агентов. Для практического внедрения нужно отдельно учитывать время самой операции инструмента: несколько миллисекунд на поиск могут быть несущественными по сравнению с запросом к внешнему API, но заметными для локальных быстрых вызовов.
Cartograph также не позиционируется как замена подходам с выполнением кода. Его задача уже: определить, какие описания инструментов раскрывать агенту, сократить поисковый контекст и сохранить историю происхождения метаданных. Код-исполнительные системы решают другую проблему — выполнение действий и работу с промежуточными результатами.
Для разработчика MCP-инфраструктуры главный практический вопрос сейчас не в заявленной экономии токенов как таковой, а в качестве каталога. Перед экспериментом с подобным прокси стоит проверить три вещи: действительно ли все серверы требуют одновременной видимости, не дублируют ли карточки друг друга и можно ли воспроизвести авторский тест на собственных запросах. Результаты Cartograph показывают перспективный способ организовать обнаружение инструментов, но пока остаются результатом препринта и ограниченного авторского эксперимента, а не подтверждённым стандартом для MCP.
