Cada required es un bloqueo. cada opcional es un default.

Cuando marcás un parámetro como required, le decís al modelo: "sin esto, no llames el tool". El modelo respeta esa regla a rajatabla. Si no tiene el dato, va a preguntar al usuario, va a buscar en otra tool, o va a desistir. nunca va a inventar el campo (en general).

Eso suena bueno hasta que required cualquier cosa. Entonces:

• El modelo tiene que juntar más datos antes de invocar. más turnos.
• Cualquier ambigüedad menor bloquea la llamada entera.
• Los usuarios tienen que dar contexto que el sistema podría haber asumido por default.

Por eso required no es la opción "segura". es una decisión de producto.

Cuándo marcar required

Marcalo required solo si:

1. Sin ese dato, el handler no puede correr. Ejemplo: transfer_credits(from, to, amount). los tres son required. Sin amount, ¿qué transferimos?
2. El default seguro no existe. Si vos no podés inventar un valor por default sin riesgo, el modelo tampoco. Pasalo a required.
3. Es ambiguo no tenerlo. mark_item_low_stock sin reason deja un registro inútil para auditoría. Required de producto.

Cuándo dejarlo opcional

Dejalo opcional cuando:

1. Es un filtro o refinamiento. list_inventory_items() sin filtros devuelve todo. Eso es válido y útil.
2. Hay un default sano. Si el sistema puede asumir "todos los activos", "los últimos 30 días", "el usuario actual", esos no van a required.
3. Es metadata que ayuda pero no bloquea. notes, tags, priority cuando hay un default razonable.

El costo de cada lado

Regla práctica: lo mínimo viable en required, lo demás opcional con default explícito. Si dudás, escribilo en la description: "Si no se especifica category, devuelve todos los items activos." El modelo lee. y respeta.

A la derecha tenés seis parámetros de tools que ya viste. Arrastralos al slot correcto.