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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the mutation/safety profile is covered structurally. The description adds a genuinely non-obvious behavioral rule — played matches are never moved — which an agent could not infer from the annotations or schema. It still omits whether the three modes are mutually exclusive or combinable, keeping it from a 5.

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?

Two sentences, no filler, with the primary capability front-loaded ahead of the constraint. Every clause earns its place.

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 mutation tool with a rich schema and an existing output schema, the description covers the three operations and one important guardrail. The remaining gaps (mode mutual exclusivity, permission/state requirements, slot semantics) are real but secondary given the output schema carries return-value detail.

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 description maps each of the three modes to its corresponding parameter (start time → start_time, delay → delay_minutes, court/slot → move_match), which adds some meaning. But with 60% schema coverage, delay_minutes and the nested move_match fields (slot, court_name) are undocumented in both description and schema, and the description says nothing about combining or mutually excluding the three modes. Baseline 3 for partial coverage is appropriate.

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 names a specific verb (reschedule) and enumerates the three concrete operations available: shift start time, add a delay, or move a single match to a court/slot. That maps cleanly onto start_time, delay_minutes, and move_match, so an agent knows exactly what the tool does. It never names or contrasts a sibling tool, which keeps it just short of a 5.

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?

'Played matches never move' is a useful when-not condition, telling the agent this call will not affect completed matches. However, there is no guidance on when to prefer this over other scheduling-related siblings (get_schedule, generate_draw) and no stated prerequisites or tournament-state requirements. Usage is implied rather than prescribed.

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