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

Annotations already cover read-only, idempotent, non-destructive and closed-world behaviour, so the bar is lower. The description still adds real operational detail beyond them: results are counts plus only the first 500 rows each, and monthly CSV links live on tarve.co.uk. It does not say what happens if the 93-day limit is exceeded.

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?

A single sentence with no filler; scope, return shape, row cap and date-window limit are all packed in and front-loaded. Every clause carries information the agent needs.

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?

With no output schema, the description takes on the return-value burden and does so reasonably: counts, capped row lists, and CSV link location. Minor gaps remain (what the 500-row truncation implies for completeness, error behaviour), but nothing essential is missing.

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 date formats are already documented. The description contributes the non-obvious rule that the two dates must be at most 93 days apart, a constraint absent from the schema and important for a valid call.

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?

States a concrete resource (organisations added to/removed from the Register of Licensed Sponsors) and a concrete scope (between two dates), which an agent can distinguish from search_sponsors or check_sponsor. It does not explicitly name a sibling or say what it is not, so it stops 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?

Usage is only implied: an agent infers this is the tool for change-over-time queries, but the description never says when to prefer it over search_sponsors or site_stats. The 93-day window is a hard constraint rather than routing guidance.

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