Pide el dato que falta en lugar de hacer fallar la llamada

Cuando una petición es válida pero está incompleta, responde exactamente con lo que todavía necesitas, en un esquema pequeño y tipado, y deja que el agente reintente desde donde se quedó en lugar de empezar de nuevo.

Por qué

Muchas peticiones fallan por algo que no es un error: el usuario no dijo cuál de dos cuentas usar, falta una elección obligatoria o la acción necesita una confirmación. Si el servidor responde con un 400 genérico, el intento termina y el agente tiene que adivinar qué falló, rehacer la petición y esperar que funcione. La revisión 2026-07-28 de MCP incorpora la alternativa al protocolo. Con las Multi Round-Trip Requests, un servidor devuelve un InputRequiredResult (resultType: "input_required") con los datos que necesita, y el cliente reintenta la petición original con las respuestas. Si las respuestas siguen incompletas, la especificación dice que el servidor debería volver a preguntar en lugar de devolver un error. El servidor puede guardar su progreso en un requestState opaco que el cliente devuelve tal cual, así que el reintento no depende de la memoria del servidor; como ese valor pasa por el cliente, la especificación exige tratarlo como controlado por un atacante y proteger su integridad con HMAC o AEAD cuando afecta a la autorización o a la lógica de negocio. A2A aplica la misma idea a nivel de tarea: una tarea puede detenerse en TASK_STATE_INPUT_REQUIRED o TASK_STATE_AUTH_REQUIRED y esperar. Hay un límite: este canal es para elecciones y valores simples, nunca para secretos. MCP prohíbe a los servidores usar la elicitación en modo formulario para pedir contraseñas, claves API, tokens de acceso o credenciales de pago.

Haz

Devuelve un resultado de tipo input-required que nombre cada valor que falta con su esquema, y firma cualquier estado que devuelvas al cliente.

No hagas

Convertir una elección que falta en un error que termina el intento, ni pedir una contraseña o un número de tarjeta por esta vía.

Artefacto

{
  "resultType": "input_required",
  "inputRequests": {
    "github_login": {
      "method": "elicitation/create",
      "params": {
        "mode": "form",
        "message": "Please provide your GitHub username",
        "requestedSchema": {
          "type": "object",
          "properties": { "name": { "type": "string" } },
          "required": ["name"]
        }
      }
    }
  },
  "requestState": "AEAD-protected blob"
}

El cliente reintenta el mismo tools/call con inputResponses ({"github_login": {"action": "accept", "content": {"name": "octocat"}}}) y el mismo requestState sin modificar.