RenterCheck

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds real value beyond them by enumerating the returned data (rent, LHA, licensing, flood risk, stations) and prescribing a follow-up action (share the returned links to the free property check and Complete RenterCheck). It does not mention failure behavior for non-England or malformed postcodes.

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?

Purpose and scope are front-loaded in the first clause, and the descriptive sentence is dense but earns its length by enumerating returns. The trailing call-to-action about sharing links is useful but slightly editorial, padding an otherwise tight definition.

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?

There is no output schema, so the description carries the return-value burden — and it does so thoroughly, listing every data class returned plus the links to propagate. Combined with clear usage context and alternatives, an agent has everything needed to call and act on this tool.

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?

Single parameter with 100% schema description coverage, so the schema already defines format and example ('M1 1AE'). The description only reasserts the geographic constraint ('in England') already present in the schema and adds no syntax or validation detail. Baseline 3 applies.

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 specific resource (area facts for a postcode in England for a rental scenario) and enumerates the concrete data classes returned: ONS average private rent, LHA rates, licensing scheme coverage, flood risk, nearest stations. It also explicitly distinguishes itself from the sibling run_free_check by naming the condition ('when no particular home is given').

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?

Explicit when-to-use ('someone is renting, viewing or about to sign for a home in England and gives a postcode') paired with an explicit when-not ('for a specific address use run_free_check'), naming the alternative tool directly. An agent can route between the two tools without inspecting either schema.

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

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

Annotations already cover read-only, idempotent, non-destructive and closed-world behavior, so the bar is lower. The description still adds real context: the dataset is England-only, results carry an address_id intended for run_free_check, and long lists are expected. No pagination or result-count detail is given, which keeps it below a 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?

Three short sentences, zero filler, with the scope/return-value fact and the routing condition front-loaded. Every sentence carries either scope, output linkage, or usage guidance.

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 two-parameter lookup with no output schema, the description supplies everything needed: what is returned (address_id), the geographic scope, the narrowing option, and the trigger condition. Nothing an agent needs in order to call it correctly is missing.

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 postcode and house_number_or_name are already documented in the schema, establishing a baseline of 3. The description goes beyond the schema by explaining the purpose of the optional parameter ('to narrow a long list'), which the schema's type/form note does not convey.

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 specific verb (Lists) and resource (the homes at a postcode), bounds the geography to England, and names the downstream artifact (address_id for run_free_check). This separates it cleanly from check_rental_postcode and run_free_check without opening any schema.

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?

"Use it when the renter has given a postcode but not which home" gives an explicit trigger condition, and it says when to add the optional parameter (to narrow a long list). It does not explicitly name check_rental_postcode as the alternative for an unknown/invalid postcode, so the routing is implied rather than exhaustive.

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

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.