MCP sin estado y flujos de agente con estado en Android

Qué cambió en MCP 2026-07-28

La especificación MCP 2026-07-28 resuelve una tensión que los constructores de agentes sentimos a diario: queremos conectores fáciles de desplegar, pero los flujos reales de usuario tienen memoria, permisos y consecuencias. El resumen oficial de la especificación MCP 2026-07-28 presenta un núcleo de protocolo sin estado: las solicitudes son autocontenidas, pueden enrutarse a cualquier instancia compatible y el protocolo ya no depende de una sesión de transporte implícita para entender cada llamada.

El cambio central viene de SEP-2575 sobre MCP sin estado. La inicialización obligatoria y las suposiciones negociadas por sesión dejan paso a metadatos por solicitud. Esto favorece balanceo de carga, entornos serverless, reinicios seguros, caché de listas y despliegues más sencillos. La versión también incorpora MRTR, cabeceras de enrutamiento, listas cacheables, refuerzo de autorización y un marco de extensiones donde Tasks aparece como extensión formal.

La respuesta práctica es: MCP puede ser sin estado en el transporte y, al mismo tiempo, un agente puede mantener estado en su aplicación. Para nosotros, construyendo FoneClaw, esa separación es familiar. El conector debe recibir una solicitud clara; el host del agente debe saber qué tarea está activa, qué permiso falta, qué aprobación se concedió y qué resultado espera el usuario. La confianza del flujo Android no vive en una sesión oculta de protocolo; vive en el contrato de tarea.

El descubrimiento también entra en esta arquitectura. Un agente puede descubrir capacidades, pero descubrir no equivale a autorizar ni a ejecutar. Si necesitas profundizar en esa frontera, Agentic Resource Discovery: catálogos fiables sin confundir descubrimiento y autorización explica por qué un catálogo de recursos debe mantenerse separado de permisos y decisiones de usuario.

Cómo funciona el ciclo de solicitud MCP sin estado

En el ciclo MCP sin estado, cada solicitud lleva los metadatos necesarios para que una instancia compatible pueda atenderla. La identidad del cliente, capacidades relevantes, versión, enrutamiento y referencias explícitas sustituyen las suposiciones que antes podían vivir en una sesión. Para infraestructura, esto abre una ruta limpia: un balanceador puede enviar solicitudes a distintas instancias; una función serverless puede arrancar, responder y desaparecer; una lista de herramientas puede cachearse cuando corresponde.

La parte importante para agentes con estado está en las referencias explícitas. SEP-2567 sobre MCP sin sesión con identificadores de estado explícitos describe cómo reemplazar estado implícito de protocolo por identificadores emitidos por el servidor y reutilizados en llamadas posteriores. Ese identificador puede apuntar a un cálculo, una operación larga, una página de resultados o un recurso preparado.

Un identificador de estado ayuda a recuperar contexto técnico, pero la aplicación del agente debe completar el significado. En un teléfono, una referencia a una operación no contiene por sí misma aprobación del usuario, vigencia del permiso Android, estado actual de la pantalla ni seguridad de reintento. El host debe volver a leer el estado del dispositivo cuando una acción puede cambiar algo. También debe aplicar idempotencia: si la red falla después de una llamada, repetirla sin clave ni verificación puede duplicar efectos externos.

La regla que usamos al diseñar FoneClaw es concreta: el transporte debe ser reemplazable y escalable; el estado de tarea debe ser explícito y auditable. El servidor MCP sin estado puede ejecutar una función; el agente de IA con estado decide si esa función sigue perteneciendo a la tarea correcta, si el usuario aprobó el paso y si el teléfono está listo para aplicar el resultado.

Seis tipos de estado que debe poseer un agente telefónico

Un agente de teléfono Android necesita varios registros de estado, y ponerlos todos dentro del servidor MCP crea acoplamiento innecesario. En FoneClaw pensamos en el host del agente como dueño del estado del usuario y de la tarea. Los conectores y herramientas reciben referencias, entradas acotadas y claves de idempotencia; el host conserva la verdad operativa.

