HouseData

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

Annotations already declare readOnlyHint=true, so safety is covered; the description adds real behavioral detail beyond that: a batch cap of 50, the acceptance of ids or postcodes, MEES 2030 as the comparison threshold, and that expired certificates are flagged. It stops short of describing result shape or failure handling for large/invalid batches.

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 tight sentences, front-loaded with the operation and its constraints, ending with the usage case. No filler or 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?

For a one-parameter read-only tool with no output schema, the description covers operation, input forms, batch limit, threshold standard, and the notable output signal (expired-certificate flags), and it names the target user scenario. Only the exact result fields and behavior on oversized/invalid batches remain unstated.

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 single parameter already documents 'Property ids and/or postcodes, up to 50.' The description restates the same constraint (batch, id-or-postcode) without adding syntax, formatting, or mixed-input rules 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 (batch-check properties against MEES 2030 thresholds) and adds concrete behavior (flagging expired certificates). It is clearly distinct from domain siblings like get_epc_history in spirit, but it never explicitly says how it differs from the EPC-history or property-summary tools.

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 closing sentence gives an explicit usage context: 'Use for landlord portfolio compliance sweeps.' This tells the agent the intended scenario (portfolio-level batch compliance), but it does not name alternatives or state when a single-property tool would be better.

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 readOnlyHint annotation already declares this a safe read operation. The description adds content-level detail about what the trend covers (price growth, transaction velocity, property mix), which is useful but does not go beyond annotations on permissions, caching, rate limits, or data freshness.

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?

A single efficient sentence that front-loads the resource and enumerates the payload. No wasted words, though it is terse to the point of omitting usage context.

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 tool with one fully-documented parameter and no output schema, the description covers what data is available. It omits any return structure or when-to-use context, but nothing critical to invoking 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?

There is a single parameter and schema description coverage is 100%, so the schema fully documents the postcode/outcode format with examples. The description adds no syntax or format detail beyond that, so 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?

The description states a specific verb and resource (area market trend) and enumerates the data components (price growth, transaction velocity, property mix) sourced from the UK HPI. It is clear what the tool returns, though it does not explicitly distinguish itself from the sibling get_price_history.

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?

There is no guidance on when to use this tool versus the similarly-named get_price_history, nor any prerequisites or exclusions. The agent must infer usage from the name and description alone.

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 only declare readOnlyHint=true; the description adds real behavioral context beyond that: an API key requirement (auth prerequisite) and a live-check latency warning with an explicit anti-pattern. That is meaningful disclosure for a tool whose annotations cover only the safety profile.

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 tight sentences with zero filler, and the most important operational warning (latency, no looping) is front-loaded alongside the resource 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?

For a one-parameter read tool with no output schema, the description covers what data is returned, the auth requirement, and the latency caveat. It leaves the response shape unspecified, but that gap is minor given the tool's simplicity.

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% for the single postcode parameter, so the schema already carries the semantics. The description adds no format guidance (e.g. spacing/case of UK postcodes) beyond what the schema states, making 3 the correct baseline.

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 (Ofcom broadband and mobile coverage) scoped to a postcode, which clearly distinguishes it from sibling data tools like get_flood_risk or get_epc_history. It does not explicitly name a sibling, so it lands just short of a 5.

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?

Provides a concrete usage constraint — 'do not call it in a tight loop over many postcodes' — which tells the agent when not to use it in bulk. It does not, however, say when this tool is preferred over or combined with siblings such as get_property_summary.

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?

readOnlyHint=true already establishes a safe read, so the bar is lower. The description adds useful analysis context (floor-area jumps as red flags), but does not disclose pagination, ordering of certificates, or coverage limitations (e.g. only lodged EPCs).

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 tight sentences: the first front-loads what is returned, the second frames why it matters. No waste, though the red-flag sentence is advisory rather than strictly definitional.

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 single-parameter read-only history tool with no output schema, the description covers what is returned and one important interpretation. Minor gaps remain around ordering, pagination, and empty-history behavior, but nothing essential to invoking it 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% and the property_id parameter already documents that it is an EPC lmk-key returned by search_property. The description adds no syntax or format detail beyond what the schema provides, so the baseline of 3 is correct.

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+resource: retrieving all EPC certificates for a property over time, and enumerates the per-certificate payload (floor area, room counts, rating). Clearly distinct from sibling check_epc_compliance (compliance status) and get_planning_history (planning records).

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?

