Preview a schedule-board job move

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotation Contradiction: the description repeatedly states 'WITHOUT writing', 'Read-only — safe to call repeatedly', yet the annotations declare `readOnlyHint: false` and `idempotentHint: false`. This directly contradicts the most important behavioral trait of the tool. Per the rubric, a contradiction with annotations forces a score of 1 despite the otherwise rich behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded, with the core purpose in the first sentence and organized sections for warnings and errors. However, it is very long and repeats some schema-supplied details such as mode semantics and technician equality. The exhaustive 409 error catalog is valuable but could be condensed or placed in referenced documentation without losing much utility.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex preview operation with no output schema, the description is remarkably complete: it covers outcome computation, cascade behavior, warning semantics, error conditions, and temporal constraints. The one significant gap is not in the text itself but in the contradictory read-only annotation, which prevents the overall definition from being fully trustworthy.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already covers all parameters at 100%, setting the baseline at 3. The description adds meaningful interpretive value by explaining that `mode` determines how later jobs are pushed back, that `technician_id` distinguishes pure time moves from manual reassigns, and that `earliest_feasible_at` should be suggested as a drop slot for infeasible moves. This goes beyond schema definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Computes (WITHOUT writing) the outcome of moving a confirmed job to a new time and/or technician.' It clearly distinguishes preview from execution by saying 'commit is a separate endpoint' and from emergency reschedule by naming the job-move context. This is unambiguous and differentiates well from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly frames the tool as a read-only preview safe for repeated calls while dragging and points to commit as a separate endpoint, giving clear situational context. It does not name the exact sibling `commitJobRequestMove`, but the intent is obvious. It also gives extensive 409 error conditions that help the agent decide whether a move is even viable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.