Esto es el corazón del Track.

Construir un schema correcto es ingeniería. Escribir la descripción que el LLM realmente entiende es el arte. Y es donde casi todo el mundo falla.

Te dejamos el schema del tool file_incident_report ya armado a la derecha. Tu trabajo: solo la descripción.

Por qué importa tanto

El modelo no tiene contexto sobre tu sistema. No sabe:

• Si file_incident_report realmente abre un ticket (que alguien va a tener que cerrar) o si solo loguea.
• Si debería invocarlo cuando el usuario dice "tengo un problema con X" o esperar a que confirme.
• Si "registrar" un incidente para hablar de él en abstracto cuenta como usar el tool.

Cada una de esas ambigüedades te va a costar ruido en producción: tickets falsos, oncalls levantados sin razón, o lo opuesto. incidentes reales que el modelo "respondió" sin registrar.

Lo que tu descripción tiene que tener

1. Efecto persistente. "Abre un ticket en el sistema de incidentes" es distinto a "registra". Decí qué pasa después.
2. Cuándo SÍ. "Cuando el usuario reporte un problema concreto que requiera seguimiento".
3. Cuándo NO. "No usar para preguntas hipotéticas, consultas sobre incidentes anteriores, o cuando el problema ya está siendo manejado por otro tool."
4. Severity es del modelo. Si querés que use bien los niveles de severity, agregá un guía: "Marcar critical solo si hay riesgo inmediato de seguridad."

Cómo se evalúa

El validador busca tres frases clave que demuestran que la description tiene lo que necesita:

• "abre un ticket". capturás el efecto persistente.
• "cuando el usuario reporte". capturás cuándo SÍ usarlo.
• "no usar". capturás cuándo NO usarlo (límites explícitos).

No tenés que usar esas frases exactas. el validador es laxo con sinónimos cercanos. Pero las tres ideas tienen que estar.

Una buena descripción de tool se lee así: tres oraciones. Una dice qué hace. Otra cuándo usarlo. Otra cuándo no.