2 ноября 2026 г.

Протокол контекста модели (Model Context Protocol, MCP) помогает агентским системам выполнять действия с внешними инструментами и получать из них информацию. По мере роста приложений агентам может потребоваться работать со множеством серверов MCP и большими каталогами инструментов, что усложняет управление контекстом.

Загрузка каждого определения инструмента заранее тратит токены на нерелевантные схемы и оставляет меньше места для инструкций, истории и данных задач. В масштабах предприятия командам нужен продуманный способ для агентов находить релевантные инструменты с одновременным контролем доступа, учетных данных и выполнения инструментов.

В этом руководстве мы покажем, как использовать Postman Fabric Gateway для подключения нескольких серверов MCP через единую конечную точку и включения прогрессивного поиска инструментов, чтобы агенты могли получать схемы инструментов только при необходимости.

Предпочитаете видео? Это руководство также доступно в виде видеоинструкции:

Чему вы научитесь

К концу этого руководства вы узнаете, как:

Подключать несколько серверов MCP к Postman Fabric Gateway и безопасно управлять их восходящими (upstream) учетными данными.
Создавать отдельные и комбинированные маршруты, чтобы клиенты могли обращаться к нескольким каталогам инструментов через единую конечную точку MCP.
Включать прогрессивное обнаружение инструментов, чтобы агенты могли искать релевантные инструменты, получать схемы по запросу и выполнять инструменты без предварительной загрузки полного каталога.

Предварительные требования

Перед началом вам понадобятся следующие компоненты:

Учетная запись Fabric Gateway
Учетная запись Postman с доступом к рабочему пространству, где вы будете тестировать интеграцию.
Базовое понимание MCP

В этом руководстве мы будем работать с двумя серверами MCP: сервером поддержки (support MCP) и банковским сервером (banking MCP). Эти серверы MCP используются агентом поддержки для обработки споров по транзакциям клиентов. Мы не будем вдаваться в технические подробности агента или инструментов, которые предоставляет сервер MCP.

Шаг 1. Подключение серверов MCP и настройка их учетных данных

В Fabric Gateway нажмите на «MCP servers» в левом меню навигации и выберите «Create connection».

Назовите соединение banking-mcp и введите указанный ниже URL-адрес в качестве полной конечной точки MCP банковского сервера.

В поле требования к восходящей аутентификации (Upstream auth requirement) выберите тип аутентификации Bearer и переключите радиокнопку.

Затем вам нужно предоставить необходимые учетные данные авторизации для Fabric Gateway.

Скопируйте и вставьте banking-mcp-demo-key в качестве ключа API в поле ввода токена.

Это создаст учетные данные на уровне службы для соединения. Эти учетные данные будут храниться в безопасном хранилище.

Этот экран настройки позволяет создать соединение и предоставить доступ к нему на только что созданном маршруте за один раз. Заполните предпочитаемое имя для нового маршрута и укажите путь, по которому он должен быть доступен. Переключите опцию «Gateway Key» и выберите «No gateway key».

Сохраните соединение, нажав на кнопку «Create Connection».

Повторите этот процесс для соединения support-mcp.

Шаг 2. Создание маршрута для объединения каталогов инструментов

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

Перейдите к разделу «MCP Servers» на левой боковой панели. Перейдите на вкладку маршрутов (routes) и нажмите значок «Copy DP URL» справа от любого из маршрутов.

В Postman создайте запрос MCP и вставьте только что скопированный URL-адрес DP (DP URL). Протестируйте любой из инструментов MCP из списка инструментов.

Повторите этот процесс для обоих серверов MCP.

Затем мы хотим объединить инструменты этих двух серверов MCP на одном маршруте. Находясь на вкладке маршрутов, нажмите «Create Route», чтобы создать третий маршрут.

Назовите этот маршрут all-mcp, задайте ему путь, например /banking/all, и выберите обе службы.

Скопируйте URL-адрес DP и отправьте на него запрос MCP в Postman.

Теперь клиент перечисляет инструменты с обоих серверов через одну конечную точку. Fabric добавляет префиксы и пространства имен к именам инструментов, чтобы вы могли определить исходную службу каждого инструмента; в этой настройке объединенный список содержит 103 инструмента.

Мы объединили соединение, но клиент по-прежнему получает полный каталог. Следующий шаг меняет это.

Шаг 3. Включение прогрессивного обнаружения инструментов

Откройте плагин (Plugin), прокрутите вниз и нажмите «Use» на опции «Tool Search». Дайте этому плагину имя и ограничьте его область видимости только что созданным маршрутом all-mcp.

Нажмите кнопку «Edit as JSON» и вставьте приведенный ниже JSON. Вернитесь в режим формы (form mode), убедитесь, что служба openai действительно выбрана, а затем сохраните изменения.

ПРИМЕЧАНИЕ. Здесь можно использовать любую модель или службу эмбеддингов по вашему выбору.

Этот плагин добавляет службу эмбеддингов, которая позволяет выполнять семантический поиск по каталогу инструментов. Это означает, что запрос вроде «list transactions» может вернуть релевантные инструменты без необходимости указывать их точные имена. Это будет подробнее объяснено чуть позже.

Отключите и заново подключите объединенный запрос MCP в Postman, чтобы обновить список его инструментов.

Вместо 103 определений инструментов теперь вы должны увидеть три инструмента, выполняющие следующие задачи:

Это означает, что агент теперь может постепенно обнаруживать инструменты вместо загрузки всей схемы инструментов целиком заранее. Исходные восходящие инструменты не были удалены или объединены в три операции. Вместо этого шлюз изменил то, как клиент обнаруживает их и вызывает.

Протестируйте обнаружение с помощью простого запроса: «list transactions». Запустите инструмент поиска и просмотрите возвращенные совпадения. Вы должны увидеть кандидатов, релевантных поиску транзакций, а не полный каталог банковских инструментов и инструментов поддержки.

Скопируйте имя одного из возвращенных инструментов, например ban__banking_list_transactions, и вставьте это имя в инструмент get_tool для получения определений схемы этого инструмента. Затем используйте возможность execute-tool с идентификатором и аргументами этого инструмента.

Вот последовательность действий, которую выполнит агент: найти релевантную возможность, узнать, как ее вызвать, а затем действовать. В клиенте Postman MCP вы только что прошли каждый этап вручную.

Шаг 4. Мониторинг трассировок и телеметрии

Fabric Gateway автоматически собирает телеметрию по всем службам и маршрутам. Вы можете просматривать трассировки на панели управления шлюза. Нажмите на «traces» на левой боковой панели. Это должно показать вам список всех запросов, маршрутизируемых шлюзом, и вы можете нажать на любой из них, чтобы просмотреть сквозную трассировку.

Трассировки позволяют изучить сопоставление маршрутов, выполнение плагинов и активность восходящих систем (upstream), если применимо.

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

Что меняется для агента

В этом руководстве мы показали, как предоставлять доступ к нескольким серверам MCP через единую конечную точку MCP, сократить рабочую поверхность инструментов агента и предоставить сфокусированный набор инструментов, которые агенту проще находить и использовать.

В результате получается одна конечная точка MCP на базе двух служб, с тремя инструментами, перечисленными изначально вместо 103. Это дает меньшую отправную точку для приложения, которое в противном случае передавало бы полный каталог своей модели. Это не измеренное процентное сокращение токенов или затрат: результаты поиска, полученные схемы и ответы инструментов по-прежнему потребляют контекст, а обнаружение добавляет запросы. Измеряйте полный рабочий процесс при сравнении производительности.

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