MCP sin estado, estado duradero para agentes

Un balanceador de carga no debería necesitar buena memoria. Si una herramienta MCP solo funciona cuando la siguiente solicitud llega al mismo proceso, el transporte está asumiendo por accidente parte de la arquitectura de la aplicación.

La versión 2026-07-28 de MCP hace que sea más difícil ignorar esa separación. El núcleo del protocolo utiliza solicitudes autocontenidas y capacidades definidas para cada solicitud. El trabajo de negocio de larga duración sigue necesitando estado. El cambio importante es que ahora hay que decidir dónde debe residir ese estado.

Mi recomendación es mantener los manejadores de solicitudes MCP sustituibles y hacer explícito el estado de los flujos de trabajo. Así, los equipos de backend disponen de un contrato más claro para probar, operar y proteger el sistema. Esto no les garantiza gratuitamente una ejecución exactamente una vez. Ninguna actualización del protocolo viene con ese regalo.

Qué ha cambiado realmente

La especificación de julio elimina el intercambio inicial initialize/initialized y los identificadores de sesión del protocolo en su núcleo moderno. Las solicitudes incluyen en sus metadatos la versión del protocolo, información del cliente y sus capacidades. Un cliente puede consultar server/discover para conocer el comportamiento admitido, pero el descubrimiento no es un paso inicial obligatorio.

Con Streamable HTTP, todas las solicitudes son POST. Las cabeceras MCP-Protocol-Version, Mcp-Method y, cuando corresponde, Mcp-Name reflejan información de la solicitud. El cuerpo sigue siendo la fuente de autoridad; cualquier discrepancia debe rechazarse. Enrutar según la cabecera y ejecutar una operación distinta indicada en el cuerpo convertiría una comodidad de infraestructura en una vulnerabilidad de seguridad.

Este es el contrato de la versión 2026-07-28. Siguen existiendo clientes y servidores antiguos, y una implementación compatible con ambas generaciones debe respetar el comportamiento que hayan negociado. No elimines una dependencia de sesiones heredadas solo porque el SDK más reciente permita compilar tu código.

Tres tipos de estado necesitan tres lugares distintos

Los metadatos de la solicitud indican qué admite este cliente en este momento. No son la base de datos de tus flujos de trabajo, y la información de identidad del cliente no debe confundirse con una autorización autenticada. Valida al solicitante en tu capa de autorización.

Los datos de continuación indican cómo reanudar un intercambio del protocolo. Las solicitudes de múltiples idas y vueltas (Multi Round-Trip Requests o MRTR) permiten que un servidor devuelva input_required para solicitar información adicional. El cliente responde y reintenta la operación original con los inputResponses correspondientes. La continuación debe seguir teniendo sentido aunque otro servidor gestione el reintento.

El estado de negocio registra lo que la aplicación ha hecho realmente: qué exportación se aceptó, qué registros se procesaron, qué aprobación es aplicable y dónde se encuentra el artefacto resultante. Guarda ese estado en una infraestructura cuyas reglas de persistencia y acceso controles. Trátalo como un contrato del producto, no como una consecuencia de mantener abierto un socket.

Un ejemplo concreto: una exportación que sobrevive a la solicitud

Imaginemos un agente hipotético que prepara una exportación de datos de clientes. La solicitud identifica al tenant, el conjunto de datos y la finalidad solicitada. Es posible que la herramienta necesite que una persona confirme el alcance antes de comenzar. Tras esa confirmación, la exportación podría tardar varios minutos. Nada de esto debería depender de que un proceso de trabajo web concreto permanezca activo.

Utiliza MRTR para intercambiar la información que falta. Mantén la confirmación pendiente vinculada a la operación exacta y al principal autorizado. Al reanudarla, vuelve a validar los permisos vigentes y el alcance confirmado. Una confirmación antigua no debería autorizar un conjunto de datos que se haya ampliado posteriormente.

Si la ejecución debe continuar de forma asíncrona, utiliza la extensión Tasks solo cuando ambas partes la admitan. La extensión incorpora un resultado de tarea y operaciones como tasks/get, tasks/update y tasks/cancel. El servidor debe crear de forma persistente una tarea antes de devolver su identificador. Tasks es una extensión opcional, no una capacidad que pueda darse por supuesta en todos los clientes MCP.

Si el cliente compatible con tu sistema no implementa Tasks, define y documenta un contrato de herramientas de trabajos a nivel de aplicación: iniciar una exportación, consultar el trabajo y recuperar su resultado. Es una decisión de diseño de tu interfaz, no una afirmación de que el núcleo del protocolo proporcione automáticamente ejecución asíncrona. Es preferible responder claramente que la capacidad no está admitida a mantener una solicitud HTTP abierta indefinidamente sin avisar.

Ejemplo ilustrativo de registro de aplicación — no es un mensaje del protocolo MCP

job_id: export_7f3
tenant_id: tenant_42
requested_by: principal_18
scope_digest: sha256(...)
operation_key: customer_export_20261103_001
status: queued | running | awaiting_review | succeeded | failed
revision: 4
result_uri: null
expires_at: ...

