MCP en el edge: qué cambia cuando MCP se ejecuta de forma segura en cada POP

Los servidores de Model Context Protocol (MCP) ofrecen a los agentes de IA una forma estándar de llamar a herramientas, leer recursos e incorporar prompts de forma masiva. 

La mayoría de los servidores MCP se ejecutan en una arquitectura de nube heredada: una región, detrás de un balanceo de carga, manteniendo una sesión por cliente. Eso es razonable hasta que un agente en el otro lado del mundo realiza cuarenta llamadas a herramientas para completar una sola tarea, y cada llamada paga un viaje de ida y vuelta transcontinental dentro de su bucle de razonamiento. Esos viajes de ida y vuelta de larga distancia se acumulan rápidamente y destruyen el rendimiento de tu aplicación.

Ejecutar tu servidor MCP en Fastly Compute como un binario de WebAssembly en todos nuestros centros de datos, impulsado y protegido por nuestra plataforma global de 620+ Tbps, cambia la naturaleza de lo que MCP puede hacer por los agentes y los humanos que los controlan. Acabamos de lanzar un proyecto de ejemplo que hace exactamente eso y está listo para que tus agentes de programación lo tomen como referencia mientras modernizan tu propio stack de MCP. 

Ya no necesitas pagar por hosting especializado ni aislar el servidor en una sola región geográfica. Además, puedes probar todo el proyecto localmente con Viceroy, el tiempo de ejecución local de Compute de Fastly, antes de desplegarlo en la red. A continuación, desglosaremos cómo funciona internamente la ejecución de MCP sin estado en el edge.

Resolver la latencia donde importa: dentro del bucle del agente

Los agentes no hacen una sola llamada y se detienen. Descubren herramientas, llaman a una, leen el resultado, llaman a otra y, a veces, entran en un bucle una docena de veces antes de responder. Cada uno de esos hops está en la ruta crítica del flujo de trabajo del agente. Si alojas tu servidor MCP en una arquitectura tradicional, un desarrollador usuario final que dependa de tu servidor MCP al otro lado del mundo podría experimentar hasta 500 ms de retraso total por cada llamada, y su agente podría hacer docenas de llamadas por acción. Ese retraso se acumula rápidamente y produce una pésima experiencia del usuario final. 

En el edge, el servidor está a milisegundos de donde se origine cualquier solicitud. No hay limitaciones de una sola región de origen ni backhaul a un centro de datos local. El catálogo de herramientas, el despacho de llamadas, la verificación de autenticación: todo se gestiona en el punto de presencia más cercano. Para una carga de trabajo de un agente con muchas interacciones, reducir cientos de milisegundos de cada llamada se acumula en un bucle agéntico notablemente más rápido.

Sin estado por diseño, para que cualquier punto de presencia pueda responder

La revisión más reciente de MCP (2026-07-28) está construida para no tener estado. Esto va más en línea con las prácticas recomendadas de HTTP y nos complace apoyar a la Agentic AI Foundation en su investigación sobre este tema y futuros avances.

La diferencia notable en esta revisión es que no hay un protocolo de enlace de inicialización. Cada solicitud lleva su propia identidad y capacidades negociadas en un bloque _meta, y cualquier estado que necesite persistir entre llamadas viaja con la solicitud en lugar de residir en el servidor.

Dado que no hay ninguna sesión vinculada a una máquina, un despliegue edge sin estado resulta ahora mucho más atractivo que en especificaciones anteriores. Con esta implementación en una plataforma moderna como la de Fastly: 

• Tu servidor MCP se despliega al instante en todas partes. Una solicitud puede llegar a cualquier centro de datos de Fastly en todo el mundo y procesarse correctamente.

• El escalamiento es horizontal y automático, sin retraso por inicio en frío. Fastly inicia tu servidor MCP en menos de 50 microsegundos.

• Cada solicitud se aísla de forma segura dentro de nuestro tiempo de ejecución basado en WebAssembly, lo que elimina cualquier riesgo de seguridad por vecinos ruidosos.

Obtienes la simplicidad operacional de una plataforma distribuida globalmente con un solo despliegue.

Trabajo de larga duración y de varios pasos sin mantener una conexión

