24 СЕНТЯБРЯ 2026 Г.

Большинство корпоративных возможностей скрыто за REST API, которые агенты не видят. Чтобы сделать API доступным для вызова агентом сегодня, команды обычно развертывают и обслуживают отдельный сервер MCP, который заново реализует логику маршрутизации, аутентификации и квотирования, уже поддерживаемую их шлюзом. Model Context Protocol (MCP) стал стандартным способом обнаружения и вызова инструментов для агентов, а такие фреймворки, как Agent Development Kit (ADK) и Gemini Enterprise, поддерживают его нативно.

Google Cloud API Gateway теперь закрывает этот пробел. На этапе публичного превью API Gateway может выступать в качестве удаленного сервера MCP: добавьте аннотацию в уже развернутую спецификацию OpenAPI, разверните ее, и ваши существующие REST-операции станут доступны в виде готовых для агентов инструментов MCP — без необходимости создавать, размещать или обслуживать отдельный сервер.

API Gateway — это легкий шлюз в линейке шлюзов Google Cloud. Если у вас есть сервис в Cloud Run и вы хотите, чтобы его API был защищен, управляем и доступен для агентов за считанные минуты, это самый быстрый путь. Для полноценной корпоративной платформы API и MCP (управление жизненным циклом, расширенные правила обработки трафика, монетизация) используйте Apigee. Чтобы контролировать запросы ваших агентов на выходе, включая такие серверы MCP, как этот, используйте Agent Gateway. Маршрутизация моделей, которая предоставляет одну стабильную конечную точку для исходящих вызовов LLM, является сопутствующей возможностью для другого направления ИИ-трафика.

Как это работает

API Gateway принимает стандартные JSON-RPC запросы MCP на одной конечной точке, преобразует каждый вызов tools/call в соответствующий REST-запрос, применяет ваши существующие правила и возвращает ответ обратно. Поскольку переведенный запрос неотличим от обычного REST-вызова, аутентификация по JWT или ключу API, квоты и логирование, которые вы уже настроили для этой операции, продолжают работать без изменений — MCP и REST-трафик используют ровно один путь применения правил, а конкретная операция расходует одну квоту независимо от того, как она вызывается.

Зааннотируйте свою спецификацию OpenAPI. MCP требует OpenAPI 3.0.x или 3.1.x; OpenAPI 2.0 не поддерживается, поэтому если ваш шлюз все еще использует спецификацию 2.0, сначала выполните миграцию. Включите эту функцию на уровне документа с помощью x-google-api-management.mcp, а также настройте или пропустите отдельные операции с помощью x-google-mcp-tool. Каждая предоставленная операция должна иметь бэкенд и непустое описание.

Простой текст

Скопировано

Описание инструмента — это основной сигнал, который LLM использует для принятия решения о его вызове, поэтому пишите о том, когда и зачем использовать инструмент, а не только о том, что он возвращает.

2. Разверните шлюз. Разверните конфигурацию API как обычно. API Gateway генерирует конфигурацию с поддержкой MCP и начинает обслуживать MCP на базовом пути /mcp без необходимости выделения дополнительной инфраструктуры.

3. Определите, кто может обнаруживать ваши инструменты. По умолчанию tools/list не требует аутентификации, что удобно для разработки, но публикует имена ваших инструментов и схемы входных данных для всех желающих. Для продакшна требуется JWT — обратите внимание, что ключи API не могут защитить этот метод:

Простой текст

Скопировано

tools/call всегда применяет ту аутентификацию, которую требует лежащая в основе REST-операция, независимо от того, защитили ли вы обнаружение.

4. Подключите своего агента. Укажите любому MCP-клиенту конечную точку шлюза /mcp. В ADK это набор инструментов плюс учетные данные, которые ваш шлюз уже ожидает:

Python

Скопировано

Шлюз сопоставляет аргументы инструмента с путем REST, параметрами запроса, телом и заголовками вашей операции, пропускает запрос через существующие правила и возвращает ответ бэкенда в виде результата MCP. Чтобы проверить это по сети:

Shell

Скопировано

JSON

Скопировано

Зачем предоставлять MCP через шлюз

Обнаруживаемость. Подключите свой шлюз к API hub, и его сервер MCP будет опубликован там с метаданными, специфичными для MCP, и автоматически появится в Agent Registry, чтобы агенты и разработчики могли находить предоставляемые им инструменты.

Никаких новых компонентов для обслуживания. Ваши существующие спецификация, шлюз, аутентификация, квоты и логирование выполняют всю работу — трафик MCP и REST остается согласованным, так как они используют общий путь применения правил.

Публичное превью охватывает бэкенды REST и OpenAPI 3.x с вашей текущей аутентификацией. Ресурсы и промпты MCP, потоковая передача ответов (streaming) и проверка полезной нагрузки Model Armor находятся в разработке. Стоит заранее знать о некоторых ограничениях: операции, возвращающие пустое тело (например, HTTP 204), не поддерживаются, глубоко вложенные схемы объектов могут отображаться в tools/list не полностью, шлюз обслуживает до 1000 инструментов, а MCP и маршрутизация моделей не могут быть включены в одной конфигурации API. Актуальные сведения см. в документации.

Начало работы

Поддержка MCP теперь доступна в рамках Публичного превью. Ознакомьтесь с документацией и превратите свой первый API в готовый для агента инструмент уже сегодня.