Conversión de APIs REST legadas: El fin del middleware MCP con Google Cloud API Gateway
La conversión de APIs REST legadas a herramientas nativas MCP a través de Google Cloud API Gateway elimina la necesidad de servidores intermediarios en la arquitectura.
Fabiano Brito
CEO & Google Cloud Architect, Autenticare
Conversión apis rest legadas es el proceso de transformar endpoints tradicionales en herramientas nativas del Model Context Protocol (MCP) directamente en la capa de gestión de tráfico, permitiendo que los agentes de IA consuman datos corporativos sin fricciones. La adopción de la Ingeniería Agéntica en grandes corporaciones a menudo choca con la complejidad arquitectónica de conectar Modelos de Lenguaje de Gran Escala (LLMs) a los sistemas transaccionales ya establecidos.
El enfoque convencional exige el desarrollo de un servidor MCP intermediario —un middleware cuya única función es traducir las intenciones del agente en llamadas que la infraestructura comprenda. Esta topología añade latencia, duplica las reglas de seguridad y aumenta el costo de mantenimiento de la plataforma. Según el anuncio realizado por Google el 24 de septiembre de 2026, esta arquitectura fragmentada se ha vuelto obsoleta.
Google Cloud API Gateway ha introducido capacidades remotas de servidor MCP en fase de Public Preview. Esta actualización proporciona una vía rápida y segura para gestionar y exponer servicios de Cloud Run directamente a los agentes.
0
Servidores intermediarios necesarios para exponer herramientas MCP con la nueva función de API Gateway — [Google Developers Blog](https://developers.googleblog.com/en/turn-your-rest-apis-into-mcp-tools-with-google-cloud-api-gateway/)
La eliminación del servidor intermediario MCP
Para los líderes de TI y arquitectos de nube, la principal ventaja técnica de esta actualización es la drástica reducción de la complejidad en la integración de agentes. Antes de esta actualización, integrar un agente a una base de datos legada significaba implementar un servicio Node.js o Python que se registraba como un servidor MCP, recibía las invocaciones vía JSON-RPC, reautenticaba la solicitud, ejecutaba la llamada REST y, finalmente, formateaba la respuesta de vuelta para el agente.
Este enfoque es riesgoso desde el punto de vista de la seguridad. Cada middleware introducido en la arquitectura es un nuevo vector de ataque y un nuevo punto de fallo que debe ser monitoreado, actualizado y escalado en paralelo al tráfico del agente.
Con la capacidad de actuar de forma nativa como un servidor remoto MCP, Google Cloud API Gateway intercepta esta necesidad. Los desarrolladores ahora pueden exponer sus operaciones REST ya existentes como herramientas MCP listas para ser utilizadas por agentes sin tener que construir, alojar o mantener una infraestructura separada.
- • Mantenimiento de contenedores separados para servidores MCP.
- • Duplicación de lógicas de autenticación y autorización (API Keys, JWT).
- • Sincronización manual de logs y tracing distribuido.
- • Aumento en el tiempo y costo de deployment de nuevas herramientas.
- • Transcoding directo en la capa de gestión de API.
- • Reutilización inmediata de las políticas de seguridad existentes.
- • Cero infraestructura extra que alojar y monitorear.
- • Exposición configurable mediante anotaciones en la especificación OpenAPI.
Transcoding JSON-RPC y preservación de políticas de seguridad
La orquestación de herramientas por parte de agentes de IA exige protocolos estrictos de comunicación. El Model Context Protocol opera mayoritariamente con payloads estructurados y llamadas a procedimientos remotos. La ingeniería detrás de la nueva función se centra en una abstracción elegante de este proceso de comunicación.
Según la especificación técnica lanzada públicamente por Google, el API Gateway pasa a aceptar solicitudes estándar MCP JSON-RPC centralizadas en un único endpoint. Cuando un agente decide que necesita consultar una base de datos o lanzar un flujo de trabajo, envía la instrucción tools/call.
El gateway recibe esta instrucción y realiza el transcoding automático de la solicitud JSON-RPC al formato de la solicitud REST correspondiente en el backend corporativo. Tras su ejecución, también traduce la respuesta REST de vuelta a la semántica MCP.
El gran diferencial arquitectónico aquí reside en la gobernanza: este proceso ocurre manteniendo todas las políticas de seguridad existentes completamente inalteradas.
| Capa de Gobernanza | Comportamiento en API Gateway (MCP Mode) |
|---|---|
| Autenticación (JWT / API Key) | Validada de forma transparente antes del transcoding, reutilizando las políticas exactas de REST. |
| Cuotas y Rate Limiting | Permanecen activas. Las solicitudes del agente consumen la cuota preconfigurada del servicio legado. |
| Logging y Monitoreo | Los logs de ejecución mantienen el formato corporativo inalterado, preservando el rastro de auditoría. |
Esta garantía de no regresión en la seguridad es fundamental para adopciones a gran escala, enfoques que discutimos en profundidad en nuestros análisis sobre la fundación de implementaciones enterprise de agentes. Cuando el CTO sabe que el LLM no logrará evadir las cuotas de uso de la base de datos y será bloqueado si el token JWT expira, la adopción gana tracción ejecutiva inmediata.
Implementación y requisitos de OpenAPI
Transformar un legado corporativo de endpoints REST en herramientas disponibles no es automático sin la adherencia a estándares estrictos de documentación de APIs. La infraestructura en la nube exige contratos formales claros para lograr mapear los parámetros de MCP a los parámetros HTTP (Path, Query, Body).
Para habilitar el servidor MCP interno del gateway, existe un prerrequisito estricto en relación a la documentación técnica: la especificación debe estar obligatoriamente en el formato OpenAPI 3.0.x o 3.1.x.
Versiones anteriores, como OpenAPI 2.0 (anteriormente conocido como Swagger), no están soportadas nativamente por esta característica de enrutamiento. Las empresas que posean legados operando bajo la versión 2.0 deberán ejecutar la migración técnica de sus especificaciones a la versión 3.0.x o superior antes de intentar exponer las herramientas.
El flujo de anotación (Opt-in)
El control granular sobre qué se expone o no a los agentes se realiza a través de anotaciones directas en el archivo de especificación OpenAPI (YAML o JSON), eliminando configuraciones en paneles visuales fragmentados. Este modelo de infraestructura como código (IaC) favorece las canalizaciones de CI/CD.
Habilitación global en el documento
Los desarrolladores deben habilitar la exposición del servidor MCP a nivel global en el documento utilizando la anotación x-google-api-management.mcp.
Selección granular de operaciones
Cada endpoint (operación) puede ser personalizado, incluido u omitido individualmente usando la anotación específica x-google-mcp-tool.
Criterios de validación de la herramienta
Para que la anotación tenga efecto y la herramienta sea creada, la operación [necesita obligatoriamente poseer una configuración de backend y una descripción no vacía](https://developers.googleblog.com/en/turn-your-rest-apis-into-mcp-tools-with-google-cloud-api-gateway/). La descripción es vital, ya que es el texto que el agente de IA leerá para decidir si debe o no invocar la herramienta.
# Exemplo conceitual de estrutura de anotação na especificação OpenAPI 3.0.x
openapi: 3.0.3
info:
title: API Corporativa de Clientes
version: 1.0.0
x-google-api-management.mcp: true # Opt-in global
paths:
/clientes/{id}:
get:
summary: Retorna dados do cliente
description: Busca os detalhes completos de um cliente específico pelo ID. # Obrigatório não ser vazio
x-google-mcp-tool: true # Exposição da operação
x-google-backend:
address: https://backend-service.internalDescubrimiento automatizado: El rol de API Hub y Agent Registry
La creación técnica de las herramientas es solo la mitad del desafío. En grandes corporaciones, saber qué herramientas existen, cuáles están obsoletas y cuáles deben usarse para determinados flujos de datos es un problema de gobernanza (discoverability).
El ecosistema de Google Cloud aborda esto integrando el proceso a API Hub. Al conectar el gateway de APIs a este hub, el servidor MCP configurado se publica automáticamente con sus metadatos específicos de la capa MCP.
Una vez publicado, este servidor y sus respectivas herramientas de backend pasan a figurar en el Agent Registry. Esto significa que las herramientas corporativas se vuelven instantáneamente descubribles por los agentes de IA y también por los desarrolladores que las orquestan.
Este nivel de automatización en la gobernanza elimina la fricción presente en la arquitectura legada, donde los equipos de datos tenían que documentar manualmente los endpoints MCP en repositorios internos y proporcionar el host del middleware a los equipos que gestionan los LLMs. Para organizaciones que ya aprovechan estrategias de aplicaciones conectadas en el workspace, expandir esta capacidad de autodescubrimiento a sus APIs propietarias es la evolución natural de la orquestación.
De manera similar a lo que se ejecuta en integraciones más complejas con procesos asíncronos y estrategias con webhooks, centralizar las rutas y sus contratos directamente en el gateway elimina los puntos de opacidad en la arquitectura corporativa.
Perspectivas finales para la ingeniería de la nube
La conversión de APIs REST legadas por medio de administradores de API con soporte nativo al Model Context Protocol redefine el trabajo de los equipos de infraestructura.
El modelo impuesto por la Public Preview de Google Cloud API Gateway demuestra que el futuro de los agentes corporativos no se basará en la creación de más silos de aplicación (como los middlewares de Node.js aislados), sino en la adaptación del borde de la red (el gateway) para comprender las solicitudes generadas por las Inteligencias Artificiales.
La responsabilidad vuelve a recaer en los contratos de API. Una especificación OpenAPI rigurosa, debidamente anotada y que soporte políticas nativas de JWT, se convierte en el verdadero activo a largo plazo. El tráfico de agentes pasa a ser tratado como un consumidor B2B más de la infraestructura preexistente de la empresa, manteniendo los costos adicionales de infraestructura cerca de cero y garantizando un cumplimiento de seguridad hermético.
Agentes orquestando sus APIs corporativas
Implemente la conversión MCP nativa en su infraestructura de Cloud Run y elimine la deuda técnica de los middlewares intermediarios manteniendo intacta la seguridad de sus datos.
Preguntas Frecuentes
¿Qué se necesita para habilitar el servidor MCP en Google Cloud API Gateway? Es necesario contar con una especificación OpenAPI 3.0.x o 3.1.x debidamente configurada. Las versiones en OpenAPI 2.0 no están soportadas y deben migrarse obligatoriamente a las versiones más recientes antes de su exposición.
¿Cómo se manejan las reglas de autenticación y cuotas durante la conversión MCP? El API Gateway ejecuta el transcoding manteniendo las políticas originales de autenticación basadas en JWT o API Keys. Además, las cuotas de consumo y las reglas de logs de acceso permanecen activas e inalteradas ante las solicitudes del agente.
¿De qué manera los agentes y desarrolladores logran descubrir estas nuevas herramientas? Cuando el API Gateway está conectado a API Hub, el servidor MCP se publica automáticamente, enviando sus metadatos a Agent Registry. Esto hace que el inventario de herramientas sea instantáneamente descubrible y esté listo para ser orquestado.
Fuentes: