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

Annotations already declare read-only and idempotent, and the description adds substantial context beyond them: the data is a dated snapshot, every figure carries source, release date, obtained date, period and required attribution, and it explicitly disclaims being a valuation or financial advice. This is exactly the provenance and liability framing an agent needs before quoting figures.

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?

Six short sentences with the usage trigger front-loaded, then returns, then provenance, then guardrails. Every sentence carries distinct information (what it returns, where data comes from, what it must not be used for); nothing is redundant.

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?

No output schema exists, yet the description enumerates the return payload (rent with bedroom breakdown and annual change, median sale price, number of sales) and its provenance metadata. Combined with the safety annotations, an agent has everything needed to call and interpret the result.

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 required parameter with 100% schema coverage ('Full postcode in England, e.g. SE15 5BA'), so the schema already does the work. The description repeats the England/postcode scope but adds no format, normalization, or failure-mode detail beyond it — baseline 3.

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 verb+resource pair — returns ONS average monthly private rent for the local authority plus HM Land Registry median sale price and sales count for the postcode district. The scope ('around a postcode in England', with bedroom breakdown and annual change) is specific enough that an agent can distinguish it from sibling tools like check_address or compare_addresses.

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?

Opens with an explicit trigger ('Use when someone asks about typical rents or house prices around a postcode in England') and adds an exclusion ('Area figures only, never a valuation of one home'). It does not name a sibling alternative for single-property queries, so routing is left partly to inference.

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