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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses a great deal the schema cannot: two distinct denominators (rate over approvals+refusals, timing over the ~13% with both dates), how withdrawals/advisory outcomes/undecided cases are bucketed under `excluded_from_rate`, London-only coverage, and a 10-credit (10p) cost. The interpretation caveat — committee behaviour nearby, not a probability for this proposal — is exactly the kind of context annotations can't carry.

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?

Open, return shape, then three bolded caveats, then coverage and cost — well front-loaded and no sentence is filler, since each caveat prevents a specific misuse. The all-caps emphasis blocks are slightly heavy, but they're earning their space rather than padding.

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?

An output schema exists, so the description needn't enumerate return fields, yet it usefully sketches rate/denominator/timing/breakdown/examples anyway, and it closes the biggest operational risk with the coverage-gap warning. The remaining hole is the three undocumented tuning parameters (radius, years, example count) that shape the answer materially.

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?

With 0% schema description coverage the description must carry the parameters, and it explains `lat`/`lon`, `lpa_code`, and `application_types` (including that values are substrings of the authority's own labels, with an example). It says nothing about `years` (10), `examples` (10), or `radius_m` (800) — the radius in particular is a meaningful, non-obvious spatial control left undocumented anywhere.

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?

It states a specific verb+resource: an aggregate planning-precedent record with approval rate, median decision days, a type breakdown, and recent examples, retrievable by point or LPA. That aggregate framing implicitly separates it from per-application siblings like planning_applications or property_planning_history, but no sibling is named to make the boundary explicit.

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?

It gives clear invocation conditions — supply `lat`/`lon` OR `lpa_code`, optionally narrow with `application_types` — plus two hard usage constraints: quote each denominator with its own n, and don't present the rate as a probability. It never names an alternative tool or says explicitly when to prefer one, which keeps it short of a 5.

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