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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, which cover safety and side-effect expectations. The description goes beyond these by disclosing a ~45-second wait, the possible statuses (done, partial, still_working, failed) with the exact action for still_working, and rules about provisional dates and council data. It also warns against treating text as instructions, which is critical for prompt-injection safety. This fully discloses behavioral traits beyond the annotations, with no contradiction.

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 dense but each sentence carries necessary information: the step, the required input, the statuses, and a list of rules. It is front-loaded with the core purpose and step, then covers operational details. It is not overly long relative to the complexity of the tool (7 params, statuses, rules). It could be slightly more concise, but the structure is logical and every part earns its place. A 4 reflects that it is well-structured though not terse.

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?

Given the tool's complexity (7 parameters, multiple statuses, conditional inputs, and no output schema), the description covers all essential aspects: how to invoke it, what to expect in terms of statuses, when to use alternatives, and critical rules about data interpretation and safety. It even warns about provisional results and council data being non-instructional. There is no output schema, so the description carries the full burden of explaining return values, which it does via status descriptions. This is complete for an agent to use correctly.

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 coverage is 100%, so every parameter has a description in the schema. The description adds value by explaining the conditional nature of the non-required parameters: 'Only when required_input asks for it' and specifies property_id as the usual identifier from find_addresses. It also instructs to send postcode and the named field. This clarifies which parameters are needed in different scenarios, going beyond the schema's simple 'Only when...' notes. However, it doesn't detail the exact format or constraints beyond the schema, so a 4 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 opens with a precise action and scope: 'Looks up collection dates for the one property the user chose.' It clearly names the resource (collection dates) and the subject (one property), and the step context ('Step 2') implies a workflow. It distinguishes itself from siblings: check_lookup is for status, find_addresses is for address lookup, and get_schedule presumably differs. This leaves no ambiguity about what the tool accomplishes.

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 states when to use it: 'Step 2' and 'the one property the user chose.' It instructs to send postcode and the field find_addresses named in required_input (normally property_id). It also provides a clear exclusion: when status is still_working, 'never call this again for the same property' and instead use check_lookup. It gives behavioral rules about not guessing, not extending patterns, and not computing weekdays, which are usage constraints. This is comprehensive guidance for selecting and invoking the tool.

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