# AX-SYS-25: Pide el dato que falta en lugar de hacer fallar la llamada

> Orchestration and handoff · advanced · AX-SYS-25

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

```json
{
  "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.

## Fuentes

1. [MCP Specification 2026-07-28: Multi Round-Trip Requests](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr): If the client fails to send all the information requested in a previous InputRequests, and the missing information is necessary for the server to process the request, the server SHOULD respond with a new InputRequiredResult requesting the missing information again, rather than returning an error. Servers MUST treat requestState as an attacker-controlled input and, if it influences authorization, resource access, or business logic, MUST protect its integrity (e.g. HMAC or AEAD)
2. [MCP Specification 2026-07-28: Elicitation](https://modelcontextprotocol.io/specification/2026-07-28/client/elicitation): Servers MUST NOT use form mode elicitation to request sensitive information such as passwords, API keys, access tokens, or payment credentials
3. [A2A Protocol Specification](https://github.com/a2aproject/A2A/blob/main/docs/specification.md): A blocking call waits until the task reaches a terminal state or an interrupted state (TASK_STATE_INPUT_REQUIRED, TASK_STATE_AUTH_REQUIRED) before returning

---
Source: Agent Experience Principles (axprinciples.com)