Naveo

STEP 9 / 27

B1 TOOL-SCHEMA

DEFINE THE SCHEMA

Write the JSON Schema for the schedule_maintenance tool.

TOOL PURPOSE

Schedule a maintenance window for one of the ship's systems. The
handler assumes the schema has already filtered out invalid values.
So you're going to tighten the schema as much as possible so the
model CANNOT send garbage.

Parameters:
- system: one of "life_support", "comms", "propulsion", "navigation".
- severity: one of "routine", "elevated", "critical".
- duration_minutes: integer between 5 and 240.
- starts_at: ISO 8601 date-time string ("2026-05-20T03:00:00Z").
- technician_alias: string of 2 to 12 chars, letters/dashes/underscores.

EXAMPLE INVOCATIONS

schedule_maintenance(system: "comms", severity: "routine", duration_minutes: 30, starts_at: "2026-05-20T03:00:00Z", technician_alias: "em") → {ok: true, window_id: "..."}
schedule_maintenance(system: "life_support", severity: "critical", duration_minutes: 120, starts_at: "2026-05-21T22:00:00Z", technician_alias: "bru") → {ok: true, window_id: "..."}

YOUR SCHEMA

150 CHARACTERS

9 CRITERIA

GUEST MODE

You're viewing this lesson as a guest. To save your progress, earn XP, and keep your streak, sign in when you're ready to check.

Costs 1 heart

The schema is NOT just documentation. it's also validation.

When the model invokes a tool, the runtime can:

Accept the invocation if the arguments pass the schema, and let the handler do its work.
Reject it and return a validation error if the arguments violate any constraint, and let the model retry with valid values.

The second flow is way cheaper than letting the handler receive garbage and deal with it. That's why a tight schema pays double: the model learns the valid values from feedback, and your handler skips checks.

The constraints that matter

JSON Schema has more tools than people use. The ones you'll use 95% of the time:

Case	Constraint	Example
Discrete values	`enum`	`"enum": ["sms", "comms", "email"]`
Number in range	`minimum`, `maximum`	`"minimum": 0, "maximum": 100`
Integer (not float)	`type: "integer"`	use instead of `"number"` for counts
String with bounded length	`minLength`, `maxLength`	`"maxLength": 280` (tweets)
String with format	`format`	`"format": "date-time"`, `"format": "email"`, `"format": "uri"`
String with regex	`pattern`	`"pattern": "^[A-Z]{3}-\\d{4}$"` (codes like "BAY-1234")
Non-empty array	`minItems`	`"minItems": 1`

Why it matters: three consequences

The model doesn't invent values. Without enum, if you ask for severity, it'll try "high", "alta", "urgent", "critical". With enum, it sticks to the 3 you defined.
Errors are useful. "value not in enum" is very different from a handler that crashes with Cannot read property of undefined.
Your description gets shorter. Things like "the format is YYYY-MM-DD" stop being text the model can ignore and become a format: date-time that the system actually checks.

Your task

On the right you have schedule_maintenance empty. Define the 5 parameters with the right constraints. The validator checks each constraint with regex; at the end an llm-judge confirms they don't contradict the use case.

The tighter the schema, the less defensive code in the handler. The schema is the first line of defense.