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

The description usefully discloses return behavior (findings, free-report link, upsell link) and the ambiguous-match path, which the annotations don't cover. However, annotations declare readOnlyHint=false and idempotentHint=false while the description reads entirely like a side-effect-free public-data lookup, and it never explains what the non-read-only behavior is. That unexplained tension is a real transparency gap.

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 action and required inputs are front-loaded, and every sentence carries actionable content. The parenthetical inventory of Complete RenterCheck contents is slightly promotional but still informative about the returned link, so no serious bloat.

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, the description steps in and describes the return payload (findings plus two links) as well as the ambiguity-handling behavior, which is the main thing an agent needs. It omits any mention of the bedrooms parameter and does not reconcile the declared non-read-only annotation, leaving minor gaps.

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, but the description adds genuine meaning: the either/or relationship between 'address' and 'address_id', their coupling to the required postcode, and the optionality of rent. This is more than the schema alone conveys about how the parameters combine.

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 states a specific verb and resource ('Runs the free RenterCheck on one home to rent in England') and enumerates exactly what data it covers (energy certificate, flood/planning, recorded crime, sale history). It clearly distinguishes itself from find_addresses, which it names as the source of address_id, and from Complete RenterCheck, its paid counterpart.

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 concrete calling conditions: supply the postcode plus either an address_id from find_addresses or a house number/name, and include monthly rent if known. It also explains the multi-match fallback (returns choices to ask about). It does not state when to prefer this over the sibling check_rental_postcode, so no explicit exclusion is provided.

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