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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is added context — which it supplies: the assessment is built from recorded local evidence, it is explicitly not a valuation, and price comparison falls back to a bedroom-based ballpark when floor area is absent. It does not discuss provenance freshness or uncertainty, which would have pushed it higher.

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 core purpose is front-loaded in the first clause, which is good, but the remainder is a single sprawling 60+ word enumeration of roughly fifteen evidence categories. Much of that list duplicates what the output schema presumably documents, and the run-on structure makes it hard to scan.

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?

For an 11-parameter, read-only analysis tool with a dedicated output schema and full annotation coverage, the description is complete enough: it states the input trigger, the evidence computed, the non-valuation caveat, and the fallback logic. Return-value detail is legitimately delegated to the output schema.

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 the baseline is 3; the description earns an extra point by explaining how parameters combine — floor area versus a bedroom-based ballpark for the £/m² comparison, stamp duty calculated on the asking price, and council tax taken by band. These are the levers that change the output, not restatements of the schema.

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 verb+resource are specific ('Check one listing ... against local evidence') and the scope (price vs £/m², HPI, crime, schools, planning, IMD) makes clear this is a per-listing evidence bundle, distinct from the area-level siblings like get_area_evidence_pack. It stops short of naming a sibling, so an agent must infer the boundary itself.

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?

'Check one listing the user found' implies the trigger (the user has a specific property in hand), and 'Not a valuation' sets one important expectation. But there is no explicit when-to-use/when-not guidance and no routing to alternatives (e.g. get_area_evidence_pack for area-only queries, get_home_prices for pure price checks).

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