Implied context of a transaction/due-diligence workflow is present via the cash-buyer framing, but there is no explicit when-to-use versus check_epc_compliance or when the data is unavailable. No exclusions or alternatives named.

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 readOnlyHint annotation already establishes it is a safe read. The description adds non-obvious behavioral context beyond that: that river/sea and surface-water risk are reported separately, and crucially that it returns an explicit absent state rather than a misleading 'low' when EA has no data. That missing-data semantics is valuable and not derivable from 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 tight sentences, front-loaded with what is returned and then the key caveat about absent data. No filler or repetition.

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 usefully explains the return semantics (two risks reported separately, explicit absent state). The remaining detail (exact field shapes, validation when neither parameter is supplied) is left to the schema, which is reasonable for a low-complexity lookup 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?

Schema description coverage is 100%, so both postcode and property_id are already documented in the schema, including the conditional requirement and the preference for property_id. The description adds no parameter-level meaning beyond this, 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 specific verb+resource (EA flood zone and surface-water risk for a property) and clarifies the two risk types are reported separately. It is clearly distinguishable from siblings like get_broadband or get_planning_history, but it does not explicitly name or contrast with any sibling tool.

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 never states when to use this tool versus alternatives, nor any prerequisites or exclusions. Usage is only inferable from the tool name and purpose, so no real guidance is provided.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read, so the bar is lower. The description usefully discloses the determining factors (EPC rating, council tax band, tenure, income band), but does not say the result is an indicative eligibility assessment rather than a confirmed award, nor address anything about rate limits or data freshness.

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?

A single front-loaded sentence with no padding. It is a noun fragment rather than a verb-led statement, but every word contributes to identifying the resource and its determinants.

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 zero-required-param, read-only lookup with no output schema, the definition covers what the tool returns and what eligibility depends on. It omits how to interpret results (indicative vs. confirmed), the property_id-vs-postcode preference, and any country-scoping behavior, leaving gaps an agent would hit in practice.

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 only 40% (postcode and property_id documented), so the description should compensate — yet it lists 'tenure and income band' (real params) alongside 'EPC rating and council tax band,' which are not parameters at all. That mismatch risks confusing the agent about what to supply, and it never explains the country enum or the relationship between property_id and the EPC-derived inputs.

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 the specific resource — energy-efficiency and home-improvement grant schemes — and frames it as an eligibility lookup, which separates it from the data-lookup siblings (flood, broadband, price history). It lacks an explicit verb and never contrasts itself with a sibling, but the resource is unambiguous.

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?

There is no when-to-use instruction, no prerequisites, and no mention of alternatives among the ten sibling tools. The phrase 'based on EPC rating, council tax band, tenure and income band' hints at inputs but does not tell the agent when this tool is the right call.

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 declare readOnlyHint=true, so the safety profile is covered. The description adds that results include a 'rule-based' score, which signals the scoring is deterministic and not a predictive model—useful context. However, it doesn't disclose return scope (radius of 'nearby'), pagination, or what happens if neither parameter is supplied. With annotations covering safety, a 3 is appropriate.

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?

A single, efficient sentence that front-loads the core content. It could be slightly more front-loaded by leading with the primary use case, but it wastes no 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?

For a read-only lookup with 100% schema coverage and no output schema, the description is minimally adequate. It omits the spatial scope of 'nearby', how the likelihood score should be interpreted, and whether results are paginated—details an agent might need to call it correctly or interpret output.

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 fully documented in the schema, including the conditional requirement and the preference for property_id. The description adds nothing beyond the schema, so baseline 3 is correct.

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 (planning applications and decisions) and adds a distinctive element (rule-based approval-likelihood score). This clearly distinguishes it from siblings like get_flood_risk or get_area_market, though it doesn't explicitly name an alternative. The verb is implicit ('get' from the name) but the content is clear.

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?

No guidance on when to use this tool versus siblings, no prerequisites, and no mention of alternatives. An agent must infer usage from the description alone. The schema hints at postcode vs property_id preference but that's parameter-level, not tool-level guidance.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds genuine value by attributing the data to HM Land Registry, which sets expectations about coverage and freshness. It says nothing about result volume (single property vs. many postcode transactions), date-range coverage, or rate limits.

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?

A single front-loaded sentence with no filler, naming the source and the keys first. It is efficiently sized, though it is arguably so terse that the missing usage and return-shape context needed somewhere else in the 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?

