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

Los servidores 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 en la nube antigua: una sola región, detrás de un equilibrador de carga y manteniendo una sesión por cliente. Esto es razonable hasta que un agente al otro lado del mundo hace cuarenta llamadas a herramientas para completar una sola tarea, y cada llamada acarrea un trayecto de ida y vuelta transcontinental dentro de su bucle de razonamiento. Esos trayectos de ida y vuelta de larga distancia se acumulan con rapidez y arruinan el rendimiento de la 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 más de 620 Tbit/s, cambia la naturaleza de lo que MCP puede hacer por los agentes y los humanos que los controlan. Acabamos de publicar un proyecto de ejemplo que hace exactamente eso y está listo para que tus agentes de programación lo tomen como referencia a medida que modernizan tu propio stack de MCP. 

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

Resolución de 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 saltos se encuentra 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 desde la otra punta del mundo podría experimentar un retraso total de hasta 500 ms en cada llamada —y su agente podría hacer docenas de llamadas por acción—. Ese retraso se acumula rápidamente y genera una pésima experiencia de usuario final. 

En el edge, el servidor está a milisegundos de donde se origina cualquier petición. No hay ninguna limitación de una única región de origen ni backhaul a un centro de datos principal. El catálogo de herramientas, el envío de llamadas, la comprobación de autenticación: todo se gestiona en el POP más cercano. Para una carga de trabajo de un agente con mucha comunicación, arañar cientos de milisegundos en cada llamada se traduce en un bucle del agente notablemente más rápido.

Sin estado por diseño, por lo que cualquier POP puede responder

La revisión más reciente de MCP (2026-07-28) está creada para ser sin estado. Esto se alinea más con las mejores prácticas de HTTP, y agradecemos poder apoyar a la Agentic AI Foundation en su investigación sobre este y futuros avances.

La diferencia más notable en esta revisión es que no hay ningún protocolo de enlace de inicialización. Cada petición incluye su propia identidad y capacidades negociadas en un bloque _meta, y cualquier estado que deba conservarse entre llamadas viaja con la petición en lugar de permanecer en el servidor.

Dado que no hay ninguna sesión fijada a una máquina, un despliegue sin estado en el edge 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 petición puede llegar a cualquier centro de datos de Fastly en todo el mundo y gestionarse correctamente.

• El escalado es horizontal y automático, sin retrasos por arranque en frío. Fastly arranca tu servidor MCP en menos de 50 microsegundos.

• Cada petición 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 operativa 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 apoya en ambos:

• Peticiones con múltiples trayectos de ida y vuelta (MRTR): una herramienta puede pausarse a mitad de llamada para pedir datos 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.

• La extensión Tasks: una herramienta capaz de activar trabajos de larga duración y devolver un identificador de tarea. El cliente realiza sondeos para comprobar si se ha completado en lugar de mantener abierto un socket durante todo el tiempo. Esto se adapta bien al modelo de peticiones 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 de "el estado viaja con la petición" 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 todos los llamantes 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 actualidad y alcance de la caché, de modo que la caché pueda servir 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 haga la petición se excluye automáticamente de la caché y nunca se filtra entre peticiones.

Seguridad aplicada antes de que nada llegue a tu origen

Como Fastly se sitúa delante de cualquier elemento con el que realmente se comuniquen tus herramientas, es el lugar idóneo para aplicar el control de acceso. Nos aseguramos de crear la siguiente funcionalidad en el prototipo:

• La autenticación se bloquea por defecto en caso de fallo:  una configuración incorrecta da lugar a un punto de conexión bloqueado o no disponible, nunca a uno abierto de forma silenciosa.

• Los tokens Bearer se verifican en el edge:  ES256 JWT validados con un JWKS almacenado en caché, de modo que las peticiones no autenticadas o con formato incorrecto se rechazan antes de que te supongan ningún coste en los sistemas posteriores.

• La autorización se deniega por defecto y está restringida por ámbitos: quien realiza la llamada debe tener los ámbitos específicos que declara una herramienta; una herramienta que no declare ninguno no se puede invocar con autorización.

• Los cuerpos de las peticiones se limitan antes de analizarlos: las recuperaciones de JWKS están protegidas contra SSRFy los errores internos se ocultan con ID de correlación para la depuración.

Una petición no autorizada o abusiva se detiene en Fastly y nunca llega a tu backend.

Impulsado por toda la potencia de la plataforma de Fastly

El prototipo de MCP se ejecuta en Fastly compute. Esto significa que cuenta con toda la resiliencia y las capacidades de la plataforma a su favor, como:

• arranques en frío de menos de 50 microsegundos

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

• Protección frente a ataques de DDoS con un solo clic

• +620 Tbit/s de capacidad cuando la necesites

• reducción de peticiones a una sola para evitar el problema de la estampida cuando tu producto se hace viral

La especificación MCP sin estado y el tiempo de ejecución de Fastly se refuerzan mutuamente: el protocolo se diseñó para que el estado pueda viajar con la petición, y el edge es donde ese diseño prospera. Lo que antes convertía lo que normalmente es un servicio vinculado a una sesión y a una única región en algo que está en todas partes, cerca de cada agente que lo invoca.

Gestiona el tráfico de IA y de agentes con ARC mediante límites de volumen por clave, controles de gasto, registros detallados y un sistema de recuperación automático ante fallos de los proveedores.

Descubre cómo Fastly para AI ayuda a los equipos a crear, proteger y operar aplicaciones agénticas en el edge.

Para probarlo, visita el proyecto en GitHub.