El schema NO es solo documentación. también es validación.

Cuando el modelo invoca un tool, el runtime puede:

1. Aceptar la invocación si los argumentos pasan el schema, y dejar al handler trabajar.
2. Rechazarla y devolver un error de validación si los argumentos violan algún constraint, y dejar que el modelo re-intente con valores válidos.

El segundo flujo es mucho más barato que dejar que el handler reciba basura y la maneje. Por eso el schema ajustado paga doble: el modelo aprende los valores válidos del feedback, y tu handler se ahorra checks.

Los constraints que importan

JSON Schema tiene más herramientas de las que se usan. Las que vas a usar el 95% del tiempo:

Por qué importa: tres consecuencias

1. El modelo no inventa valores. Sin enum, si pedís severity, va a probar "high", "alta", "urgent", "critical". Con enum, se queda en los 3 que vos definiste.
2. Los errores son útiles. "value not in enum" es muy distinto a un handler que crashea con Cannot read property of undefined.
3. Tu description se vuelve más corta. Cosas como "el formato es YYYY-MM-DD" dejan de ser texto que el modelo puede ignorar y pasan a ser un format: date-time que el sistema chequea.

Tu tarea

A la derecha tenés schedule_maintenance vacío. Definí los 5 parámetros con los constraints correctos. El validador chequea cada constraint con regex; al final un llm-judge confirma que no contradigan el caso de uso.

Cuanto más apretado el schema, menos código defensivo en el handler. El schema es la primera línea de defensa.