Lettance

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

Annotations already declare read-only and idempotent, and the description adds substantial context beyond them: the data is a dated snapshot, every figure carries source, release date, obtained date, period and required attribution, and it explicitly disclaims being a valuation or financial advice. This is exactly the provenance and liability framing an agent needs before quoting figures.

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?

Six short sentences with the usage trigger front-loaded, then returns, then provenance, then guardrails. Every sentence carries distinct information (what it returns, where data comes from, what it must not be used for); nothing is redundant.

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?

No output schema exists, yet the description enumerates the return payload (rent with bedroom breakdown and annual change, median sale price, number of sales) and its provenance metadata. Combined with the safety annotations, an agent has everything needed to call and interpret the result.

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?

There is a single required parameter with 100% schema coverage ('Full postcode in England, e.g. SE15 5BA'), so the schema already does the work. The description repeats the England/postcode scope but adds no format, normalization, or failure-mode detail beyond it — baseline 3.

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 verb+resource pair — returns ONS average monthly private rent for the local authority plus HM Land Registry median sale price and sales count for the postcode district. The scope ('around a postcode in England', with bedroom breakdown and annual change) is specific enough that an agent can distinguish it from sibling tools like check_address or compare_addresses.

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?

Opens with an explicit trigger ('Use when someone asks about typical rents or house prices around a postcode in England') and adds an exclusion ('Area figures only, never a valuation of one home'). It does not name a sibling alternative for single-property queries, so routing is left partly to inference.

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 readOnly, idempotent, openWorld and non-destructive, so the bar is lower, yet the description still adds real behaviour: unattributed councils return an explicit "not researched" answer rather than a guess, each result carries its source, and it disclaims legal advice. That is genuine context beyond the structured fields.

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 usage trigger, then the return payload, then constraints and disclaimer. Four dense sentences with little waste, though "Read-only" restates the readOnlyHint annotation and could be dropped.

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 does so thoroughly: it enumerates licence need, licensing schemes, register window, flood zone, conservation area, per-item sources and councilPage. Combined with the England-only and no-guessing behaviour, an agent has everything needed to call it and interpret the result.

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 both parameters are fully documented in the schema, including the household enum breakdown. The description only alludes to "household type" and adds no format or edge-case detail, so the baseline of 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 verb and resource: it checks what rules apply to a rented home at an England postcode and returns licence need, schemes, register window, flood zone and conservation area. The scope is concrete, though it never names the sibling tools (council_licensing, get_rule, search_rules) that overlap with the licensing portion of its output.

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 when someone asks what applies to a rented home at a postcode in England" gives a clear triggering condition, and "England only" bounds it. It stops short of naming an alternative or stating when another tool would be better, so no explicit exclusions.

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?

Beyond the readOnly/idempotent annotations, it discloses rate-limit accounting ('each postcode counts as one request'), the unknown-never-no data semantics, source attribution and dates per field, and a not-legal-advice disclaimer. These are exactly the behavioral traits an agent cannot infer from structured fields.

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 usage trigger, then outputs, then caveats and limits. Dense but every sentence carries information; the run-on enumeration of comparison fields is long but functionally necessary given no output schema.

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 fully enumerates the returned fields and the comparison table columns, plus data-quality semantics and rate-limit cost. An agent has everything needed to call this correctly and to interpret the response.

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 both parameters are already documented, and the description only reinforces the 2-to-4 postcode bound. The household parameter and its enum implications are never discussed in the description, so it adds little beyond 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?

States a specific verb (compare), resource (2-4 rented homes or areas in England), and scope (by postcode). It is clearly differentiated from siblings like check_address (single address) and area_market (single area) because it returns both plus a comparison table.

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 leading clause 'Use when someone wants to compare 2 to 4 rented homes or areas in England by postcode' gives a clear trigger condition and cardinality bound. It does not explicitly name alternatives like check_address or area_market for single-item lookups, so the routing guidance is implicit 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?

Annotations already establish read-only, idempotent, non-destructive and closed-world behavior, so the bar is lower. The description adds genuinely new behavioral detail beyond the annotations: the fallback response for an un-researched council (researched: false, plus region and landlord register window), which tells the agent how to handle a partial hit.

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 sentences, front-loaded with the 'Use when' trigger and then the return shape and edge case. The standalone 'Read-only.' sentence duplicates the readOnlyHint annotation and earns little, a minor bit of redundancy.

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 burden of describing return values, and it does so (wards, dates, fees, council sources) while also covering the degenerate case of an un-researched council. Nothing an agent needs 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?

