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

Annotations already declare this a safe, idempotent read, so the description is free to add data-quality behaviour instead — and it does: provenance categories including the important caveat that 'measured_wider_area' is an SA1/postcode figure repeated across every block in that area, plus a one-sentence 'how' per field and empty-string behaviour when not_recorded. That materially changes how an agent should interpret the numbers. It does not cover response size or limits, which keeps it below 5.

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 return payload is front-loaded and the provenance paragraph is a compact, high-value legend. The bolded rhetorical question is slightly promotional, but it is short and frames the subject quickly, so little is wasted.

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 and no annotations-level detail on returns, the description steps in and spells out the response envelope (mesh_blocks, per-entry fields) and the provenance model, and tells the agent where to get geometry. Missing pieces: units or scale for the noise score and greenness metric, and any sense of result size for large suburbs.

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?

There is a single parameter, suburb_name, with 0% schema description coverage. The description only implies that it identifies the suburb to enumerate ('for every mesh block in the suburb') and gives no format guidance — name vs code, state disambiguation, case handling. Marginal value over the bare schema, so a middle score.

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 names the resource precisely (greenness/vegetation cover and change, noise score, solar panels) and the unit of return (one entry per mesh block in a suburb, with mb_code/population/dwellings). It is distinguishable from the other mesh-block siblings by its subject matter. It stops short of naming a contrasting sibling tool, relying on the '/shapes/mesh-blocks' route note instead to separate values from geometry.

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 'Is it green and quiet?' framing implies the use case, and the pointer to '/shapes/mesh-blocks' clarifies this is values-only rather than geometry. However there is no explicit when-to-use vs when-not guidance, and no mention of neighbours such as suburbs_risks_environment or properties_risks_environment that might offer overlapping risk data.

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