La separación entre aprobación y autenticación es esencial. Un token válido puede permitir llamar a un servicio, pero el usuario todavía debe aprobar una acción que envía un mensaje, cambia un ajuste o comparte datos. Un identificador de tarea puede apuntar a trabajo en curso, pero el teléfono debe verificar el estado actual antes de aplicar el paso. Un permiso concedido por Android puede existir, pero la tarea debe seguir mostrando qué hará con ese permiso.

Para nosotros, esta tabla es el corazón de MCP sin estado y flujos de agente con estado. El transporte no arrastra memoria implícita; el host conserva una visión clara de tarea, permiso y resultado. Identidad de agentes de IA: permisos, aprobación por herramienta y auditoría en Android amplía esta distinción entre identidad, permisos y auditoría para agentes móviles.

MCP Tasks, MRTR, elicitación y aprobaciones

MCP 2026-07-28 incorpora MRTR y un marco de extensiones. Tasks aparece como extensión formal para trabajo que puede durar más que una solicitud simple. En un agente telefónico, eso encaja con operaciones que empiezan con una intención y avanzan por etapas: preparar un borrador, consultar un recurso, esperar una elección, aplicar un ajuste o verificar un resultado.

MRTR ayuda cuando una herramienta necesita interacción adicional del usuario o del modelo durante una operación. La elicitación permite pedir información faltante de forma estructurada: qué contacto, qué SIM, qué duración, qué archivo o qué destino. Tasks puede ofrecer un identificador para seguir trabajo en curso. Estos mecanismos evitan volver a sesiones de transporte ocultas; hacen que la continuidad sea explícita.

La aprobación sigue siendo un estado de aplicación. Un task handle permite localizar una operación, pero el host debe decidir si el usuario aprobó esa acción exacta, si la aprobación caducó, si el dispositivo sigue en el mismo estado y si la operación requiere nueva revisión. Cancelación y expiración también pertenecen al contrato: una tarea que espera demasiado puede quedar pendiente, pedir confirmación de nuevo o ofrecer una ruta manual.

En FoneClaw diseñamos aprobaciones como decisiones visibles ligadas a la acción. El usuario debe entender destino, consecuencia y resultado esperado. Esta filosofía acompaña cualquier arquitectura futura basada en conectores. El transporte puede ser stateless; la decisión humana se mantiene ligada a la tarea del teléfono.

Un flujo Android con estado sobre MCP sin estado

Imaginemos un flujo de SMS visible. El usuario dice: “prepara un mensaje para Marta diciendo que llego en veinte minutos”. El host del agente crea un estado de tarea con objetivo, destinatario candidato, cuerpo del mensaje, app SMS predeterminada esperada, permisos necesarios y una clave de idempotencia. La solicitud a una herramienta compatible puede viajar por MCP como llamada autocontenida: operación, metadatos, referencia de tarea e idempotency key.

El servidor o herramienta responde con un resultado parcial: app abierta, destinatario encontrado, borrador preparado o permiso requerido. El host vuelve a leer el estado del teléfono antes del paso sensible. Si el destinatario está claro y el texto completo aparece visible, el host pide aprobación. Si hay dos Martas, doble SIM o pantalla ambigua, la tarea entra en estado de aclaración. La conversación continúa, pero la tarea conserva su propio registro.

Después de aprobar, la ejecución Android aplica la acción soportada. El host verifica el resultado: mensaje enviado, borrador guardado, acción cancelada o paso pendiente. Si la red falla entre ejecutar y recibir respuesta, la idempotency key y la verificación evitan duplicar el envío. Si Android revoca un permiso, la recuperación guía al usuario al ajuste correspondiente y permite retomar el flujo desde el paso correcto.

El mismo patrón sirve para No molestar. La intención indica duración y excepciones; la herramienta prepara el cambio; el host muestra efecto; el usuario aprueba; Android aplica; el host verifica el estado. La base actual de FoneClaw aporta una analogía práctica con continuidad en el mismo teléfono, recuperación de permisos y acciones rápidas; puedes revisar la información más reciente disponible desde la página de descarga de FoneClaw. La Asistente de IA flotante en Android: usar la pantalla actual con control explica cómo esa continuidad host-side funciona con pantalla actual y entradas del mismo teléfono.

