Servidores Ecosistema
En esta página
Básico Lección 7 de 17 ≈ 35 min de lectura
Especificación 2026-07-28
Interacción con el usuario y extensiones
Especificación MCP 2026-07-28 · revisada el 2 de octubre de 2026
Cómo pide un servidor MCP lo que le falta sin poder iniciar peticiones: el patrón de varias rondas (MRTR), elicitation en modo formulario y URL, requestState, la extensión Tasks y el marco de extensiones.
Qué aprenderás
- Diseñar una tool que pide confirmación o datos al usuario con el patrón de peticiones de varias rondas
- Elegir entre elicitation en modo formulario y en modo URL, e interpretar accept, decline y cancel en cada uno
- Proteger requestState frente a manipulación y reutilización
- Decidir cuándo una operación debe ejecutarse como task y cómo se negocia una extensión
- Planificar la salida de Roots, Sampling y Logging
Contenido de la lección
- 01 El problema
- 02 Pedir sin poder preguntar: peticiones de varias rondas
- 03 Elicitation: formulario y URL
- 04 `requestState` es entrada no fiable
- 05 Operaciones largas: la extensión Tasks
- 06 El marco de extensiones
- 07 En producción
Además: quiz de comprobación y desafío práctico.
Extracto
Una agente de soporte de Nortia atiende el ticket TCK-88213: el pedido PED-2026-004812 llegó con un palé dañado y el cliente reclama. El asistente propone un abono de 184,50 EUR sobre la factura F-2026-0142 y llama a emitir_abono en nortia-facturacion. La política financiera exige dos cosas antes de mover dinero: que una persona confirme el importe y que clasifique el abono con una causa de una lista cerrada. Ninguna de las dos puede salir del modelo.
Como viste en la lección 2, el servidor solo responde. No puede iniciar peticiones, así que no tiene forma de enviar una pregunta al usuario. Hay un segundo problema: nortia-facturacion corre en varias réplicas detrás de un balanceador, y nada garantiza que la respuesta del usuario llegue a la réplica que hizo la pregunta.
Fin del extracto · la lección sigue con 6 secciones más
Artículos relacionados
Preguntas frecuentes
¿Qué es elicitation en MCP?
Es el mecanismo con el que un servidor MCP pide a la persona, por medio del cliente, un dato o una confirmación, por ejemplo que confirme un importe antes de emitir un abono. Como en la versión 2026-07-28 el servidor no puede iniciar peticiones, lo hace respondiendo resultType: "input_required" con una petición elicitation/create dentro de inputRequests, y el cliente repite la llamada original con la respuesta en inputResponses (el patrón de varias rondas o MRTR). Tiene dos modos: formulario, en el que los datos pasan por el cliente, y URL, para lo sensible, como contraseñas, tokens o un segundo factor, que el usuario introduce en una página del propio servidor.
¿Qué es `requestState` en MCP y cómo se protege?
Es una cadena opaca que el servidor incluye en una respuesta input_required para recuperar en el reintento lo que necesita, ya que la siguiente ronda puede llegar a otra réplica; el cliente tiene que devolverla tal cual, sin leerla ni modificarla. Como viaja por el cliente, fuera del control del servidor, la especificación obliga a tratarla como entrada de un posible atacante: si influye en permisos o en lógica de negocio, se protege con HMAC o con cifrado autenticado y se rechaza la que no verifique. Conviene además ligarla al usuario autenticado y a la petición original y darle una caducidad corta, para que no sirva en otra llamada.
¿Qué son las extensiones de MCP y para qué sirve la extensión Tasks?
Las extensiones son capacidades opcionales que viven fuera del core del protocolo, identificadas con un prefijo y un nombre (las oficiales empiezan por io.modelcontextprotocol), desactivadas por defecto y negociadas con el campo extensions, que el cliente incluye en las clientCapabilities de cada petición y el servidor anuncia en server/discover. Tasks (io.modelcontextprotocol/tasks) está pensada para operaciones que duran minutos: el servidor puede contestar con una task en lugar del resultado, y el cliente consulta su estado con tasks/get hasta que termina. El servidor solo puede devolver una task si el cliente declaró la extensión en esa misma petición.