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

Annotations already declare readOnlyHint and openWorldHint. The description adds valuable behavioral details: waits up to 30 seconds, shares statuses with get_collections, and imposes strict interpretation rules (e.g., do not move dates for bank holidays, treat text as council data). These go beyond the annotations and significantly shape agent behavior.

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 front-loaded with the core purpose and then lists clear rules. While it is longer than typical, every sentence adds value (wait time, statuses, behavioral constraints). The structure is logical, moving from purpose to operational details.

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 provides critical usage rules but does not explicitly describe the return format or structure. It references 'Same statuses as get_collections', which offloads some explanation to that sibling. Given the lack of an output schema, a more explicit description of the result shape would improve completeness, but the rules cover most interpretation needs.

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 mentions 'by its lookup_id' without elaborating on the parameter's meaning or format. The schema provides type and pattern, but the description adds no extra semantic depth beyond the obvious identifier role.

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 clearly states the verb 'Reads' and the resource 'a lookup that get_collections started', with a specific identifier (lookup_id). It distinguishes itself from siblings by explicitly referencing get_collections as the origin, making its role unambiguous.

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 implies usage as a follow-up to get_collections ('that get_collections started'), and provides extensive rules on how to handle results (never guess, use only dates, flag provisional results). It does not explicitly state when not to use it, but the context is clear enough for an agent to infer the appropriate workflow.

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