Este registro separa deliberadamente el trabajo de negocio de la tarea del protocolo que lo expone. Tu aplicación puede conservar un trabajo durante más tiempo del que la extensión retiene los metadatos de su tarea. Define esa relación y su política de limpieza en lugar de dar por hecho que ambos tienen el mismo ciclo de vida.

Un identificador sirve para localizar, no para autorizar

Un identificador de trabajo opaco resulta útil porque permite que cualquier manejador de solicitudes autorizado encuentre el trabajo. No debería conceder acceso solo porque el modelo lo conozca. Comprueba el tenant y el principal en cada consulta, actualización y descarga. Vincula el identificador al alcance aprobado y rechaza una solicitud de otro tenant aunque presente un ID aparentemente válido.

En el ejemplo de la exportación, haz que la clave de operación sea única dentro del tenant y del tipo de operación. Confirma de forma atómica la creación del trabajo y la intención de enviarlo a ejecución; después, permite que un worker reclame el trabajo mediante una transición de estado protegida. Son recomendaciones de ingeniería para esta aplicación, no requisitos de MCP. Hacen menos probable que un reintento tras una respuesta ambigua cree una segunda exportación.

Un ID de solicitud del protocolo sirve para correlacionar una respuesta. No lo utilices como única clave de deduplicación de negocio. Guarda la identidad de la operación de negocio antes de realizar una acción irreversible y define qué ocurre cuando el solicitante reintenta con la misma clave, pero con argumentos distintos. Rechazar esa discrepancia suele ser más fácil de razonar que adivinar qué solicitud debería prevalecer.

Modela también cuidadosamente el resultado. En la extensión Tasks, el estado completed puede contener un resultado de herramienta con isError:true; failed representa un error de ejecución JSON-RPC. El resultado de negocio debe leerse del propio resultado, no inferirse de lo tranquilizador que suena la palabra completed. Especifica también durante cuánto tiempo se conservan los resultados y qué ven los solicitantes cuando la tarea caduca.

Migra probando los fallos, no solo el escenario ideal

La prueba de migración más útil consiste en cambiar la instancia del servidor entre solicitudes. Después, repítela cambiando las credenciales, omitiendo capacidades y perdiendo respuestas. Una pequeña matriz puede revelar supuestos que las pruebas de integración habituales nunca detectan.

• Cliente moderno y servidor moderno: ejecutar sin inicialización; rechazar claramente las versiones no admitidas y probar un reintento con una versión compatible con ambos.
• Cliente compatible con ambas generaciones y servidor heredado: verificar el mecanismo de compatibilidad documentado. Un error moderno reconocido no debe interpretarse como prueba de que el servidor sea heredado.
• Discrepancia entre cabecera y cuerpo: rechazar la solicitud antes de ejecutar la herramienta; comprobar que la pasarela y el servicio interpretan la misma operación.
• Reanudación MRTR en otra instancia: aceptar la información que coincida, rechazar cambios de alcance o un principal incorrecto y garantizar que no se haya confirmado ninguna acción antes de obtener la confirmación necesaria.
• Falta de compatibilidad con Tasks o interrupción de la creación de la tarea: devolver la alternativa o el error documentado; nunca exponer un identificador de tarea que no pueda consultarse.
• Inicio duplicado, reinicio del worker y pérdida de la respuesta: recuperar el mismo trabajo de aplicación mediante su clave de operación y transiciones de estado protegidas.
• Tarea caducada y acceso revocado: explicitar la política de conservación e impedir el acceso al resultado cuando el solicitante pierda la autorización.

Evalúa estas pruebas mediante registros persistidos y efectos secundarios en sistemas posteriores. Una respuesta tranquilizadora del asistente es una prueba poco sólida de que la exportación se ejecutó una sola vez, utilizó el alcance correcto o permaneció inaccesible para otro tenant.

Ideas clave

• Mantén sustituible el procesamiento de solicitudes MCP; guarda el trabajo de negocio duradero detrás de identificadores explícitos de la aplicación.
• Separa las capacidades de cada solicitud, la continuación del protocolo y el estado de negocio. Cada elemento tiene un ciclo de vida y un límite de confianza distintos.
• Negocia explícitamente Tasks, distingue el estado de la tarea del éxito de negocio y documenta la conservación de resultados y los mecanismos alternativos.
• Prueba la reanudación entre instancias, los cambios de autorización y los reintentos ambiguos antes de eliminar los supuestos sobre sesiones heredadas.

La oferta publicada de Nieve, Generative AI & Agentic Workflows, incluye la integración segura y a medida de flujos de trabajo.

Yo haría explícito el límite del estado antes de optimizar el transporte. Una vez definidos la identidad del trabajo, la autorización y el contrato de recuperación, un endpoint MCP sin estado se convierte en un servicio corriente que puedes sustituir. Sin esa separación, solo habrás trasladado el mismo flujo de trabajo frágil detrás de un protocolo más reciente.