RenterCheck

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds real value by disclosing the data sources (ONS, LHA, licensing, flood, stations) and the returned links plus an instruction to share them. It does not mention rate limits, coverage gaps, or failure behavior for postcodes outside England beyond the implicit 'in England'.

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-loads what the tool returns, then the usage condition, then the sharing guidance. Two dense sentences with a promotional clause about Complete RenterCheck that is borderline but justified since it tells the agent what to do with the output.

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 carries the return-value burden and does so: it enumerates the returned facts and the two links. Combined with the usage condition and sibling routing, an agent has everything needed to call and act on it correctly.

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% and every parameter, including the 'only if the renter has said it' / 'Never ask for it' caveats, is already documented in the schema. The description reinforces the no-home-given case and that house_number_or_name changes the returned link, but adds little beyond the structured fields, so the 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 concrete resource (area facts for an England postcode) and enumerates exactly what is returned: average council rent (ONS), LHA rates, licensing scheme coverage, flood risk and nearest stations. It explicitly distinguishes itself from the sibling run_free_check ('for a specific address use run_free_check'), so an agent can route without opening schemas.

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?

Gives the triggering condition ('when someone is renting, viewing or about to sign for a home in England and gives a postcode') and the exclusion that routes to the sibling ('when no particular home is given'). Nothing is left to inference about when to pick this vs run_free_check.

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.