Naveo

STEP 15 / 27

B3 TOOL-HANDLER

IMPLEMENTÁ EL HANDLER

Implementá el handler del tool transfer_credits.

SCHEMA DEL TOOL (READ-ONLY)

{
  "name": "transfer_credits",
  "description": "Transfiere créditos entre dos crewmates de la crew.",
  "parameters": {
    "type": "object",
    "properties": {
      "from_alias": { "type": "string", "description": "Alias del crewmate que envía." },
      "to_alias": { "type": "string", "description": "Alias del crewmate que recibe." },
      "amount": { "type": "number", "description": "Monto a transferir, en créditos." }
    },
    "required": ["from_alias", "to_alias", "amount"]
  }
}

ESCENARIOS · 4

Transferencia normal: 50 créditos de Em a Bru. Em tiene 200, Bru existe.

EXPECTED: ok: true, transfer_id: <id>

Destinatario no existe: 50 créditos de Em a alguien inexistente.

EXPECTED: ok: false, error con código tipo "to_not_found" o equivalente identificable

Monto negativo: -10 créditos de Em a Bru.

EXPECTED: ok: false, error con código tipo "invalid_amount"

Saldo insuficiente: Em quiere transferir 999 créditos pero solo tiene 200.

EXPECTED: ok: false, error con código tipo "insufficient_funds", incluyendo balance actual

TU CÓDIGO

369 CARACTERES

EVALUADO POR LLM-JUDGE · SIN EJECUCIÓN

MODO INVITADO

Estás viendo esta lección como invitado. Para guardar tu progreso, ganar XP y mantener tu racha, inicia sesión cuando estés listo para comprobar.

Cuesta 1 vida

El handler que el agente puede leer.

Un handler que tira excepciones es un handler que rompe la conversación. El agente recibe un crash y no sabe si:

El tool estaba caído.
Le pasó argumentos malos.
El estado del mundo cambió entre que decidió usarlo y lo invocó.

La diferencia entre un MCP que se usa y uno que se descarta es cómo maneja los casos malos. La regla:

Los errores se devuelven como datos estructurados, no como excepciones. El agente puede leer datos. No puede recuperarse de un crash.

El task

A la derecha tenés el schema de transfer_credits ya hecho, y un starter del handler que funciona en el happy path pero explota en todo lo demás.

Tu trabajo: agregar las validaciones para que cuatro escenarios diferentes terminen con un resultado limpio:

Happy path. todo válido. Devolvés ok: true.
Destinatario no existe. devolvés ok: false con error identificable.
Monto negativo. devolvés ok: false con error identificable.
Saldo insuficiente. devolvés ok: false, incluyendo cuánto hay disponible.

La estructura recomendada de error

{
  ok: false,
  error: {
    code: "insufficient_funds",
    message: "Em tiene 200 créditos, intentó transferir 999.",
    balance: 200
  }
}

code. string corto, identificable. El agente lo lee para decidir qué hacer.
message. texto humano. Lo puede mostrar al usuario o usar como contexto.
Datos extra. opcional. Acá balance ayuda al agente a sugerir un monto válido.

Sin sandbox

Este ejercicio NO ejecuta tu código. Un LLM-judge lee tu implementación y razona sobre si manejaría correctamente los cuatro escenarios. Eso significa que tu código tiene que ser leíble. variables con nombres claros, control flow obvio. El judge no ejecuta, infiere.

Tip: estructurá if-return early. Cada validación es un check + early return. Sin nesting, sin else.