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

Annotations already convey readOnly, idempotent, non-destructive behavior. The description adds a specific behavioral nuance: if facts.contract_date is provided, no current rule is applied retroactively when its historical version is missing. This goes beyond the structured annotations and gives the agent an important edge-case rule.

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 wasted words. The main purpose and output are front-loaded, and the conditional rule is given as a clear secondary point. Ideal length for a tool with an existing schema.

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?

The description lists the key outputs (missing facts, rules, temporal check, uncertainties, next step, procedural timeline) which helps the agent understand what to expect. It also covers the notable contract_date exception. Given the output schema exists and the input is a well-defined facts object, this is fairly complete, though it could elaborate on the as_of parameter or required prerequisites.

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?

Schema description coverage is 0%, so the description must compensate. It only references one parameter field (facts.contract_date) and does not explain the purpose of 'as_of' or the broader 'facts' object beyond the implicit 'structured facts'. The many fields in the schema are self-titled but lack any semantic guidance from the description.

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 uses a specific verb ('Route') with a precise resource ('un cas de colis indiqué livré mais non reçu') and enumerates the output (missing facts, possible rules, temporal control, uncertainties, next step, procedural timeline). It clearly differentiates from sibling route_* tools which target other case types (e.g., guarantee, subscription).

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 clearly states the scenario (package marked delivered but not received) and that it works from structured facts, providing clear context for when to use it. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full exclusions.

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