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

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds substantial behavior: the fallback hierarchy (district -> local authority -> national), the ban on forecast months, the status vocabulary, the null-factor rule (never a stand-in 1.0), that exactly 1.0 is real, and that current_period trails the calendar due to registry lag.

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?

Front-loaded with the core purpose, then fallback rules, then status/edge-case semantics, then parameter notes. Dense and mostly waste-free, though the run of parenthetical clarifications and return-field enumeration makes it longer than strictly needed.

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 a read-only index tool with an output schema present, the description is nearly self-sufficient: basis, status, null handling, and provenance are all covered, removing reliance on the output schema. The only real gap is the undocumented property_type parameter.

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 coverage the description must carry params, and it documents postcode (full postcode or district), from_date (YYYY-MM-DD), and lookback_years (1-20, only affects monthly_series return size) well beyond the bare schema titles. It omits any explanation of property_type, one of four params, so it is strong but not complete.

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 precise verb+resource: computing the factor that carries a past-month price to the latest settled month of the repeat-sales house-price index. It is immediately distinguishable from siblings like market_index_series or comps_adjustments because it names the exact index basis and the carry semantics.

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 description gives context ('the same carry the valuation applies to each comparable and to the property's own last sale') and a constraint ('forecast months are never used'), which implies valuation-adjustment use. However, it never explicitly names when to choose this tool over index or valuation siblings, leaving the selection to inference.

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