With no output schema and only a readOnlyHint annotation, the description carries the burden of explaining what comes back, yet it never says whether a postcode query returns one transaction or a list, nor what fields accompany a price. The data-source attribution partially compensates, but a three-parameter lookup tool with a list-shaped result needs more.

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%, so the three parameters are fully documented in the schema and the baseline is 3. The phrase 'a property or postcode' merely echoes two of the three inputs and adds no syntax, format, or precedence detail beyond what property_id's schema entry already explains.

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 dataset ('HM Land Registry Price Paid transaction history') and the two lookup keys ('a property or postcode'), which distinguishes it from siblings like get_epc_history and get_planning_history by data source. It is not merely a restatement of the name. It lacks an explicit verb and never distinguishes itself from search_property or get_property_summary, so it stops short of a 5.

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?

There is no when-to-use guidance, no exclusions, and no named alternative among the ten siblings. The only routing hint ('Prefer this over re-supplying a postcode once you have it') lives in the property_id schema entry, not in the description. An agent must infer from the name alone when this tool beats get_property_summary.

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?

With readOnlyHint=true already declaring the safety profile, the description adds real context beyond annotations: it states an active HouseData API key is required and that non-entitled accounts get an error explaining how to upgrade. That is useful failure-mode disclosure. It stops short of describing latency, result shape or pagination.

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 with no filler; the core capability leads and the prerequisite follows. The opening is slightly dense with parenthetical field examples, but nothing feels wasted.

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 read-only lookup with no output schema, the description covers what the score means, what it flags, that remediation guidance is included, and the auth prerequisite. Output structure is left unspecified, but the conceptual return content is conveyed, which is adequate here.

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%, so the schema already documents both postcode and property_id, including the preference for property_id once known. The description adds nothing about parameters, 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?

The description gives a concrete verb and resource — it returns a PRISM consent-gap score and states exactly what it identifies (features such as extensions, conversions and floor-area changes lacking a planning/building-control record) plus that it returns remediation paths. That is far more specific than the name alone. It does not, however, name a sibling such as get_planning_history or check_epc_compliance to sharpen the boundary.

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?

Usage is implied by describing the consent-gap concept, so an agent can infer this tool is for detecting unrecorded works, but there is no explicit when-to-use or when-not-to-use statement and no routing against the many neighbouring get_* tools. The entitlement/API-key prerequisite is the only genuine usage constraint given.

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?

readOnlyHint=true already establishes the safety profile, so the bar is lower; the description adds real value by disclosing the aggregate's contents and positioning it as the entry point in a workflow. It says nothing about auth needs, rate limits, or how missing data for a property is handled, which would round it out.

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, front-loaded with the payload then the workflow hint; every clause carries information and nothing is 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?

With no output schema, the description correctly carries the burden of telling the agent what comes back, and it does so by listing the six data points. Minor gaps remain on coverage guarantees and what to do if a section is unavailable.

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% for the single property_id parameter, and the schema already explains it is the lmk-key from search_property. The description adds no syntax or format detail beyond that, so 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?

Names a specific verb and resource and enumerates the exact payload (EPC headline, last sale, flood risk, LPA, planning-risk score, council tax band), which cleanly separates it from single-domain siblings like get_flood_risk, get_price_history and get_epc_history.

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?

"Start here after disambiguating with search_property" gives explicit sequencing and names the prerequisite tool. It stops short of stating when not to use it (e.g., when full histories from get_epc_history or get_planning_history are required), so no exclusions are covered.

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?

readOnlyHint=true already covers the safety profile, and the description adds workflow behavior: results are 'candidates' needing human confirmation, and downstream tools must not run on an unconfirmed guess. It stops short of describing ambiguous or empty-result behavior, so not a full 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?

Two sentences, zero filler, with the entry-point rule front-loaded ahead of the caution. Every clause carries an instruction the agent needs.

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 single-parameter entry-point search with no output schema, the description covers the essential behavior. It omits what happens on multiple or zero matches, which would help an agent interpret results, but nothing critical to correct invocation 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% and the schema already gives a concrete example ('14 Acacia Road, CV4 7AL'). The description only restates 'address or postcode' without adding format or matching semantics, 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 and resource ('Find candidate properties') plus the input modality ('by address or postcode'). It clearly reads as the discovery/entry-point tool, distinct from the get_* siblings that appear to operate on an already-identified property.

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 explicit sequencing ('Always call this first'), a user-confirmation step before invoking other tools, and a negative instruction ('never guess which property was meant'). This is exactly the when/when-not guidance the dimension asks for.

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