Only one parameter, and schema description coverage is 100%; the schema already documents that it accepts a slug or name with the same examples. The description's 'Pass a slug such as southwark or a name such as Birmingham' largely restates the schema, so no meaningful value is added beyond the structured field.

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 names a specific resource (a council's licensing schemes in England) and a clear verb action (returns every scheme with wards, dates, fees and sources). The England/council-licensing scope is distinct enough from the rule-oriented siblings (get_rule, search_rules, check_address) that an agent can route correctly.

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 when someone asks about a council's licensing schemes in England' gives a clear triggering context. There is no explicit when-not or named alternative sibling, but the domain is narrow enough that misuse is unlikely.

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 declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description goes beyond them by disclosing the field set the agent will receive and the error behavior for unknown ids ('return an error rather than a guess'), which is real behavioral context not encoded in the annotations.

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?

Two sentences, zero filler. The usage precondition is front-loaded and the returned-field list is packed into a single clause rather than sprawling bullets.

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 compensates by enumerating the returned fields, and it covers the pre-call requirement, the safety profile, and the failure mode. An agent has everything needed to call it correctly and interpret the result.

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?

There is a single parameter and schema coverage is 100%, including a concrete example ('gas-safety-annual-check'), so the baseline is 3. The description restates where the id originates (search_rules) but adds no format, validation or lookup semantics beyond 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?

States a specific verb and resource ('get ... its full detail') and enumerates the concrete fields returned: requirement, deadline, evidence, penalty, legal basis, guidance links. It is clearly the single-record counterpart to the sibling search_rules, so an agent can separate the two without opening either 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?

The opening clause 'Use when you have a rule id from search_rules' gives the exact precondition and names the sibling that produces the input, implicitly excluding search_rules itself as the tool to call here. Nothing about when to invoke this is left to inference.

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 open-world. The description adds real substance: statuses depend on the landlord's own answers rather than documents, nothing is stored, and the output is information rather than legal advice. It also discloses the return shape, which the annotations cannot.

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 trigger condition, then argument guidance, then the return payload, then caveats. Every sentence carries distinct information, and the long return sentence is dense rather than padded.

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 21-parameter tool with no output schema, the description does the essential work: it summarises the return payload, warns that statuses rest on self-reported answers, and tells the agent how to handle partial knowledge. Minor gaps remain around failure modes, such as an unrecognised postcode or a plan the tool cannot produce.

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 baseline is 3, but the description adds meaning: only the postcode is required and every other argument is best-effort knowledge the landlord happens to have. The note that unanswered questions are returned as argument names ties the output back to the input schema, which helps the agent reason about filling a 21-parameter tool.

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?

Names a specific verb and resource: producing a 12-month plan/calendar of duties for a rented home in England, including each duty's status, date and cited rules. That clearly separates it from rule-lookup siblings like get_rule and search_rules, though no sibling is named explicitly.

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 when a landlord in England asks what is due for a rented home and when, or wants a plan or calendar for it" gives a concrete trigger and jurisdiction. It also says to supply the postcode plus whatever the landlord knows, since all other arguments are optional. It stops short of stating exclusions or naming alternatives such as get_rule or council_licensing.

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 declare readOnly, idempotent and non-destructive, so the description's 'Read-only' is partly redundant. It still adds value beyond structured fields by disclosing return content (matching rule ids with summaries) and provenance (each cited to legislation.gov.uk or GOV.UK).

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 tight sentences, front-loaded with the when-to-use clause and ending with the routing hint and safety note. No wasted words.

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?

No output schema exists, yet the description tells the agent what comes back (rule ids plus summaries). Combined with the usage and sibling routing, an agent has everything needed to call 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 description coverage is 100%, and the schema already documents the single query parameter with its own examples. The description's inline topic list is illustrative context rather than new parameter syntax, so baseline 3 is appropriate.

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 (searches) and resource (Lettance's catalogue of landlord rules), scoped to private landlords in England. It explicitly contrasts itself with sibling get_rule, so an agent can distinguish the two without opening either 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?

Opens with 'Use for general questions about...' and closes with 'Use get_rule for one rule's full detail', naming the alternative and the condition that selects it. Concrete topic examples (gas safety, deposits, EPC ratings) reinforce the intended use.

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