1. ¿Por qué hace falta otra capa?
Casi todo el mundo empieza igual: hay un único servidor MCP que expone un par de herramientas; ChatGPT se conecta a él directamente por HTTPS y, en apariencia, todo es perfecto. La arquitectura aproximada se ve así:
ChatGPT → tu servidor MCP → base de datos / API externas
En la fase de «proyecto personal» esto es una opción perfectamente válida. Pero en cuanto la aplicación empieza a crecer en funcionalidades y el equipo de desarrollo a aumentar, los problemas aparecen muy rápido.
En primer lugar, el servidor MCP se convierte en un «God object». En él conviven a la vez las herramientas de selección de regalos, el checkout, la analítica y alguna otra cosa del tipo «metamos también aquí los informes». Partes de código con distintos SLA y requisitos de seguridad quedan pegadas en un mismo proceso.
En segundo lugar, ChatGPT y otros clientes se ven obligados a conocer la topología de tus servicios. Si dentro de seis meses aparece otro servidor MCP para commerce, tendrás que reconectar clientes, cambiar configs y descripciones. En vez de un «punto de entrada único», obtienes un zoo de URL.
En tercer lugar, deja de estar claro dónde implementar lo común para todos los servicios: autenticación, registro (logging), métricas, rate limiting, comprobación de tokens, localización y enrutamiento por regiones. Si repartes esto por todos los servicios MCP/Agent, tendrás mucha duplicación y comportamientos distintos en cada uno.
Para romper este acoplamiento y a la vez ocultar la complejidad interna a ChatGPT, entra en juego MCP Gateway, un gateway de red y punto de entrada único para todo el tráfico MCP.
2. Qué es MCP Gateway en el contexto de ChatGPT App
Formalmente, MCP Gateway es una capa de proxy y punto de entrada único entre los clientes MCP (ChatGPT, MCP Jam, tus herramientas internas) y tu conjunto de servicios backend: normalmente REST/HTTP‑API, microservicios, servicios de Agents, commerce‑backend, etc.
El gateway implementa el protocolo MCP hacia fuera (para ChatGPT parece un único servidor MCP) y, por dentro, llama a endpoints REST normales por HTTP/gRPC.
Ante una solicitud tools/list el gateway no proxya la llamada, sino que devuelve su propia lista de herramientas: o bien está definida en el código, o se compone desde la configuración. Cada tool está vinculada a un endpoint REST concreto y a un esquema de datos. Ante una solicitud tools/call el gateway toma el nombre de la herramienta, encuentra la ruta REST correspondiente y la invoca mediante fetch/cliente HTTP.
Esquemáticamente puede representarse así:
flowchart LR
ChatGPT["ChatGPT / modelo"] --> |MCP JSON-RPC| Gateway["MCP Gateway<br/>(único servidor MCP)"]
Gateway --> GiftAPI["Gift REST API<br/>/ microservicio de regalos"]
Gateway --> CommerceAPI["Commerce REST API<br/>/ ACP / pagos"]
Gateway --> AnalyticsAPI["Analytics Service<br/>/ eventos y métricas"]
Para ChatGPT es un único servidor: una URL, un conjunto de herramientas, un flujo de eventos. Para ti — una punta flexible de enrutamiento del tráfico hacia distintos servicios fríos y calientes.
3. MCP Gateway en la arquitectura de GiftGenius
Para evitar tanta abstracción y mostrar el gateway en un «sistema vivo», continuemos con nuestro ejemplo GiftGenius: una aplicación que sugiere regalos y puede crear pedidos mediante ACP/Instant Checkout.
En la versión simple teníamos un único servidor MCP que hacía tanto suggest_gifts como checkout_start. Ahora que la aplicación ha crecido, separamos responsabilidades:
- Gift REST API: búsqueda y recomendaciones de regalos, trabajo con el catálogo y el feed (servicio HTTP/REST normal).
- Commerce REST API: ACP, sesiones de checkout, estados de pedido, integración con el proveedor de pagos.
- Analytics Service / REST API: recogida de eventos y métricas (qué recomendaciones se abren, qué se compra).
- Servicio aparte de Agents (si hace falta): escenarios complejos de varios pasos. También accesible por HTTP/REST, no por MCP.
MCP Gateway se convierte en el punto de entrada único para todos estos componentes. Este:
- ante la solicitud tools/list devuelve una lista unificada de herramientas que él mismo describe: cada herramienta está vinculada a un endpoint REST concreto de uno de los servicios;
- ante la solicitud tools/call mira el nombre de la herramienta (params.name), determina con una tabla de enrutamiento a qué servicio REST ir y llama al método HTTP correspondiente (mediante fetch, axios, etc.).
Si llega un tools/call con el nombre suggest_gifts, el gateway llama al endpoint REST correspondiente del Gift REST API. Si es checkout_start, la solicitud irá al Commerce REST API.
Un pequeño pseudocódigo en TypeScript al estilo Express puede verse así:
// Manejador de solicitudes MCP muy simplificado
app.post("/mcp", async (req, res) => {
const mcpReq = req.body as { method: string; params?: any };
const ctx = buildContextFromHeaders(req); // auth, locale y demás.
const toolName = mcpReq.params?.name;
const backendRes = await callBackend(toolName, mcpReq, ctx);
res.json(backendRes);
});
Dentro de pickBackend puedes basarte en el nombre del método, el nombre de la herramienta, la configuración regional del usuario e incluso en la versión del servicio (para despliegues canarios y blue/green, de los que hablaremos más adelante en el módulo).
4. Responsabilidades de MCP Gateway: lo que sí hace
Ya hemos visto cómo encaja el gateway en la arquitectura de GiftGenius. Ahora dejemos claro qué responsabilidades tiene como capa separada, independientemente de la aplicación concreta. Es importante verlo como una capa de red y transversal a servicios. Su objetivo no es encargarse de la lógica de negocio de los regalos, sino resolver las tareas de infraestructura alrededor de ellos.
Enrutamiento de solicitudes
La primera función es la de enrutador. El gateway recibe una solicitud MCP y, basándose en su contenido, en el contexto del usuario y en su configuración, elige el servicio de destino.
Por ejemplo, en GiftGenius puedes definir una tabla de enrutamiento sencilla:
const TOOL_ROUTES: Record<string, "gift" | "commerce" | "analytics"> = {
suggest_gifts: "gift",
get_similar_gifts: "gift",
checkout_start: "commerce",
get_order_status: "commerce",
log_event: "analytics",
};
Y usarla así:
function pickBackend(req: McpRequest, ctx: GatewayContext): Backend {
if (req.method === "tools/list") return "aggregator";
if (req.method === "tools/call") {
const toolName = req.params?.name;
const group = TOOL_ROUTES[toolName] ?? "gift";
return group === "commerce" ? commerceBackend : giftBackend;
}
return giftBackend;
}
En nuestro caso, giftBackend, commerceBackend, analyticsBackend son servicios REST normales: cada uno tiene su URL base ("https://gift-api.internal", "https://commerce-api.internal", …). El gateway no reenvía MCP hacia dentro: descompone la llamada MCP en una solicitud HTTP al endpoint REST necesario.
Autenticación y autorización en el perímetro
La segunda función clave es proteger el perímetro. El gateway es un lugar conveniente para verificar el token, identificar al usuario, de qué organización viene y qué permisos tiene.
Puede, por ejemplo, aceptar un token OAuth de ChatGPT o de tu servidor MCP de autenticación, validarlo (preferiblemente con una biblioteca probada, no con criptografía casera) y convertirlo en un objeto de contexto manejable:
type GatewayContext = {
userId: string | null;
tenantId: string | null;
locale: string;
};
function buildContextFromHeaders(req: Request): GatewayContext {
const token = req.headers["authorization"]; // "Bearer ..."
const claims = token ? verifyJwt(token) : null;
return {
userId: claims?.sub ?? null,
tenantId: claims?.tenant ?? null,
locale: (req.headers["x-openai-locale"] as string) || "en-US",
};
}
Entonces los servicios internos backend/REST no tienen que lidiar con cabeceras HTTP en bruto y tokens, sino que reciben un context ya normalizado con userId, tenantId y locale. Las recomendaciones de la documentación de MCP lo dicen claramente: no implementes la validación de tokens «desde cero», usa bibliotecas verificadas y tokens de corta duración.
Registro, trazabilidad y métricas
La tercera función es la observabilidad. El gateway ve todas las solicitudes MCP entrantes y todas las respuestas, por lo que es el lugar ideal para poner un ID de correlación, registrar los parámetros de las herramientas (sin datos sensibles), anotar el tiempo de respuesta y el estado.
Una idea sencilla:
app.use((req, res, next) => {
const requestId = crypto.randomUUID();
(req as any).requestId = requestId;
const start = Date.now();
res.on("finish", () => {
const ms = Date.now() - start;
console.log(
`[${requestId}] ${req.method} ${req.url} -> ${res.statusCode} in ${ms}ms`
);
});
next();
});
Más adelante, en el módulo de observabilidad, podrás enviar estos datos no solo a console.log, sino a un almacén estructurado y construir paneles sobre ellos.
Control básico de carga
La cuarta, pero también importante, tarea es el control primario de la carga. En el gateway es cómodo poner contadores de llamadas por usuarios, organizaciones, herramientas y endpoints para que un cliente «desbocado» no queme tu clúster y tu presupuesto de modelos.
En este módulo de momento solo fijamos la idea: el rate limiting y las colas viven a nivel del gateway; los detalles de implementación (Redis, token buckets, leaky buckets) se verán en la siguiente lección sobre protección del perímetro.
Enriquecimiento de las solicitudes con contexto
Y, por último, el gateway es un buen lugar para convertir el contexto en bruto del cliente MCP en argumentos limpios para las herramientas internas.
Por ejemplo, ChatGPT puede pasar la configuración regional del usuario mediante openai/locale y _meta["openai/userLocation"]. El gateway puede:
- elegir el servicio regional adecuado (servidor ru, servidor en, etc.);
- añadir locale a los argumentos de la llamada de la herramienta, incluso si la propia herramienta no lo solicitó explícitamente en su JSON Schema (por ejemplo, como un campo opcional).
De forma aproximada:
function enrichToolArgs(args: any, ctx: GatewayContext) {
return {
...args,
locale: args.locale ?? ctx.locale,
tenantId: ctx.tenantId,
};
}
Como resultado, el Gift API recibe un «contexto enriquecido» y puede, por ejemplo, recuperar descripciones de regalos en ruso para "ru-RU" y en inglés para "en-US".
5. Lo que MCP Gateway NO debe hacer
Cuando un desarrollador obtiene un «lugar mágico por donde pasa todo», aparece la tentación de meter allí todo lo que antes vivía en servicios separados. Así el gateway corre el riesgo de convertirse en un monstruo.
Hay varias cosas que, por lo general, no deberían vivir en esta capa.
En primer lugar, lógica de negocio compleja. Selección de regalos, reglas de descuentos, cálculo de costes de envío, lógica de ACP: todo eso debe permanecer dentro de los servicios especializados de backend/commerce. Como mucho, el gateway puede hacer una validación ligera previa (por ejemplo, verificar que el precio no sea negativo), pero no elegir SKU ni calcular impuestos por regiones.
En segundo lugar, estado de usuario de larga duración. El gateway es un servicio típicamente stateless. Debe escalar horizontalmente sin problemas, no depender de memoria local y poder reiniciarse sin consecuencias. Si empiezas a guardar en él, por ejemplo, el estado de un asistente de checkout o el contenido temporal del carrito, pronto tendrás dolores de sincronización entre instancias.
En tercer lugar, funcionalidades específicas que es más lógico ubicar dentro de los propios servicios backend (Gift API, Commerce API). Por ejemplo, si el backend de Gift quiere cachear resultados de búsqueda de regalos, que lo haga él mismo, quizá usando Redis. El gateway no tiene por qué conocer esa optimización interna. Hablaremos por separado de la protección del perímetro, y allí subrayaremos: el gateway trata de funciones de red y transversales a servicios, no de reglas de negocio de recomendaciones.
En cuarto lugar, cálculos pesados. Si dentro del gateway empiezas a llamar a modelos LLM, a hacer transformaciones y agregaciones complejas, dejará de ser un «frente ligero» y se convertirá en otro backend grueso, difícil de escalar y depurar.
6. Gateway, localización y versiones de servicios
Ya vimos las responsabilidades básicas del gateway y lo que es mejor no meter en él. Ahora veamos un par de tareas «avanzadas» típicas que conviene resolver precisamente en esta capa: la localización y el versionado de servicios. Otra función interesante del gateway es el enrutamiento inteligente por localización y versiones de servicios.
Cuando ChatGPT llama a tu App, ya tiene una idea del idioma del usuario (openai/locale) y, a menudo, de su geolocalización (_meta["openai/userLocation"]). El gateway puede usar esta información para enviar solicitudes a los servicios backend adecuados.
Por ejemplo, se puede construir una arquitectura de «un gateway y muchos backends monolingües»:
- ru‑Gift API: solo catálogo y textos en ruso.
- en‑Gift API: solo en inglés.
- jp‑Gift API: japonés (cuando decidas conquistar el mundo).
En este caso el gateway actúa como servidor MCP para ChatGPT y, por locale y userLocation, elige el servicio interno adecuado.
De forma aproximada:
function pickGiftBackendByLocale(ctx: GatewayContext): Backend {
if (ctx.locale.startsWith("ru")) return giftRuBackend;
if (ctx.locale.startsWith("ja")) return giftJpBackend;
return giftEnBackend;
}
Ahí mismo es cómodo implementar un enrutamiento canario sencillo. En este módulo sobre arquitectura de producción proponemos usar el gateway para enviar parte del tráfico a un nuevo clúster del servicio y el resto al antiguo.
Ejemplo de canario muy tosco:
function pickGiftBackendCanary(ctx: GatewayContext): Backend {
const hash = hashUser(ctx.userId ?? "anonymous");
const bucket = hash % 100;
return bucket < 5 ? giftBackendV2 : giftBackendV1; // el 5% del tráfico va a v2
}
Así puedes desplegar con seguridad una nueva versión del Gift API, observando métricas y errores sin romper toda la producción de golpe.
7. Arquitecturas típicas: de «todo en uno» a Gateway
Antes en el curso ya viste varias opciones de arquitectura de producción para una ChatGPT App. En este módulo destacamos tres topologías básicas que bastan en el 90 % de los casos.
La primera: «todo en uno». El widget del App (Next.js), el servidor MCP, la lógica de Agents y un backend sencillo de commerce viven en un mismo servicio, a menudo en un mismo repositorio e incluso en una misma app de Vercel. Ventaja: casi no hay DevOps, el despliegue es sencillo, la latencia mínima. Desventaja: es difícil escalar partes por separado; una funcionalidad caliente puede tumbar toda la aplicación; los límites entre componentes quedan difusos.
La segunda: App + MCP Gateway + varios servicios backend. Aquí el widget de Next.js vive aparte (por ejemplo, en Vercel) y todo el tráfico MCP pasa por el Gateway, que enruta las solicitudes al Gift REST API, al Commerce REST API, al servicio de Agents, al backend de ACP y a otros. Es justo el esquema que estamos analizando ahora con GiftGenius y que vale para el 90 % de los casos reales en producción.
La tercera: lo mismo, pero en varias regiones (multi‑region), con un balanceador global delante del gateway. Así, un usuario de Europa cae en el clúster eu, uno de EE. UU. en el clúster us, y cada región se construye con el esquema «Gateway + varios servicios backend». Esto ya es para proyectos bastante grandes con audiencia global.
Para nosotros ahora no es tan importante memorizar todas las variantes como acostumbrarnos a pensar en el gateway como un componente lógico separado de la arquitectura, incluso si en las primeras etapas su papel lo desempeña, por ejemplo, un único monolito MCP o el backend de tu App.
8. Dónde vive físicamente MCP Gateway
Buena noticia: MCP Gateway no tiene por qué ser un gran servicio aparte sobre Kubernetes. La mayoría de las veces pasa por varias etapas de madurez.
A la escala más pequeña, el propio servidor MCP puede desempeñar el papel de gateway. En este caso, solo necesitas estructurar el código con cuidado: extraer en un módulo el enrutamiento, la autenticación y el logging, y la lógica de herramientas en otros. En este módulo señalamos expresamente que en sistemas pequeños las funciones de gateway pueden vivir dentro del servidor MCP o de la parte backend del App (por ejemplo, en una API route de Next.js).
El siguiente paso es un servicio independiente en Node/TypeScript. Puede ser una aplicación Express/Fastify que escuche en "/mcp" y llame hacia dentro a varios servicios HTTP. Para muchos equipos es una opción cómoda: encaja bien con las herramientas DevOps habituales.
Esqueleto sencillísimo de ese servicio:
const app = express();
app.use(express.json());
app.post("/mcp", handleMcpRequest); // aquí vive toda la magia del gateway
app.listen(4000, () => {
console.log("MCP Gateway listening on :4000");
});
En una etapa aún más madura, el gateway puede implementarse sobre soluciones gestionadas: AWS API Gateway, Cloudflare Workers/Routes, NGINX/Envoy con configuración de enrutamiento y scripts Lua/JS. Es importante entender que eso cambia la implementación, no el concepto. Arquitectónicamente, ChatGPT sigue yendo a un único punto, y el gateway se encarga de los detalles.
9. Mini ejemplo: un MCP Gateway sencillo para GiftGenius
Ya hemos visto por separado el enrutamiento, el contexto y el manejo de tools/list. Ahora juntemos todo en un ejemplo pequeño pero claro. Supongamos que tenemos dos servicios REST internos:
- GIFT_API_BASE = "https://gift-api.internal";
- COMMERCE_API_BASE = "https://commerce-api.internal".
Y un gateway al que ChatGPT accederá en "https://gateway.giftgenius.com/mcp".
Primero definimos un par de tipos:
type Backend = "gift" | "commerce";
type ToolRoute = {
backend: Backend;
method: "GET" | "POST";
path: string;
};
const TOOL_ROUTES: Record<string, ToolRoute> = {
suggest_gifts: {
backend: "gift",
method: "POST",
path: "/api/gifts/suggest",
},
checkout_start: {
backend: "commerce",
method: "POST",
path: "/api/checkout/start",
},
get_order_status: {
backend: "commerce",
method: "GET",
path: "/api/orders/status",
},
};
A continuación implementamos la selección del backend y la llamada:
async function callBackend(toolName: string, mcpReq: McpRequest, ctx: GatewayContext) {
const route = TOOL_ROUTES[toolName];
if (!route) {
throw new Error(`Unknown tool: ${toolName}`);
}
const base =
route.backend === "gift" ? GIFT_API_BASE : COMMERCE_API_BASE;
const url = base + route.path;
// args que llegaron en la llamada MCP tools/call
const args = {
...(mcpReq.params?.arguments ?? {}),
locale: ctx.locale,
};
const res = await fetch(url, {
method: route.method,
headers: { "content-type": "application/json" },
body: route.method === "POST" ? JSON.stringify(args) : undefined,
});
const data = await res.json();
// Envolvemos la respuesta del servicio REST en una respuesta MCP
return {
result: data,
} satisfies McpResponse;
}
Y por último, el handler principal, que:
- Construye el contexto a partir de cabeceras (auth, locale).
- Elige el backend.
- O bien agrega tools/list, o bien proxy a tools/call.
app.post("/mcp", async (req, res) => {
const mcpReq = req.body as McpRequest;
const ctx = buildContextFromHeaders(req);
if (mcpReq.method === "tools/list") {
// El Gateway declara las herramientas y sus esquemas
const tools = [
{
name: "suggest_gifts",
description: "Selecciona regalos por presupuesto e intereses.",
inputSchema: { /* ... JSON Schema ... */ },
},
{
name: "checkout_start",
description: "Crea un borrador de pedido e inicia el checkout.",
inputSchema: { /* ... */ },
},
// ...
];
return res.json({ result: { tools } });
}
if (mcpReq.method === "tools/call") {
const toolName = mcpReq.params?.name;
const backendRes = await callBackend(toolName, mcpReq, ctx);
return res.json(backendRes);
}
res.status(400).json({ error: { message: "Unsupported MCP method" } });
});
Es, por supuesto, un esquema simplificado, pero ya muestra las ideas clave:
- el gateway no sabe cómo el Gift API elige los regalos;
- solo enruta con cuidado, enriquece argumentos y, si quieres, registra y limita las llamadas.
10. Cómo se relaciona todo esto con los temas siguientes del módulo
MCP Gateway es una parte fundamental de todo lo que vamos a comentar en las lecciones restantes del módulo:
- En el siguiente tema hablaremos de la protección del perímetro: rate limiting, colas y backpressure. Todo esto vive ante todo a nivel del gateway, porque es él quien ve todo el tráfico entrante y puede «cortar lo sobrante» antes de que las solicitudes saturen el backend.
- Después trataremos la resiliencia: timeouts, circuit breakers, bulkheads. El gateway es el punto donde es cómodo fijar centralmente los timeouts de llamadas externas y activar/desactivar servicios problemáticos (por ejemplo, «apagar» temporalmente el Commerce API si empieza a fallar).
- Por último, al hablar de escalado y despliegue veremos el gateway como un clúster aparte que puede balancearse, desplegarse con esquemas blue/green y canary y revertirse de forma independiente de los servicios MCP internos.
En esencia, si antes pensabas «tengo un App y un servidor MCP», ahora el esquema se amplía a «tengo un App, un MCP Gateway, varios clústeres backend/Agents y un commerce‑backend». Y es el gateway el que permite no complicar la configuración para ChatGPT — sigue viendo un único punto MCP.
11. Errores típicos al trabajar con MCP Gateway
Error n.º 1: convertir el gateway en un «monstruo de negocio».
Una trampa habitual: como todo pasa por el gateway, ¿por qué no añadir allí el cálculo de descuentos, la elección de SKU, reglas complejas de categorías o la validación de cupones? Al final obtienes un servicio obeso, difícil de escalar y cambiar, y pierdes el sentido de separar Gift API, Commerce API y otros componentes especializados. Es mejor mantener el gateway como una capa de red fina y dejar lo específico del dominio dentro de los servicios de su ámbito.
Error n.º 2: almacenar en el gateway estado de usuario de larga duración.
La idea «guardemos el carrito del usuario en memoria del gateway» suena tentadora mientras tienes una sola instancia. En cuanto aparece una segunda, llega el dolor: ¿dónde está el carrito real —en la instancia A o en la B? ¿Qué pasa tras un reinicio? El gateway debe permanecer stateless: como mucho, un pequeño caché de handshakes o configs; todo el estado de sesiones y pedidos vive en la base de datos o en servicios especializados.
Error n.º 3: hacer que ChatGPT conozca la topología interna de los servicios.
Si empiezas a exponer a ChatGPT varios servidores API (por separado Gift API, por separado Commerce API) y usas el gateway «a veces», pierdes la ventaja principal: una entrada única y control centralizado. Cuando cambie la topología, tendrás que modificar la configuración en varios sitios. Es mucho más sencillo configurar una vez MCP Gateway como el endpoint oficial del App y ocultar tras él todos los cambios internos.
Error n.º 4: duplicar la lógica transversal en todos los backends.
A veces los equipos intentan implementar autenticación, rate limiting, logging y localización en cada servicio REST por separado. Como resultado, la política de permisos y límites en Gift API es una, en Commerce API es otra, y el comportamiento del App se vuelve impredecible. Justo para eso sirve el gateway: verificar el token, determinar el tenant y la locale, registrar la llamada, aplicar límites y, a partir de ahí, ir al servicio concreto.
Error n.º 5: sobrecargar el gateway con cálculos pesados y llamadas a LLM.
Técnicamente nada impide llamar desde el gateway a otro modelo LLM, hacer agregaciones complejas o operaciones batch largas. Pero esto lo convertirá rápidamente en otro backend pesado, imposible de escalar y aislar correctamente. El gateway debe permanecer rápido y predecible: como máximo una ligera transformación y enrutamiento. Todo lo pesado —dentro de los servicios REST o en colas/workers, de los que hablaremos más adelante en el módulo.
Error n.º 6: complicar la infraestructura demasiado pronto.
El extremo opuesto: montar de inmediato un clúster separado de Kubernetes, un stack de NGINX, Cloudflare Workers y un montón de configs complejas para un App pequeño de aprendizaje. No tiene sentido mientras no haya carga real ni requisitos de alta disponibilidad. Es perfectamente normal empezar con un monolito MCP o un gateway Node sencillo y solo después, conforme crezcas, separar componentes en clústeres y servicios gestionados.
GO TO FULL VERSION