Para llamadas, el límite entre protocolo y acción nativa merece su propio tratamiento. Llamadas telefónicas con agentes de IA: MCP frente al marcador Android desarrolla cuándo un conector ayuda y cuándo el marcador Android debe conservar la acción visible.

Escalar servidores MCP conservando fiabilidad telefónica

Un servidor MCP sin estado facilita escalar. Las instancias pueden arrancar y salir, los balanceadores pueden repartir solicitudes, las listas de herramientas pueden cachearse y los despliegues pueden actualizarse con menos afinidad de sesión. El lanzamiento MCP Go SDK v1.7.0 ofrece un ejemplo oficial de implementación para el protocolo 2026-07-28, con metadatos por solicitud, descubrimiento de servidor y rutas de compatibilidad para versiones anteriores.

La fiabilidad de un flujo telefónico exige una capa adicional. Primero, clasifica reintentos: leer estado puede repetirse con menor riesgo; enviar un SMS, iniciar una llamada o cambiar un ajuste requiere idempotencia, verificación y, a veces, compensación. Segundo, usa claves de idempotencia para acciones externas. Tercero, registra correlación: tarea, herramienta, solicitud, dispositivo, aprobación y resultado deben compartir un hilo común. Cuarto, verifica el estado del teléfono después de ejecutar.

La observabilidad importa tanto como el escalado. Un log técnico que solo dice “request ok” no basta para una tarea Android. El host necesita saber si la pantalla cambió, si el permiso faltó, si el usuario canceló, si la herramienta devolvió un resultado parcial o si el paso quedó listo para toma manual. En grabadoras con IA, el mismo principio aparece cuando una nota se convierte en acción confirmada; MCP para grabadoras con IA: de notas a acciones confirmadas aplica esa transición a otro flujo.

Escalar conectores y conservar confianza son objetivos compatibles cuando el estado correcto vive en el lugar correcto. MCP transporta la llamada; el host del agente telefónico gobierna intención, permisos, aprobación, idempotencia, verificación y recuperación.

Límites de seguridad y lista de migración

La seguridad empieza separando autenticación, autorización de servicio y aprobación de usuario. Una credencial válida permite acceder a una API; un permiso Android permite a una app realizar cierto tipo de operación; una aprobación de FoneClaw autoriza una acción concreta dentro de una tarea visible. Esos tres registros cooperan, pero cada uno responde a una pregunta distinta: quién llama, qué puede hacer técnicamente y qué aceptó el usuario para este paso.

La migración a MCP 2026-07-28 debe ser gradual. Revisa clientes y servidores, negocia versiones cuando el SDK lo permita, mueve supuestos de sesión a metadatos por solicitud, introduce handles explícitos para estado técnico, define claves de idempotencia para efectos externos y registra correlación desde la intención hasta el resultado. Conserva rutas de compatibilidad para despliegues heredados mientras los conectores adoptan el nuevo ciclo de vida.

Lista de migración para un agente telefónico:

• Mapea qué estado vive en conversación, tarea, dispositivo, aprobación, autenticación y auditoría.
• Convierte cada llamada de herramienta en una solicitud autocontenida con metadatos suficientes.
• Usa handles explícitos para operaciones largas y evita depender de memoria de sesión implícita.
• Separa aprobación de usuario y autorización técnica.
• Aplica idempotency keys a acciones con efecto externo.
• Vuelve a leer estado Android antes de ejecutar cambios sensibles.
• Define cancelación, expiración y recuperación para Tasks o tareas equivalentes.
• Registra correlación entre intención, herramienta, aprobación, resultado y error.

En FoneClaw usamos esta lectura para pensar futuros conectores con disciplina: un modelo configurado razona, herramientas gobernadas ejecutan y el host conserva el estado que importa para el usuario. La página de funciones de FoneClaw resume las capacidades actuales del producto; este playbook explica la arquitectura que exigiríamos para que un servidor MCP sin estado pueda participar en flujos Android con estado, visibles y recuperables.