MCP 2026-07-28: Transición de Protocolo Stateful a Stateless para Agentes Distribuidos

El Model Context Protocol (MCP) aborda el problema fundamental de la interoperabilidad y comunicación estandarizada entre agentes de software y servicios externos, un desafío recurrente en sistemas distribuidos. La evolución hacia un protocolo stateless en la especificación 2026-07-28 responde a la necesidad de mejorar la escalabilidad, resiliencia y eficiencia operativa en arquitecturas modernas de computación en la nube, particularmente en entornos serverless y de edge computing.

Históricamente, muchos protocolos de comunicación comenzaron con modelos stateful, inspirados en interacciones locales o sesiones de red de larga duración. Sin embargo, a medida que los sistemas distribuidos crecieron en escala y complejidad, la gestión de estado en el servidor se convirtió en un cuello de botella significativo, introduciendo desafíos en el balanceo de carga, la tolerancia a fallos, el despliegue continuo y la elasticidad. La adopción de un modelo stateless para MCP es una respuesta directa a estas limitaciones, alineándose con los principios de diseño de la World Wide Web y los servicios RESTful, que han demostrado ser altamente escalables y robustos.

Esta transición es crucial en el contexto actual de la inteligencia artificial y los sistemas de agentes autónomos, donde la interacción con múltiples herramientas y servicios es la norma. Un protocolo stateless facilita la orquestación de estos agentes, permitiendo que las solicitudes se procesen de manera independiente y que los recursos computacionales se asignen y liberen dinámicamente, optimizando el uso de recursos y reduciendo la latencia.

Arquitectura del Sistema

La arquitectura de MCP 2026-07-28 se centra en la eliminación del estado de sesión en el core del protocolo. Anteriormente, las sesiones se gestionaban mediante un intercambio initialize/initialized y un Mcp-Session-Id en las cabeceras, lo que requería afinidad de sesión (sticky sessions) en la infraestructura de balanceo de carga y complicaba los despliegues y la recuperación ante fallos. La nueva especificación elimina este handshake y la cabecera Mcp-Session-Id, haciendo que cada solicitud sea autocontenida con la versión del protocolo, identidad del cliente y capacidades.

Para manejar interacciones que previamente dependían de un stream abierto y persistente (como las 'elicitation' o solicitudes de información adicional del servidor al cliente), el nuevo protocolo introduce Multi Round-Trip Requests (MRTR). En lugar de mantener un stream, el servidor puede responder con un resultado input_required que describe la información necesaria. El cliente recolecta esta entrada y reintenta la operación con la información adicional, completando la transacción sin necesidad de estado de sesión en el transporte.

La comunicación subyacente sigue siendo JSON-RPC sobre HTTP. Sin embargo, la nueva especificación requiere las cabeceras Mcp-Method y Mcp-Name en las solicitudes HTTP. Esto permite que la infraestructura de red intermedia (gateways, balanceadores de carga, WAFs) inspeccione y enrute las solicitudes basándose en metadatos de cabecera, sin necesidad de parsear el cuerpo JSON. Esto mejora la observabilidad, la seguridad y la capacidad de aplicar políticas a nivel de método. La autorización se ha reforzado, prefiriendo clientes pre-registrados, luego Client ID Metadata Documents (CIMD) y deprecando Dynamic Client Registration (DCR). También adopta RFC 9207 para la identificación del emisor (issuer identification) y RFC 8707 para el recurso (resource) en las solicitudes de autorización y token, asegurando que los tokens sean emitidos y aceptados solo por la audiencia prevista.

import { McpServer } from "@modelcontextprotocol/server";
import { createMcpHandler } from "agents/mcp/server";
import { z } from "zod";

function createServer() {
  const server = new McpServer({
    name: "hello-server",
    version: "1.0.0",
  });

  server.registerTool(
    "hello",
    {
      description: "Return a greeting",
      inputSchema: { name: z.string().optional() },
    },
    async ({ name }) => ({
      content: [
        {
          type: "text",
          text: `Hello, ${name ?? "World"}!`,
        },
      ],
    }),
  );

  return server;
}

export default {
  fetch(request, env, ctx) {
    return createMcpHandler(createServer)(request, env, ctx);
  },
}

import { OAuthProvider } from "@cloudflare/workers-oauth-provider";

export default new OAuthProvider({
  apiRoute: "/mcp",
  apiHandler: mcpHandler,
  defaultHandler: authorizationHandler,
  authorizeEndpoint: "/authorize",
  tokenEndpoint: "/oauth/token",
  clientIdMetadataDocumentEnabled: true,
  resourceMetadata: {
    resource: "https://mcp.example.com/mcp",
    authorization_servers: ["https://mcp.example.com"],
    scopes_supported: ["mcp:read"],
  },
});

Fundamentos Teóricos

La transición de un protocolo stateful a uno stateless en MCP resuena con principios fundamentales de la computación distribuida y la arquitectura de la World Wide Web. El concepto de 'statelessness' fue un pilar en la tesis doctoral de Roy Fielding, "Architectural Styles and the Design of Network-based Software Architectures" (2000), donde se definieron los principios de REST (Representational State Transfer). Fielding argumentó que un estilo arquitectónico stateless mejora la escalabilidad, la fiabilidad y la visibilidad del sistema al eliminar la necesidad de que el servidor retenga el estado de la sesión del cliente entre solicitudes.

Este cambio también se alinea con el patrón de diseño de 'request-response' que es inherente a muchos sistemas distribuidos, donde cada interacción es atómica y no depende de interacciones previas. La introducción de Multi Round-Trip Requests (MRTR) para manejar interacciones complejas sin estado de sesión puede verse como una aplicación práctica del patrón de 'compensating transactions' o 'sagas' en sistemas distribuidos, donde una secuencia de operaciones atómicas se coordina a través de múltiples intercambios, pero sin un estado de sesión persistente a nivel de transporte. Esto permite una mayor resiliencia y flexibilidad frente a fallos parciales o reintentos.