"Sin estado" suele sonar incompatible con "de larga duración". Los dos mecanismos de continuación de la especificación hacen que funcione, y nuestra implementación se basa en ambos:

• Solicitudes de múltiples viajes de ida y vuelta (MRTR): una herramienta puede pausarse a mitad de la llamada para solicitar información al cliente y reanudarse más tarde. El estado en curso se sella en un token opaco que el cliente devuelve en la siguiente llamada. No se mantiene abierta ninguna conexión; cualquier instancia retoma el trabajo.

• Extensión Tasks: una herramienta que puede activar trabajos de larga duración y devolver un identificador de tarea. El cliente sondea para verificar la finalización en lugar de mantener un socket abierto durante todo el proceso. Esto se adapta bien al modelo de solicitudes de Fastly.

Ambos tokens de continuación están sellados criptográficamente con cifrado autenticado y vinculados a la identidad del autor de la llamada, de modo que el modelo "el estado viaja con la solicitud" no se convierta en una forma de falsificar o secuestrar trabajo.

El catálogo de herramientas, servido desde la caché

Las llamadas de descubrimiento y listado— server/discover, tools/list, prompts/list, resources/list — devuelven la misma respuesta a cada solicitante y rara vez cambian. Son perfectas para almacenar en caché en el edge mediante la funcionalidad de almacenamiento en caché nativo de Fastly.

El servidor marca estas respuestas con indicaciones de vigencia y alcance de la caché, para que la caché pueda entregar el catálogo de herramientas a agentes de todo el mundo sin volver a ejecutar el controlador cada vez. Todo lo que dependa de quién lo solicita se excluye automáticamente de la caché y nunca se filtra entre solicitudes.

Seguridad aplicada antes de que algo llegue a tu origen

Debido a que Fastly se ubica frente a aquello con lo que realmente se comunican tus herramientas, es el lugar adecuado para aplicar el control de acceso. Nos aseguramos de construir la siguiente funcionalidad en el prototipo:

• La autenticación se bloquea ante fallas de forma predeterminada:  una configuración incorrecta da como resultado un endpoint bloqueado o no disponible, nunca uno abierto de forma silenciosa.

• Los tokens de portador se verifican en el edge:  ES256 JWT validados con respecto a un JWKS en caché para que las solicitudes no autenticadas o con formato incorrecto se rechacen antes de que generen algún costo en los sistemas posteriores.

• La autorización tiene denegación predeterminada y está delimitada por ámbitos: quien realiza la llamada debe tener los ámbitos específicos que declara una herramienta; una herramienta que declara none no se puede llamar con autorización.

• Los cuerpos de las solicitudes se limitan antes del análisis: las obtenciones de JWKS están protegidas contra SSRF, y los errores internos se ocultan con ID de correlación para la depuración.

Una solicitud no autorizada o abusiva se detiene dentro de Fastly y nunca llega a tu backend.

Impulsado por toda la potencia de la plataforma de Fastly

El prototipo de MCP se ejecuta dentro de Fastly Compute. Esto significa que obtiene toda la resiliencia y las capacidades de la plataforma a su favor, tales como:

• inicios en frío de menos de 50 microsegundos

• aislamiento seguro mediante nuestro tiempo de ejecución de WebAssembly

• protección contra ataques de DDoS con un solo clic

• más de 620 Tbps de capacidad cuando la necesites

• colapso de solicitud para evitar un problema de thundering herd cuando tu producto se vuelva viral

La especificación sin estado de MCP y el tiempo de ejecución de Fastly se refuerzan mutuamente: el protocolo fue diseñado para que el estado pueda viajar con la solicitud, y el edge es donde ese diseño tiene éxito. Lo que antes convertía lo que normalmente es un servicio de una sola región y vinculado a sesiones en algo que está en todas partes, cerca de cada agente que lo llama.

Gobierna el tráfico de IA y agentes con ARC mediante límites de velocidad por clave, controles de gasto, logging detallado y conmutación por error automática de proveedores.

Explora cómo Fastly for AI ayuda a los equipos a construir, proteger y operar aplicaciones agénticas en el edge.

Para probarlo, consulta el proyecto en GitHub.