Microburbs Australian Property Data

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

With no annotations, the description carries the behavioral burden. It discloses the free price (0¢), fuzzy token-based matching, synonym handling, ABS field-code coverage, and field count (~17k). It stops short of covering auth or rate-limit behavior, but the concrete query example and matching semantics provide solid expectation-setting.

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 description is front-loaded with the core purpose and remains information-dense throughout. The only minor redundancy is stating the free price twice: 'Free (0c)' at the start and '**Price: 0¢ per call.**' at the end.

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 simple two-parameter discovery endpoint with an output schema, the description is complete: it covers purpose, pricing, matching behavior, a worked example, available field volume, and the downstream route. The output schema handles return-value details, so nothing critical 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 the baseline is 3. The description adds value beyond the schema by explaining exactly how fuzzy matching behaves, including plural handling and Census synonyms, and by showing the verbatim `query=couples with children` scenario. This enriches both `query` and `limit` semantics.

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 opens with a specific verb and resource: 'Discover which statistical fields exist.' It then gives a concrete example and clarifies that returned field codes feed into the values route, distinguishing it from the nearby area_stats_values and area_stats_regions siblings without ambiguity.

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 clearly establishes the intended workflow: first discover field codes here, then use them with the priced `/area-stats/SAL/{suburb}/values` route. It does not explicitly name sibling tools or state when not to use them, but the routing guidance is strong enough for an agent to select it correctly.

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 no annotations, the description carries the behavioral burden. It discloses cost ('Free (0c)', 'Price: 0¢ per call') and implies a read-only list operation, but it does not explicitly state that the call has no side effects or describe rate limits beyond what the output schema already provides.

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 description is short and front-loaded, but it repeats the cost ('Free (0c)' and '**Price: 0¢ per call.**'), so not every sentence earns its place. Removing one of the price statements would make it tight.

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?

The output schema and 100% parameter coverage cover the return shape and parameters, so the description only needs to supply cost and the key use case. It does that, though the '/values' reference is slightly indirect compared to naming the sibling tool area_stats_values.

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?

Input schema already documents all three parameters (100% coverage), so the baseline applies. The description adds little parameter-specific detail; 'exact region names to pass to /values' clarifies the purpose of the output but not the parameters themselves.

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 the action ('List'), the resource ('regions that exist at a level'), and the scope ('every suburb, LGA, postcode, etc.'). It also points to the downstream use ('pass to /values'), which differentiates it from area_stats_values without needing to open that tool's 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?

Explicitly tells the agent when to call it: to discover exact region names to pass to /values. It does not spell out exclusions or name alternative tools, but the intended context is clear enough for routing.

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?

No annotations are provided, so the description carries the burden. It discloses the pricing (3¢ per call), the mode behavior switch at SAL level, and the requirement to pass fields. It doesn't mention return format or error conditions, but the output schema exists and the description adds meaningful behavioral context beyond the schema.

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 description is compact and front-loaded: it states the core purpose in the first sentence, then adds the mode detail and pricing. Every sentence earns its place, and the formatting with bold for pricing is clear.

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?

Given the tool has an output schema and 100% schema coverage, the description is complete enough for an agent to call it correctly. It covers the key behavioral nuance (mode=sa1) and pricing. It could mention that region is case-insensitive or that SA1 uses codes, but those are in the schema. Overall, adequate.

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 all parameters. The description adds the constraint that fields must be 1-5 codes from /fields, which is already in the schema. It doesn't add much beyond the schema, but the baseline 3 applies because the schema is complete.

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 ('fetch') and resource ('statistical field values for one region'), and clarifies the fields parameter. It distinguishes the SAL mode behavior, but doesn't explicitly differentiate from sibling tools like area_stats_fields or area_stats_regions, though the name and context make it reasonably 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?

The description explains when to use the tool: pass fields (1-5) from /fields to fetch. It also gives a specific usage condition for SAL level with mode=sa1. It doesn't explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to select it appropriately.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns up to 10 candidates ranked by Meilisearch score, and mentions the cost per call. It does not describe failure modes or whether the operation is read-only, but for a geocoding lookup these are less critical. The candidate limit and ranking are useful behavioral details.

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 description is concise, with purpose front-loaded, followed by usage guidance, then return and pricing details. Formatting with a line break and bold for the price improves scannability. Every sentence carries information, and there is no 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?

An output schema exists, so return structure is covered elsewhere. The description covers purpose, when to use it, candidate limit, ranking, and cost. It does not mention error handling or alternative tools, but for a simple geocoding endpoint with one parameter, the provided context is sufficient for an agent 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?

The single parameter 'address' has a schema description ('Freeform address string') with an example, giving 100% schema coverage. The description adds no additional semantics beyond restating that it is freeform and used for geocoding. Since the schema fully documents the parameter, the baseline of 3 applies; the description adds marginal value.

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 ('Resolve') and resource ('freeform address string to candidate G-NAF identifiers'). It clearly distinguishes from sibling geocode_suburb, which would handle suburb-level inputs. The purpose is unambiguous and actionable.

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?

Explicitly states when to use this tool: before calling any /v1/properties/{gnaf_id}/... route because those require a GNAF. This is clear usage context. However, it does not mention alternatives (like geocode_suburb) or when not to use it, leaving a slight gap in routing decisions.

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 no annotations provided, the description itself carries the burden of disclosing behavior. It does show that this is an autocomplete/lookup operation by the ABS SAL list and includes a per-call cost. However, it does not describe result cardinality, error behavior, or whether any side effects exist; these are left mostly to the output schema.

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 description is economical: a purposeful first sentence, a fine-grained second sentence on the critical usage path, and a one-line cost note. It front-loads the most important selection-relevant information and contains no filler or misplaced schema 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?

Given its simplicity — two params, one required, and an output schema present — the description covers the essential selection and routing information: what it matches, when to call it, and the cost. The only slight gap is the absence of an explicit statement about when the caller is given an alternative such as geocode_address, but the described use before canonical SAL endpoints is adequate.

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 input schema already documents q and state. The description primarily paraphrases the parameter semantics ('partial suburb search string' vs 'Partial suburb name') without adding details like match limiting, normalization, or state-specific behavior. This meets the baseline for high schema coverage but does not add beyond it.

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 opens with a specific verb and resource: 'Autocomplete a partial suburb search string against the ABS SAL list.' It clarifies that the tool is a search/autocomplete helper for canonical suburb names and ties it to the /v1/suburbs/{name}/... family, which differentiates it from address geocoding and other sibling 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 description explicitly states the key usage: 'Use this before calling /v1/suburbs/{name}/...' because those endpoints require a canonical SAL name. This gives the agent clear when-to-use guidance. It stops short of naming an alternative tool or saying when not to use this, but the primary routing context is strong.

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 no annotations, the description carries the behavioral burden and does usefully disclose the per-row return fields and the flat 3¢ pricing. However, it says nothing about ordering, pagination/limits, sorting, error behavior, or whether any authentication/rate-limit constraints apply, so the transparency is partial.

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 description is compact: purpose, optional filter, return shape, and cost are each stated once, front-loaded, with no filler. The cost is highlighted as a separate line, which is useful but not 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?

For a simple single-parameter list endpoint with an output schema, this is nearly complete: it states the scope, the optional filter, the row fields, and the cost. It could be slightly stronger by noting the default no-filter behavior and whether results are sorted, but those are readily inferred from 'All Australian LGAs.'

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?

The schema already documents the `state` parameter at 100% coverage, so baseline is 3. The description's mention of an optional `?state=` filter with NSW as an example adds no meaning beyond the schema; it only restates what is already there.

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 opens with 'All Australian LGAs' and specifies the return shape `{lga, state}` per row, so an agent can tell this is a list/dictionary tool. It doesn't explicitly differentiate from sibling tools like lga_profile or the various *_list endpoints, but the scope (all LGAs, optional state filter) is unambiguous enough.

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 implies when to call it: when a list of all or state-filtered LGAs is needed. It does not explicitly state when not to use it or point to alternatives such as lga_profile for detailed LGA data, leaving the selection largely 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?

There are no annotations, so the description carries the transparency burden. It usefully discloses the hierarchical quirk (chain stops before SA4) and the 3¢ per call cost. It does not explicitly state read-only behavior or rate limits, but for a simple profile lookup the key behavioral traits are covered.

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 description is two compact sentences followed by a bolded price. The core output is stated first, the caveat second, and the cost last. Every clause adds value, with 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?

An output schema exists, so return-value details are handled there. The description provides the chain endpoint, the SA4 exception, and pricing, but omits how to obtain a valid lga_name and gives no explicit usage boundaries. For a single-parameter tool this is close to adequate, but the missing guidance prevents full completeness.

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?

The schema has one parameter, lga_name, with 0% description coverage. The description never names this parameter or explains accepted values, formats, or case sensitivity. The only implicit link is the word "LGA", which does not fully compensate for the missing schema documentation.

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 clearly identifies the tool's output: "LGA's parent chain — state + GCCSA" and adds the nesting caveat that LGAs are not strictly nested in SA4. This distinguishes it from generic profile or hierarchy tools, though the wording is more noun-phrase than an explicit verb+resource.

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 is given on when to use this tool versus alternatives like lga_list, sa4_profile, or suburbs_profile. The SA4 caveat hints at one edge case but does not provide selection criteria or when-not-to-use instruction.

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?

No annotations are present, so the description carries the behavioral burden. It usefully discloses pricing, the current scope limitation, and the payload-size rationale. It does not mention error behavior, exact output format, or whether sal is a name/code, but these are less critical for a simple list-by-suburb tool.

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 description is short and well structured: core purpose first, then scope limitation with rationale, and pricing. Every sentence carries useful information with no filler.

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?

Given one parameter, full schema coverage, and an output schema, the description provides enough context for an agent to understand the tool's scope and call it. The main gap is that it does not clarify whether 'sal' should be a suburb name, a code, or a resolved identifier, but the schema's 'Suburb (SAL)' phrasing makes this mostly discoverable.

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 schema already documents 'sal' as required and as the suburb to list mesh blocks for. The description adds only that 'sal' is required 'for now', reinforcing the constraint without providing format or example details.

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 ('mesh-block codes') and a clear scope ('inside a suburb'), with the required 'sal' parameter. It does not explicitly contrast with nearby siblings such as mbs_profile or suburbs_shapes_mesh_blocks, so it is not fully differentiated.

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 clearly states that only suburb-scoped queries are currently supported ('sal is required for now') and explains why broader scopes are not yet available. However, it does not name alternative tools or say when to choose mbs_list over similar mesh-block/suburb tools.

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 no annotations, the description carries the full burden of behavioral disclosure. It mentions the price (3¢ per call) but omits other behavioral traits like read-only nature, error handling, rate limits, or response format. This is insufficient for a tool with zero annotation coverage.

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 description is a single, dense sentence that conveys the core function and includes the price. It is front-loaded with the key information and contains no filler, making it highly efficient.

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 simple one-parameter tool with an output schema, the description provides a conceptual overview but lacks usage guidance and parameter semantics. The price mention is useful but does not compensate for missing behavioral details. Overall, it is adequate but has clear 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 description coverage is 0%, and the description does not explain the mb_code parameter at all. It fails to provide any semantic guidance (format, source, or meaning) beyond the field name, leaving the agent without essential parameter context.

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 clearly identifies the tool's function: returning the upward ABS chain (SA1, SA2/3/4, GCCSA, state) and parallel admin chain (LGA, suburb, postcode) for a mesh block. This distinguishes it from sibling profile tools like sa4_profile or lga_profile, which target different geographic levels.

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 implies usage for retrieving a mesh block's parent regions but does not explicitly state when to prefer this over alternatives (e.g., sa4_profile, lga_profile). No exclusions or when-not-to-use guidance are provided, so an agent must infer the appropriate context.

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?

No annotations are provided, so the description carries the burden. It discloses that the credit balance is 'authoritative', which is a useful behavioral signal about data quality. However, it doesn't mention whether this is a read-only operation, whether it requires authentication, or what the response shape looks like. The description adds some context but leaves the safety profile implicit.

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 description is a single sentence that front-loads the action ('Return') and names both outputs. There is zero wasted text, and it is appropriately sized for a zero-parameter tool.

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-parameter tool with an output schema present, the description is mostly complete. The main gap is that it doesn't state whether this is a safe read-only call or whether it requires any special setup. Given the output schema exists, the agent can infer the return shape, but the description could be slightly more explicit about the operation's nature.

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?

The tool has zero parameters, so there is no parameter semantics burden on the description. The schema already fully covers the input side (empty properties). The description's mention of 'identity' and 'credit balance' helps the agent understand what the output will contain, which is the relevant semantic information for a parameterless 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?

The description clearly states the tool returns identity and the authoritative Autumn credit balance. It uses a specific verb ('Return') and names the two key outputs. It doesn't explicitly distinguish from siblings, but the sibling list is dominated by data-query tools, so the identity/credit-balance purpose is distinctive enough.

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 implies this is a lightweight identity/account tool, and the zero-parameter schema makes it obvious there are no inputs to prepare. However, it doesn't explicitly say when to use this versus alternatives, and there are no sibling tools with similar identity/credit purposes to contrast against. The context is clear but not explicit.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns immediately, requires no authentication, and is not metered. This is valuable behavioral context beyond what the schema shows. It doesn't describe the response format, but the output schema exists, so that gap is partially covered. The description adds meaningful behavioral traits (no auth, no metering) that an agent needs to know.

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 description is a single, tight sentence that front-loads the core behavior ('Returns immediately if the API is up') and then adds the two most important operational facts (no auth, not metered) plus concrete use cases. Every clause earns its place; there is no fluff.

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-parameter health-check tool, the description covers the essential context: what it does, when to use it, and its operational characteristics. The output schema exists, so return-value documentation is not the description's job. The only minor gap is that it doesn't explicitly state what a failure looks like (e.g., non-200 response), but that is a minor omission for a ping 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?

The tool has zero parameters, so the schema is trivially complete. The description adds no parameter-specific semantics because there are none to add. Baseline 4 for zero-parameter tools is appropriate; the description correctly implies no inputs are needed.

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 ('Returns') and resource ('API'), and clearly defines the tool's scope: a health check that returns immediately if the API is up. It distinguishes itself from the sibling 'ping_head' by describing the behavior (immediate return) and the intended use cases (load balancer, uptime monitor, status dashboard).

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 explicitly states when to use this tool: for health checks from load balancers, uptime monitors, or status dashboards. It also provides an exclusion by noting it is not metered and requires no authentication, which implies it is safe for frequent polling. This is clear guidance for an agent deciding between this and other tools.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns immediately, requires no authentication, is not metered, and is safe for polling. This is strong behavioral disclosure for a health-check tool. It doesn't mention the exact response shape, but the output schema exists and the behavior is simple enough that this is a minor 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?

Two sentences, front-loaded with the core behavior ('Returns immediately if the API is up'), followed by the key operational guarantees. Every word earns its place; no fluff or repetition of schema information.

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-parameter health-check tool with an output schema, the description is complete. It covers behavior, auth, metering, and safe usage contexts. An agent has everything it needs to decide when to call this tool and what to expect.

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?

The tool has zero parameters, so there is no parameter semantics burden. The description adds value by explaining the operational context (no auth, not metered) which is more useful than any parameter documentation would be. Baseline 4 for zero params 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?

The description states a specific verb ('Returns') and resource ('API up' status), and clearly distinguishes this from the sibling 'ping' tool by adding the 'head' semantics — immediate return, no auth, not metered. An agent can tell exactly what this tool does without opening the 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 description explicitly says when to use it: 'safe to poll from a load balancer, uptime monitor, or status dashboard without affecting your usage.' It also implicitly excludes use cases requiring authentication or metered operations. This is clear context with no ambiguity.

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?

No annotations exist, so the description carries the full burden. It discloses useful behavioral traits: results are curated, bucketed, and ordered nearest-first, plus the cost (10¢ per call). However, it does not disclose result-count limits, pagination, or data freshness/staleness. The price disclosure is a genuinely useful addition beyond structured fields, but the behavioral picture is not deeply rich.

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 functional purpose and free of filler. The functional content leads, and the pricing note follows as a compact secondary detail. Slightly off-topic for a purpose description, but the cost disclosure is useful for an agent deciding whether to call. Every sentence earns its place.

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?

This is a simple 2-parameter tool with an output schema present, so return values need no explanation. The description covers the essential semantics: content categories, scoping radius, ordering, and grouping. The term 'bucketed' is mildly ambiguous (distance buckets vs category buckets), and gnaf_id remains unexplained, but for a tool of this simplicity the description is largely sufficient.

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 50% — radius_m is fully documented (range 100–5000, default 1000) in the schema, and the description reinforces its semantic role as the search radius. However, gnaf_id is undocumented in both the schema and the description; its meaning is only inferable from the name. The description adds modest value beyond the schema but does not compensate for the gnaf_id gap.

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 clear purpose: returning curated amenities (supermarkets, green spaces, restaurants/cafes) near a property within a radius. The verb is implicit ('list'/'return') but the specific categories and scope make the purpose clear. It distinguishes itself from nearby siblings like properties_schools_nearby and properties_transport_nearby by naming its content categories, though it never names a sibling 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?

The categories (supermarkets, green spaces, restaurants/cafes) implicitly signal when this tool applies versus siblings like properties_schools_nearby or properties_transport_nearby, but there is no explicit when-to-use/when-not-to-use guidance, no named alternatives, and no mention of what it does NOT cover. The guidance is implied through category listing, not stated.

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?

No annotations are provided, so the description carries the full burden of explaining behavior, but it only mentions price. It fails to disclose whether this is a read operation, what data it returns, any side effects, or any context such as required permissions or output structure.

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 description is short, but this is under-specification rather than effective conciseness. The single price sentence provides no functional information and does not earn its place in a tool definition meant to guide tool selection and invocation.

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?

Even with an output schema present, the description is missing the most essential information: what the tool does and when to use it. Given the large number of similar property tools, this definition is wholly inadequate for an agent to invoke 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 0%, so the description must explain what 'gnaf_id' means or how it should be formatted, but it says nothing about the parameter. The agent is left with only the raw schema and a field name with no semantic guidance.

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 contains only 'Price: 23¢ per call.' and does not state what the tool does. The name hints at returning all basic property information, but no verb, resource, or scope is defined, and nothing distinguishes it from sibling tools like properties_basics_bed_count or properties_basics_dwelling_type.

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 alternatives. With dozens of property-related siblings, the absence of any selection criteria leaves the agent unable to choose this tool correctly.

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 no annotations, the description carries the full burden and only reveals that it returns a bathroom count and costs 5 cents. It does not disclose what happens if no listing matches, how 'latest' is determined, or any prerequisites for gnaf_id.

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 description is two short sentences with the result front-loaded and the cost clearly separated. There is no filler, though the brevity sacrifices behavioral detail.

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?

Despite low complexity and an output schema, the description omits the parameter's meaning and the tool's selection semantics. An agent cannot confidently call this without knowing what gnaf_id should contain or what 'latest matching listing' means.

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?

The input schema provides only a required string parameter with 0% description coverage, and the description never explains gnaf_id. An agent must guess that gnaf_id is a G-NAF identifier and how it relates to the matching listing.

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 the resource ('bathroom count') and source ('latest matching listing'), so an agent can distinguish it from properties_basics_bed_count and properties_basics_parking_count. It lacks an explicit verb and 'matching' is imprecise, but the core purpose 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 is given about when to use this tool versus properties_basics_all or other properties_basics_* siblings, and no alternatives are named. The phrase 'latest matching listing' implies a use case, but the description never says when this tool is preferred.

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 no annotations, the description carries the full behavioral burden. It does provide a useful scoping detail—'latest matching listing' rather than current or historical—and notes the 5¢ cost, but it leaves ambiguous what 'matching' means and does not say how unmatched properties are handled.

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 description is two short sentences and front-loads the core purpose before the pricing note. Every sentence earns its place, and there is no filler or redundant restatement.

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 tool with no annotations and no parameter documentation, the description is too thin: it omits what gnaf_id refers to, gives no selection guidance among the basics siblings, and never clarifies 'matching.' The output schema reduces the need to describe return values but cannot compensate for the core input and usage 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 description coverage is 0% and the description does not define gnaf_id or clarify that the listing is matched by that identifier. The phrase 'matching listing' weakly implies an identifier, but the only real parameter is left to be inferred from its name.

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 outcome: returning the bedroom count for the latest matching listing, and the tool name narrows it to one of the basics family. It is clear but does not explicitly contrast with properties_basics_all or properties_basics_bath_count, so it stops short of full sibling differentiation.

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 says when to call this instead of properties_basics_all, properties_basics_bath_count, properties_basics_dwelling_type, or other property basics endpoints. The only signal is the name, leaving an agent to infer which sibling is appropriate for a given property-attributes request.

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?

No annotations are provided, so the description carries the full burden. It discloses the price (5¢ per call) but doesn't mention what the output looks like, whether the gnaf_id must be valid, or any error behavior. The description is minimal and doesn't add meaningful behavioral context beyond the price.

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 description is very short and front-loaded with the core purpose. The price note is extra but relevant. It earns its place, though it could be slightly more informative without becoming verbose.

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?

Given the tool has an output schema, the return value may be documented there, but the description still lacks context about the input parameter, prerequisites, and how this tool fits among the many properties_basics_* siblings. For a simple single-parameter tool, it's minimally adequate but leaves 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 description coverage is 0%, and the description does not explain the gnaf_id parameter at all. The parameter name suggests a G-NAF identifier, but the description doesn't confirm what it is, where to find it, or its format. With one required parameter and zero coverage, the description should compensate but doesn't.

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 the tool returns a dwelling type (house, unit, townhouse, ...) for a property, which is a clear verb+resource. It doesn't explicitly differentiate from siblings like properties_basics_bed_count or properties_basics_all, but the resource is specific enough to be understood.

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 alternatives. The sibling list includes many properties_basics_* tools, but the description doesn't mention them or provide selection criteria. The only context is the price note, which is not usage 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add useful context by identifying the cadastral feed as the data source and stating the per-call price, but it does not mention edge cases such as missing parcel data, GNAF ID resolution failures, or whether the returned value is the original cadastral area.

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 description is extremely concise, contains no filler, and front-loads the core semantic: parcel land area in square metres. The price is separated into its own sentence, making it easy to scan.

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 lookup with an output schema, the core purpose is covered and the price is disclosed. However, the lack of parameter guidance and any usage comparison to sibling tools leaves the description just barely adequate rather than fully complete.

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 0%, and the description does not explain the gnaf_id parameter at all. The parameter's name suggests it is an address identifier, but the description does not say where it comes from or how it should be formatted, so the agent is left without meaningful guidance 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?

The description clearly states the tool returns parcel land area in square metres from the cadastral feed, so an agent can understand what data it provides. It distinguishes this metric from area-related siblings by specifying the unit and the cadastral source, though it does not explicitly name or contrast 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 gives no guidance on when to use this tool versus related alternatives such as properties_basics_all or properties_valuation_land_values. There are no stated exclusions, prerequisites, or recommendations about how GNAF IDs should be obtained first. An agent must infer when this specific endpoint is appropriate.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the price per call, which is useful, and implies a read-only operation by saying 'count', but it does not disclose what happens when no matching listing exists, whether the value comes from the listing or a database, or any limitations. The phrase 'latest matching listing' could mislead an agent into thinking the count reflects current property state rather than a listing's data.

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 description is two short sentences, with the core purpose front-loaded and the price note clearly separated. It contains no fluff, and the price note is arguably useful for an agent deciding whether the call is cost-effective. The lack of any usage or parameter detail is a completeness issue rather than a conciseness issue, so this dimension scores well.

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?

Though the tool has only one parameter and an output schema, the description is incomplete for effective use. It never explains what gnaf_id is or how to find it, nor what 'latest matching listing' means in terms of data freshness or matching criteria. With sibling tools available for other property attributes, the description does nothing to help an agent decide whether this tool is the correct one for the task.

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 0%, so the description must compensate by explaining the single parameter gnaf_id. It only says 'from the latest matching listing', which loosely ties the ID to a listing, but it never defines gnaf_id, its format, or how to obtain it. The description adds minimal meaning beyond the bare schema and leaves the agent without enough information to correctly populate the parameter.

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: it returns a parking-space count from the latest matching listing. The noun 'parking' in both the name and description distinguishes it from sibling tools like properties_basics_bed_count and properties_basics_bath_count. The phrase 'latest matching listing' adds a useful scoping detail, making the purpose 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?

The description gives no guidance on when to use this tool versus the many sibling property_basics_* count tools. It does not mention any prerequisites, such as needing a valid gnaf_id or a property with an active listing, nor does it warn against using it when another tool would be more appropriate. The agent is left to infer context solely from the tool name.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The only disclosed behavior is pricing, which is not a functional behavior. There is no mention of what the tool returns, side effects, or operational characteristics.

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 description is extremely short, but this is under-specification rather than effective conciseness. The single sentence about pricing is not a functional description and does not earn its place as the sole content.

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?

The tool has an output schema and one required parameter, but the description provides no context about what the tool does, how the parameter should be used, or what the output represents. Given the large sibling family, this is completely inadequate for an agent to select and invoke the tool 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 0%, and the description provides no parameter information. The single parameter gnaf_id is only defined as a string in the schema, with no explanation of its format, purpose, or constraints. The description does not compensate for the schema gap.

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 only states 'Price: 74¢ per call.' It does not state a verb, resource, or what the tool does. The name 'properties_comparables_all' suggests it returns comparable properties, but the description itself provides no functional information.

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 alternatives. Sibling tools like properties_comparables_cma_comp_set and properties_comparables_recent_sales_nearby exist, but the description does not differentiate or provide selection criteria.

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 no annotations, the description carries the full burden of behavioral disclosure. It only mentions the output type ('top comparable sales') without describing how the set is selected, ordering, limits, or any side effects. The price note is the only extra behavioral trait, but it is billing-related, not operational.

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 description is very short, but it is under-specified rather than efficiently complete. The first sentence states the purpose, and the second adds cost information, which is useful. However, it lacks necessary details, making brevity insufficient for a usable 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 tool with one required parameter, no annotations, and an output schema that isn't shown, the description is inadequate. It does not explain the parameter, nor does it clarify how this tool relates to the similar sibling tools. An agent could not determine when to call this tool or what input to provide.

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 0%, and the description does not explain what gnaf_id means or what value to pass. The parameter is required and has a type, but the agent receives no semantic guidance beyond the field name itself.

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 clearly states that the tool provides 'top comparable sales used to triangulate the subject property's value,' which conveys a specific resource and its purpose. However, it does not explicitly distinguish this from sibling tools like properties_comparables_all or properties_comparables_cma_single_comp, leaving some ambiguity.

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 is given about when to use this tool versus the many sibling comparable-sales tools. The description only states what the tool does, not the context or conditions that would make it the right choice.

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 no annotations, the description carries the full disclosure burden. It does state the key selection behavior (highest dist_score) and the cost (10¢ per call), but it does not explain what happens when no comparable exists, what CMA means, or any prerequisites. The core behavior is present, so it is not a total failure.

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 description is two short sentences with no wasted words. The core purpose is front-loaded, and the price is separated into a useful second sentence.

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?

The output schema covers the return shape, and the tool is simple, but the description omits input semantics and sibling routing. The price disclosure is helpful, yet an agent would need external context to understand gnaf_id and the CMA concept.

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 0%, and the description never mentions gnaf_id. The agent is left to infer that gnaf_id identifies the subject property, with no explanation of its format, source, or role in selecting the comparable.

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 clearly identifies the tool's output: the single best comparable from the CMA set, selected by highest dist_score. This distinguishes it from the sibling properties_comparables_cma_comp_set, though it lacks an explicit verb like 'returns' or 'retrieves' and does not name the sibling directly.

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 phrase 'Single best comparable' implies when the tool should be used, but there is no explicit guidance about when not to use it or which alternative to choose. It does not mention properties_comparables_cma_comp_set or other comparable tools as routing options.

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 no annotations, the description carries the behavioral burden. It discloses the call cost (4¢) and the core query behavior, but leaves 'small radius' and 'recent' undefined and says nothing about result limits, data coverage, or side effects.

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 description is two short sentences, front-loaded with the primary behavior and followed by the cost. There is no filler or repetition of the tool name.

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 an output schema, the definition is mostly adequate, but it leaves 'small radius' and 'recent' imprecise and provides no guidance on where to obtain a valid gnaf_id. It is not severely incomplete, but it has clear 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 description coverage is 0%, and the description never mentions gnaf_id, its format, or how to obtain it. The phrase 'subject parcel' only weakly implies that gnaf_id identifies the parcel, so the description does not compensate for the schema gap.

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 the tool returns recent comparable sales in a small radius around the subject parcel, giving a clear resource and scope. This differentiates it from siblings like properties_comparables_all and properties_comparables_cma_comp_set, though it lacks an explicit verb such as 'get' or 'list'.

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 choose this tool over the many comparable-sales siblings (e.g., properties_comparables_all, cma_comp_set, sale_history) or when not to use it. The description only states what it returns, leaving the agent to infer use cases.

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 no annotations, the description carries the full burden, and it does disclose the output scope, the included statistics, GeoJSON format, and the 30¢ per-call cost. It does not mention potential limits, data recency, or that the operation is a read, but the low-risk query nature makes the omission less severe.

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 short sentences with no filler. The core output and scope are front-loaded, and the pricing note is the only secondary content. Every word earns its place.

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?

The output schema and geojson parameter description already cover return structure and the geometry toggle, so the description does not need to restate them. However, the absence of usage guidance and gnaf_id semantics leaves some selection and invocation details to inference.

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 50%, with geojson fully described in the schema but gnaf_id undocumented. The description never mentions gnaf_id or explains how the property is identified, so it does not compensate for the missing parameter semantics.

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 identifies the resource precisely: mesh-block polygons within 1 km of the property, in GeoJSON, with a defined set of statistics. It is distinguishable from sibling tools like suburbs_shapes_mesh_blocks by its property-centered scope, though it lacks an explicit verb such as 'Returns' or 'Gets'.

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 is given on when to use this tool versus alternatives such as properties_context_nearby_for_sale, properties_surroundings_parcels, or suburbs_shapes_mesh_blocks. The emphasis on 'within 1 km of the property' implies a property-context use case, but no explicit condition or exclusion is stated.

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 discloses key behavioral traits: results are newest first, capped at 30, and cost 20¢ per call. These details go beyond what annotations (none) or schema provide. It does not state whether the operation is read-only, but for a listing retrieval this is likely implied; given the absence of annotations, this level of transparency is above average.

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 description is a single, efficient sentence covering the core function, followed by a clear pricing note. No filler, and the most important information (what and how) is front-loaded.

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?

The description covers purpose, ordering, limit, and cost, which is good for a simple two-parameter tool. However, it omits explanation of the required gnaf_id parameter, and the output schema (though present) does not cover parameter explanation. Given the low parameter count and existing output schema, this is acceptable but not complete.

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 only 50% (radius_km is described, gnaf_id is not). The description mentions radius_km but adds no new meaning beyond the schema. It does not explain gnaf_id, which is required, nor its format or source. The description fails to compensate for the undocumented required parameter.

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?

Description clearly states the tool returns current for-sale listings within a radius of a property, with AVM and rent-yield comparison, and orders them newest first with a max of 30. This distinguishes it from siblings like properties_comparables_recent_sales_nearby (recent sales, not active listings) and properties_sale_history (historical sales).

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 provides context (currently for-sale listings near a property) but does not explicitly mention when to use this tool over alternatives like suburbs_listings_for_sale or properties_surroundings_properties. No explicit exclusions or alternative routing is given, so the agent must infer usage from the stated purpose.

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 no annotations, the description carries the burden of behavioral disclosure. It does disclose the data source ('listing history'), the output composition (bedroom band plus 10-year series), and the cost ('15¢ per call'). However, it does not mention rate limits, access requirements, or any caveats about how the series is computed.

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 description is two short sentences with no filler. The first sentence conveys the full semantic content, and the second cleanly separates the pricing fact. Every word earns its place.

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?

An output schema exists, so the description doesn't need to explain return fields. It covers the core data, the source, and the cost. Still, it is missing explicit parameter semantics and usage guidance, which leaves an agent without clear conditions for invocation.

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 0%, and the single required parameter gnaf_id has no documented format. The description indirectly implies that gnaf_id identifies 'the subject' and its suburb, but it never explicitly names the parameter or explains what a GNAF ID is or how to format it. It provides partial compensation but not enough for full confidence.

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 concrete output resource: the subject's bedroom band derived from listing history plus the suburb's 10-year price series for that band. It lacks an explicit verb like 'get' or 'returns', but the intent is clear and the tool is distinguishable from sibling context tools by its specific data content.

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 choose this tool over alternatives such as properties_sale_history, properties_context_mesh_blocks, or suburbs_market_median_sale_price_series. The description states what it returns but not when it is useful or when it should not be used.

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?

No annotations are provided, so the description carries the full burden of disclosing behavior, but it only mentions pricing. It does not indicate what is returned, whether data is historical or current, what location scope applies, or any side effects.

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 text is short, but this is under-specification rather than effective conciseness. The only sentence conveys pricing, which does not help an agent select or invoke the tool.

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?

Despite an output schema and a clear property-focused sibling family, the description is completely inadequate. An agent cannot infer what development data 'all' refers to, what gnaf_id represents in this context, or how this differs from the zoning and overlay siblings.

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 0% and the description adds nothing about the required gnaf_id parameter. With only one parameter, the description could easily clarify its meaning or format, but it does not.

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 only states 'Price: 8¢ per call' and does not say what the tool does. The tool name suggests it returns development information for a property, but the description itself provides no verb, resource, or behavior, so an agent cannot determine its purpose.

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 about when to use this tool versus the many sibling tools such as properties_development_zoning_code or properties_development_zoning_overlays. The description gives no context, exclusions, or alternatives.

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 no annotations provided, the description carries the behavioral disclosure burden. It does add a useful caveat that the code is only returned 'when the council ships one,' and it notes the 3¢ cost, but it does not disclose error behavior, data availability handling, or other operational traits.

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 description is compact and front-loaded with the essential purpose, followed by the cost note. Both sentences earn their place, and there is no extraneous wording.

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 lookup with an output schema present, the description covers the main content and an important caveat. It could be more explicit about how it differs from sibling zoning tools, but that is not a critical gap given the clarity of the data returned.

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?

The schema has a single required gnaf_id parameter with 0% description coverage, and the description does not explicitly explain the parameter. However, 'at the property's point' and the tool's domain make it reasonably clear that gnaf_id identifies the property being queried.

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 clearly identifies the tool as returning the primary zoning code at a property location, plus the human-readable name and broader category. It is specific enough to distinguish from zoning_overlays and development_all siblings, though it does not explicitly name alternatives.

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 implies use when an agent needs a property's primary zoning code, but it does not provide explicit when-to-use guidance, exclusions, or alternatives. The tool's scope is inferable from the description, just not stated directly.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and price, without indicating whether this is a read-only operation, what fields are returned, or any potential limitations. The price note is useful but does not cover the behavioral traits an agent needs to understand.

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 description is highly concise, with the purpose in the first sentence and the pricing note in the second. It front-loads the key functional information and avoids fluff. Although it is very brief, it is properly structured and every sentence serves a purpose.

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?

Given it has only one parameter and no annotations, the description is thin on context. It does not explain what development overlays are, how many might be returned, or how this differs from related tools. An agent cannot fully understand the tool's behavior or when it is the right choice without additional information.

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?

The schema has 0% description coverage and the description does not explain the 'gnaf_id' parameter. While the name hints at a GNAF identifier, the description adds no meaning beyond the parameter name itself. With no schema description and no high-level explanation, the agent is left without guidance on how to format or interpret this parameter.

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 resource ('Development overlays') and scope ('intersecting the property's parcel'), making it clear what the tool returns. It distinguishes itself from related siblings like properties_development_zoning_code (which returns a code) and properties_development_all (which likely returns broader development info). The verb is implied but the purpose 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 explicit guidance on when to use this tool versus alternatives. The description mentions 'intersecting the property's parcel' but does not explain the difference from other development-related tools or provide any selection criteria. An agent would have to infer usage from the name 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It provides none: no indication of what the call returns, whether it is read-only, how pricing works, or any side effects. The only behavior mentioned is the cost, which is unrelated to the tool's operation.

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 description is short, but it is under-specified rather than appropriately concise. It contains no functional information and fails to earn its place as a tool description.

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?

Despite having an output schema and a single required parameter, the complete absence of a functional description means the tool is effectively unusable for correct selection or invocation. The pricing note does not explain what history is returned, what gnaf_id refers to, or how this differs from numerous related siblings.

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 0%, and the description adds no meaning to the single gnaf_id parameter. An agent cannot tell what form the identifier should take or how it is used. The description does nothing to compensate for the schema's lack of documentation.

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 is only 'Price: 80¢ per call.' It does not state a verb, resource, or function. The tool name suggests it returns property history, but the description itself provides no purpose or distinction from siblings like properties_sale_history or properties_rent_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 any of the many historical tools in the sibling list. The description offers no context, exclusions, or alternatives, leaving the agent to guess entirely from the tool name.

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?

No annotations are provided, so the description carries the behavioral disclosure burden. It adds useful behavioral context by stating the enrichment fields and the 30¢ cost per call, but it says nothing about side effects, read-only behavior, or how the latest matching listing is chosen. This is useful but not comprehensive.

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 description is two crisp sentences: the first states the output, the second states the price. Every clause adds information, and the price is visually separated. There is no filler or redundant restating of the tool name.

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 simple one-parameter tool with an output schema, the description covers the core result and cost. It is incomplete on parameter semantics and usage selection, but it does not need to describe return values because an output schema exists. Overall, it is adequate but leaves key selection and input questions unanswered.

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?

The schema gives gnaf_id only a type, and the schema description coverage is 0%, so the description must explain the parameter. It never defines gnaf_id or states that it is the parcel identifier for which neighbours should be returned. An agent must infer the parameter meaning from the tool name rather than from any explicit documentation.

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 clearly identifies the resource and result: adjoining-parcel neighbours, enriched with specific listing data. The noun-phrase style lacks an explicit imperative verb, but 'Adjoining-parcel neighbours' is unambiguous about what is returned. It does not explicitly distinguish itself from sibling tools such as properties_context_nearby_for_sale or properties_surroundings_parcels.

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 choose this tool over the many neighbouring-property alternatives. The price note is a cost signal, not a usage condition. An agent must infer intended use 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?

With no annotations provided, the description carries the behavioral disclosure burden. It discloses the full scope of returned data and explicitly states the 3¢ per-call price, which is an operational trait an agent needs. It does not discuss failure modes or authorization, but this is a simple read-style lookup and the output schema covers the response shape.

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 description is compact: one dense sentence for the core purpose and one for usage, followed by the bolded price. The hierarchy list is information-dense but necessary and front-loaded, with 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?

For a one-parameter lookup with an output schema, the description adequately conveys the input, the full output scope, and the economic cost. It does not explain how to obtain a valid GNAF ID or what happens on an invalid ID, but those are minor gaps given the simplicity of the tool and the presence of an output schema.

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?

The schema provides no description for gnaf_id and schema description coverage is 0%, so the description had to compensate. It clarifies that gnaf_id is a GNAF identifier and that the tool resolves it to a hierarchy, which gives the parameter some meaning beyond its name. However, it does not specify the expected format, source, or constraints on the identifier.

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 uses a specific verb ('Resolve') and names the exact output: the full ABS hierarchy from Mesh Block to State plus the admin chain of LGA, SAL, and postcode. It also differentiates itself from sibling tools by framing the result as the ABS keys that other data layers index on, so an agent can tell it apart from tools like properties_context_mesh_blocks or suburbs_profile.

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?

'Call this once to get every ABS key the rest of the data layers index on' gives an explicit trigger and consolidation rule, helping an agent know when to select this tool. It does not name alternatives or state when not to use it, but the usage context is clear enough.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the ordering ('most-recent first') and the pricing ('30¢ per call'), which is useful, but it does not disclose what fields are returned, whether the record includes historical entries or only current listings, pagination behavior, or any rate limits beyond cost. The pricing note is a positive addition, but the behavioral profile is thin for a data-returning tool.

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 description is extremely short and front-loaded: the core purpose is in the first sentence, and the pricing is a separate line. Every word earns its place. It loses one point because the pricing, while useful, is placed without context and the description could have used the available space to add parameter or usage detail without becoming verbose.

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 tool with one required parameter, no annotations, and no parameter documentation, the description is incomplete. The output schema exists, so return values are covered, but the agent still lacks: what gnaf_id means, how this differs from properties_rent_history_latest, and whether the result is a list of historical records or current listings. The pricing note is helpful but does not fill these 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 description coverage is 0%, and the description does not explain the gnaf_id parameter at all. The schema only says it's a required string, leaving the agent to guess that gnaf_id is a G-NAF address identifier. The description adds no meaning beyond the schema, and with zero coverage, it fails to compensate for the missing parameter documentation.

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: 'All For Rent records, most-recent first.' This clearly indicates the tool returns rental listing history records for a property, and the ordering is specified. It doesn't explicitly differentiate from siblings like properties_rent_history_latest or properties_history_all, but the 'For Rent records' phrasing and ordering give enough clarity for basic selection.

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 is provided on when to use this tool versus alternatives. The sibling list includes properties_rent_history_latest, properties_history_all, and properties_sale_history, but the description does not mention any of them or explain the distinction. An agent would have to infer usage from the name and description alone, with no explicit when-to-use or when-not-to-use 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions the price (10¢ per call), which is a cost implication but not a behavioral trait. It does not describe the return format, whether the gnaf_id is required, or any data characteristics. The description provides minimal information about what the tool does beyond the name.

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 description is very short and to the point, with no fluff. It includes the key information (most-recent, For Rent) and a critical cost note. It is front-loaded with the most important descriptive phrase. The cost is mentioned as a separate line, making it easy to notice.

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?

Given the large sibling set, including properties_rent_history and properties_sale_history_latest, the description is insufficiently complete. It does not explain what data the record contains (e.g., rent amount, dates), how the 'most-recent' is determined, or whether the tool returns a single object or an array. The cost is noted, but other operational details are missing. The output schema might provide some clarity, but the description leaves many questions unanswered.

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 one parameter, gnaf_id, with 0% schema description coverage. The description does not elaborate on the parameter beyond what the schema shows (name and type). The description does not explain what gnaf_id represents or how to format it. Since it's a single parameter, the agent might infer it's an identifier, but the description adds little value.

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 resource ('Most-recent For Rent record') with a clear noun, but the verb is implied ('get' or 'retrieve') rather than explicit. It distinguishes the tool from sibling properties_rent_history by indicating 'most-recent', but doesn't name the sibling directly. However, the purpose is understandable and aligns with the tool name.

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 implies that this tool is for retrieving a single most-recent rent record, which contrasts with properties_rent_history that might return a list. However, it does not provide explicit guidance on when to use this over properties_rent_history or other history tools. No alternative tools are mentioned by name.

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 discloses pricing behavior ('Flat 30¢ — may grow without increasing the bundle price as new overlays are added') and the geojson clipping behavior ('1km-radius-clipped'). However, it contains an internal contradiction: it says 'Flat 30¢' then later says 'Price: 48¢ per call.' This is confusing and undermines transparency. No annotations are provided, so the description carries the full burden, and this inconsistency is a significant flaw.

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 description is compact and front-loaded with the core purpose. The geojson behavior is explained in a dedicated paragraph. However, the pricing contradiction ('Flat 30¢' vs '48¢ per call') is confusing and wastes the reader's attention. Otherwise, every sentence earns its place.

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?

The tool has an output schema, so return values are covered elsewhere. The description explains the geojson option and pricing, but the pricing contradiction creates uncertainty. It also doesn't clarify whether the 48¢ price is the current price or the flat 30¢ is the bundle price. For a simple 2-param tool with an output schema, this is adequate but not complete.

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 50%: the geojson parameter is well-documented in the schema, but gnaf_id has no description. The description adds context for geojson (clipped to 1km radius, adds geojson_meta) but doesn't explain gnaf_id beyond the schema's type/required. With 50% coverage, the description partially compensates but leaves the key identifier parameter undocumented.

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: 'Every property-level risk overlay in one call.' This clearly distinguishes it from the individual risk tools (properties_risks_bushfire, properties_risks_flood, etc.) by emphasizing the aggregate 'all' nature. However, it doesn't explicitly name a sibling alternative, so it loses a point for not directly differentiating from the individual risk endpoints.

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 implies usage: use this when you want all property-level risk overlays in one call rather than calling individual risk endpoints. It also explains the optional geojson parameter's effect. However, it doesn't explicitly state when NOT to use it (e.g., when you only need one specific risk type, use the specific endpoint) or name alternatives.

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 no annotations, the description carries the disclosure burden and does add real value beyond the schema: the 1 km radius, the near-vs-in-zone semantics, and the 15¢ per-call cost. It does not describe output shape or empty-result behavior, but with an output schema present and a simple tool, these aren't critical omissions. No contradiction with annotations since none are provided.

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, each earning its place: the resource, the critical semantic warning, and the price. The most important caveat is front-loaded immediately after the resource phrase, with no filler.

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?

Given an output schema, return values needn't be re-explained; the description covers the non-obvious facts: the proximity radius, the `on_property` interpretation pitfall, and the cost. The main leftover gap is `gnaf_id` semantics, which is minor since it appears to be a standard identifier across this API family.

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 50%: `geojson` is fully documented in the schema, and the description's 1 km phrasing aligns with it. But `gnaf_id` is the single required parameter and the description never explains what it is, leaving the agent to infer its meaning from the sibling tool family.

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?

Identifies the resource (bushfire-prone-area overlays within a 1 km radius) and the `on_property` clarification removes the most likely misreading of the data — a row means found nearby, not in-zone. Lacks an explicit verb and doesn't name a sibling, which keeps it just under the top score.

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 `on_property` warning is genuinely useful operational guidance — it tells the agent how to interpret results before trusting them, which is at least as important as tool selection here. But there is no explicit statement of when to choose this tool over `properties_risks_flood`, `suburbs_risks_bushfire`, or the umbrella `properties_risks_all` tools.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions the price (3¢ per call) and the overlay concept, but does not disclose what the tool returns, any side effects, authentication requirements, or other behavioral characteristics. For a tool with no annotation coverage, this is a significant 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 description is very short, which is concise, but it is under-specified. It has two parts: the main description and a price note. While it is not verbose, the brevity comes at the cost of content. It is acceptable as a concise statement but lacks necessary structure and detail.

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?

The tool has only one parameter and an output schema exists, but the description is vague. It does not clarify what the overlay includes beyond examples, nor does it explain how the output relates to the input. Given many sibling risk tools, this description is incomplete for an agent to correctly select and use it. The output schema exists but the description does not help interpret it.

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?

The schema has one required parameter (gnaf_id), but the description does not mention it at all. Schema description coverage is 0%, so the description adds no meaning beyond the schema. It fails to compensate for the missing parameter context, leaving the agent to infer that gnaf_id is the property identifier.

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 resource (environmental-risk overlay) and gives examples (contamination, salinity), which distinguishes it from sibling risk tools like bushfire or flood. However, it lacks an explicit verb, relying on the noun phrase to imply retrieval. It is clear enough but not fully explicit.

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 is given on when to use this tool versus the many sibling risk tools (e.g., properties_risks_bushfire, properties_risks_flood). There is no mention of alternatives, conditions, or exclusions. An agent cannot determine when to choose this over a more specific risk tool.

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 no annotations provided, the description carries the disclosure burden and does so well: it states the 1 km radius, explains that a returned row means 'found nearby' not 'property is eroding', and discloses the 3¢ per-call price. These are meaningful behavioral details beyond the schema.

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 description is compact and front-loaded: the purpose and spatial scope come first, followed by the critical output interpretation and pricing. Every sentence earns its place with no redundant filler.

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?

The tool is simple, has an output schema, and the description covers core semantics and pricing. However, it falls short on explaining when to use this specific risk tool versus related risk siblingsorestation or environment tools, and it leaves `gnaf_id` without any explanatory context.

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 only 50%, and the description does not compensate for the undocumented `gnaf_id` parameter at all. The `geojson` parameter is already described in the schema, so the description adds no parameter semantics beyond what structured data already provides.

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 ('Coastal / soil erosion overlays') and a clear spatial scope ('within 1 km'), which distinguishes it from the many sibling risk tools by hazard type. It lacks an explicit verb like 'Get' or 'List', but the intent 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?

The description provides a crucial interpretation note about `on_property` but gives no guidance on when to choose this tool over siblings such as properties_risks_all, properties_risks_environment, or properties_risks_landslide. There is no explicit 'use this for erosion only' or alternative-routing information.

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 no annotations, the description carries the transparency burden and does so well: it discloses that the data is modelled, that a returned row means 'found nearby' rather than 'this property floods', and that the call costs 10¢. This prevents a serious misinterpretation, though more details about limits or failure modes could be added.

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, front-loaded units: purpose, critical interpretation caveat, and price. There is no filler, and the code formatting plus bold price make the important caveats scannable.

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?

Given the output schema exists and there are only two parameters, the description plus schema cover the core invocation details: required `gnaf_id`, optional `geojson`, spatial radius, interpretation, and billing. It could be more complete by naming sibling-distinguishing use cases, but nothing essential for a safe call 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?

The schema already documents `geojson` in detail, and the description's 'within 1 km' adds spatial meaning. However, `gnaf_id` is left with only a type in both the schema and the description, and with 50% schema coverage the description does not fully compensate for the required parameter.

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 clearly identifies the resource ('Modelled flood overlays') and the spatial scope ('within 1 km'), which is enough to distinguish it from bushfire, erosion, and landslide siblings. It lacks an explicit verb like 'Returns' and does not contrast itself with `properties_risks_historical_flood`, 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?

The intended use is implied: call this tool for modelled flood overlays within 1 km of a property. The `on_property` instruction is useful, but the description never states when to prefer this tool over `properties_risks_historical_flood`, `properties_risks_all`, or other risk tools, and it gives 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?

With no annotations, the description carries the burden and does disclose the most important behavior: a returned row means 'found nearby', not that the property is listed. The price and 'Read' wording add operational context, though rate limits, error cases, and explicit read-only status are not stated.

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 deliver the resource, the semantic warning, and the price with no filler. The core message is front-loaded, and every sentence earns its place.

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 tool with an output schema, the description covers the core semantics and the critical interpretation trap. It is slightly less complete on usage guidance and rate-limit/read-only behavior, but nothing essential to making a correct call 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?

The schema already documents the `geojson` parameter, but `gnaf_id` has no description. The description adds the 1 km proximity context and the `on_property` interpretation, which helps, but it does not explain what `gnaf_id` is or its format, so it only partially compensates for the 50% schema coverage.

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 phrase 'Heritage-listing overlays within 1 km' identifies the resource and scope clearly, and the caveat about `on_property` sharpens what the result means. It lacks an explicit verb like 'Returns' or 'Lists', and it does not name a sibling tool, 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?

The description gives clear context: use this for heritage-listing overlays within 1 km, and the `on_property` caveat tells the agent not to treat a returned row as proof the property is heritage-listed. It does not name alternatives or give explicit when/when-not routing beyond that interpretive boundary.

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 no annotations, the description carries the full burden. It discloses a critical interpretation caveat: a returned row means 'found nearby', not that the property flooded. It also discloses the cost (3¢ per call). It does not mention pagination or error behavior, but the main misinterpretation risk is addressed.

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 zero fluff. The main purpose is front-loaded, followed by the crucial interpretation caveat and the price. Every sentence earns its place.

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?

The tool is simple (one parameter, output schema provided). The description covers the key caveat and cost. It does not mention prerequisites like needing a gnaf_id from a geocoding step, but that is implicitly understood from the sibling context. The output schema covers return details, so the description is sufficiently complete.

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 0% for the single parameter gnaf_id. The description does not explain what gnaf_id represents or how it should be formatted. The name is somewhat self-explanatory, but the description adds no value in clarifying the parameter's meaning or usage.

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 clearly states the tool returns recorded historical flood extents within a 1 km radius, specifying the resource (historical flood extents) and scope (within 1 km). It distinguishes itself from siblings like properties_risks_flood by the 'historical' qualifier and the distance constraint.

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 provides no explicit guidance on when to use this tool versus alternatives such as properties_risks_flood or properties_risks_all. The purpose is clear, but the agent must infer from the name and description that it is for historical flood data; there is no direct comparison or exclusion criteria.

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 no annotations, the description carries full burden for behavioral disclosure. It only states the subject and price, offering no information about output shape, read-only nature, side effects, or how 'near' is determined. This is insufficient for a tool with zero annotation safety hints.

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 description is short and front-loads the core subject, which is good. However, the price note, while useful, occupies the second sentence and is the only other content. The structure is adequate but lacks informative details that would earn a higher score.

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?

An output schema exists, so return values need not be describedcars. However, with many similar sibling tools, the description should clarify how this tool differs (e.g., properties_risks_all) and what 'easement near the parcel' means in practice. The missing usage context makes the definition incomplete for reliable tool selection.

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 0% for the single required parameter 'gnaf_id'. The description does not mention this parameter, its format, or how to obtain itcars. Given the low coverage, the description was expected to compensate but provides no parameter semantics.

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 'High-voltage power-line easement near the parcel' clearly identifies the resource as HV power-line easement information for a location, which is distinct from siblings like flood or bushfire risk tools. However, it lacks a verb (e.g., 'Returns' or 'Gets') and relies heavily on the tool name for clarity.

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 is provided about when to use this tool versus other risk-related siblings such as properties_risks_all or properties_risks_environment. The description does not state prerequisites, intended use cases, or 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly warns that a returned row means 'found nearby' rather than 'property at risk', preventing a common misinterpretation. It also states the cost per call (3¢), adding transparency about usage charges. It does not cover all possible behaviors but covers the most critical one.

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 description is extremely concise, consisting of two sentences and a price note. The primary purpose is front-loaded, followed by the crucial semantic clarification and cost. There is zero fluff, making it efficient for an agent to parse.

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 risk-overlay tool with an output schema, the description provides the essential context: the spatial scope (1 km), the meaning of the on_property flag, and the cost. It does not mention authentication or other prerequisites, but these are likely covered by the output schema and general API context. The description is sufficiently complete for an agent to call the tool 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 only 50%—the geojson parameter is well documented, but gnaf_id has no schema description. The tool description does not compensate for this gap; it does not explain what gnaf_id represents or how to obtain it. Given the low coverage, the description should have provided parameter context but did not.

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 clearly states the tool's function: providing landslide-risk overlays within a 1 km radius. It also clarifies the meaning of the `on_property` field, which is essential for correct interpretation. While it doesn't explicitly contrast with sibling risk tools, the name and content make the purpose 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?

The description does not provide guidance on when to use this tool versus alternatives such as properties_risks_all or properties_risks_flood. It implies usage for landslide risk but offers no exclusions or selection criteria, leaving the agent to infer from the name 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?

There are no annotations, so the description carries the full behavioral burden. It does add the pricing constraint ('Price: 2¢ per call') and indicates a geospatial proximity scope ('near the parcel'), which are useful. However, it does not state whether the operation is read-only, what the overlay contains, or how the response behaves.

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 description is very short and front-loads the core subject before the pricing note. No words are wasted, though the phrasing 'overlay near the parcel' is compact to the point of being slightly unclear.

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 annotations, one required parameter, and no parameter explanation, the description is not fully sufficient on its own. The presence of an output schema helps, but the agent still lacks clarity on what value to pass for gnaf_id and when to use this tool instead of other risk-related siblings.

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 0%, and the description does not explain the required gnaf_id parameter beyond the implicit 'parcel' context. The parameter name is probably recognizable, but the description adds no explicit meaning to help an agent construct a correct call.

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 identifies the resource as a mobile-coverage black-spot overlay near the parcel, which clearly distinguishes it from other risk tools like flood, bushfire, or heritage. It lacks an explicit verb like 'get' or 'return', but the noun phrase is specific enough for an agent to understand what is being described.

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 is given about when to choose this tool over alternatives such as properties_risks_all, properties_risks_bushfire, or other risk overlays. The pricing note is useful but does not help an agent decide between similar sibling tools.

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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It discloses only the price per call and the generic result type; it does not say whether the overlay is a risk rating, what data source or geometry it uses, whether results are cached, or what limitations apply.

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 description is very short, front-loads the core purpose, and includes the price as a separate standalone sentence. It has no filler, but the brevity comes at the expense of parameter explanation and usage context, so it is efficient rather than exemplary.

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?

The tool is simple: one required parameter and an output schema are provided, so the short purpose statement is close to sufficient for invoking it. However, the description lacks sibling-selection guidance and any explanation of gnaf_id, which leaves an agent uncertain when choosing among the many properties_risks_* and properties_surroundings_public_housing variants.

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?

The schema provides zero description coverage for gnaf_id, and the description does not name or explain the parameter. 'Near the parcel' only indirectly implies that gnaf_id identifies the parcel, leaving the agent without format details, validity requirements, or how the parameter affects the overlay output.

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 output: a public-housing concentration overlay near the parcel. This identifies the resource and scope clearly enough, though 'overlay' is used as a noun and there is no explicit verb or sibling comparison to fully distinguish it from properties_surroundings_public_housing or properties_risks_all.

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 alternatives. It does not mention sibling tools like properties_risks_all or properties_surroundings_public_housing, nor any conditions that would make this the right choice. Usage is only implied by the name and the phrase 'near the parcel'.

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 discloses the record scope (Sold + For Sale) and the ordering (most-recent first), and adds the cost warning. With no annotations, the description carries behavioral responsibility, but it does not mention pagination, rate limits, empty-result behavior, or how "All" might be bounded. Still, the core behavior is stated.

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 description is extremely concise and front-loaded: the primary behavior appears in the first sentence, followed by a clearly formatted cost note. Every word earns its place and there is no wasted text.

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 tool with dozens of siblings and no annotations, this description is too minimal to be fully actionable. It omits parameter context and usage differentiation, although the output schema exists and partially compensates by documenting the response structure.

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?

The description provides no meaning for gnaf_id beyond what the schema already shows. Schema description coverage is 0%, so the description should compensate by explaining the parameter's format, role, or how to obtain it, but it does not.

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 clearly states the tool's resource: all Sold + For Sale records, most-recent first. It effectively distinguishes this from siblings like properties_sale_history_latest and properties_rent_history by emphasizing "All" and "Sold + For Sale", though it lacks an explicit verb like "returns".

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 explicit guidance is given about when to use this tool versus alternatives, nor are any exclusions or prerequisites mentioned. The description only implies that this is for retrieving full sale history, leaving the agent to infer the appropriate selection among many siblings.

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?

No annotations are provided, so the description carries the full burden. It mentions a cost of 10¢ per call, which is a transparent operational detail, but it does not disclose response format, pagination, error behavior, or any rate limits. For a read operation, the description does not clarify whether the record includes both sold and for-sale statuses, or how 'most-recent' is defined (e.g., by date). This is insufficient for a tool that likely has nuances.

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 description is very brief (one line plus pricing). It is concise and front-loads the core purpose. However, it may be too brief, omitting critical details; conciseness is good but not at the expense of necessary information. The pricing note is useful but could be placed elsewhere.

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 an output schema (not provided in the input), which may explain the return structure, so the description doesn't need to detail return values. However, for a tool that retrieves data, the description is incomplete: it doesn't specify what data fields are returned (even though output schema exists, the description should hint at what 'record' includes), nor does it mention any limitations or alternatives. Given the sibling count, the description is inadequate for correct selection.

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 0%, and the description does not explain the parameter 'gnaf_id' at all. The description only says it is a record for a property, but does not define what gnaf_id is (e.g., Geocoded National Address File identifier) or how it should be formatted. With a single required parameter, the description should at least clarify its semantics; it completely fails to do so.

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 'Most-recent Sold or For Sale record' clearly identifies the tool's purpose: retrieving the latest sale or listing record for a property. However, it does not explicitly differentiate from the sibling tool 'properties_sale_history' (likely the full history) or 'properties_sale_history_latest' (which may be an alias or distinct). The verb 'retrieve' is implied but not stated, and the resource is 'record' which is somewhat vague.

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 alternatives like properties_history_all or properties_sale_history. The description does not mention any conditions, exclusions, or prerequisites beyond the required gnaf_id. An agent is left to infer that it should use this tool when needing the most recent sale record, but no explicit direction 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?

With no annotations provided, the description must carry the burden of behavioral disclosure. It only states a cost, not what the tool does, what data it returns, or any side effects. This is entirely inadequate.

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 text is extremely short, but this is under-specification, not conciseness. The sole sentence about price does not earn its place as it provides no functional value. A score of 2 reflects the brevity without any useful content.

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?

The tool has an output schema, but the description is essentially empty. For a tool that returns school data for a property, the complete lack of functional description makes it impossible for an agent to use 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?

The schema has one required parameter 'gnaf_id' with no description, and the schema description coverage is 0%. The description adds nothing about the parameter's meaning, format, or expected values, leaving the agent without any guidance.

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 contains only a price note ('Price: 105¢ per call.') and gives no indication of what the tool does. There is no verb, resource, or functional statement. It fails to distinguish the tool from any sibling, especially properties_schools_nearby or properties_schools_ranking.

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 is provided on when to use this tool versus alternatives. The description does not mention any use case, prerequisites, or context that would help an agent select it.

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?

No annotations are provided, so the description carries the transparency burden. It does disclose the approximate 5km radius and the per-call price, which are useful behavioral traits, but it does not mention read-only status, rate limits, or error conditions. This is partial but not misleading.

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 description is extremely compact: one sentence for purpose/content and one sentence for pricing. Every word adds value, with 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?

For a one-parameter tool with an output schema, the description covers core purpose, scope, data content, and cost. However, it lacks parameter-level explanation and any usage differentiation among sibling school tools, leaving some context for correct selection and invocation incomplete.

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 0%, and the description only ties gnaf_id to 'the property' without explaining the identifier format, source, or constraints. It adds little meaning beyond the field name itself.

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 clearly states the tool returns schools within ~5km of the property and includes rank and student counts. It is specific enough to distinguish it from related property tools, but it does not explicitly differentiate it from sibling tools like properties_schools_all or properties_schools_ranking.

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 implies the tool should be used when nearby school information is needed, but it gives no explicit when-to-use or when-not-to-use guidance and does not name alternative tools. An agent would have to infer the appropriate selection among many sibling school tools.

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 no annotations, the description carries the burden and does state the approximate radius and ranking basis. However, it doesn't reveal ranking direction, how many schools are returned, data source, or whether results are based on current/catchment data. It doesn't contradict anything; it just stays thin.

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 content is a single front-loaded sentence, with the price as a separate callout. No filler or repetition. It's slightly thin, but as a compact definition it is well structured.

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 one parameter and an output schema, the description covers the essential result concept and price. It is incomplete in not explaining gnaf_id or usage context, but it's a minimal viable description for a simple endpoint.

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?

The only parameter, gnaf_id, is not explained at all in the description, and schema description coverage is 0%. The name may be conventional, but the description adds no meaning beyond the schema, so it doesn't compensate.

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 exact object (schools within ~5km of a property) and the operation/output (ranked by NAPLAN/socioeconomic score). It is clearly distinguishable from the sibling schools endpoints: 'all' and 'nearby' don't imply ranking.

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 statement about when to choose this over properties_schools_all or properties_schools_nearby, and no exclusions or prerequisites. The use case is only implied by the description, not explained.

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?

No annotations are provided, so the description must carry the full behavioral burden. It discloses the key behavior: it returns a 404 when no forecast row exists, and explains why it doesn't fall back to suburb-wide data. It also mentions the pricing (20¢ per call). It doesn't mention auth or rate limits, but those are likely global. The disclosure is helpful and non-obvious.

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 description is concise and front-loaded with the core purpose. The first sentence lists all the metrics, the second paragraph explains the 404 behavior, and the price note is separate. There is no wasted wording; it efficiently conveys the essential information.

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?

The output schema exists, so return values are covered. The description covers purpose, behavior, and price, but leaves the parameter undefined. For a single-parameter tool, explaining the parameter would make it complete. It also doesn't mention typical use cases beyond the property context, but given the schema and clear purpose, it's adequate though not thorough.

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?

The schema has 0% description coverage for the single parameter gnaf_id, and the description does not explain what it is or how to obtain it. It only implies it identifies the property. This is a significant gap since the agent must know what value to provide; the description should clarify that gnaf_id is the property's GNAF identifier.

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 clearly states the tool returns street-level property metrics (median price, forecasts, growth, turnover, renter share, houses/units) plus suburb-wide medians and a rank. It uses a specific verb ('returns') and resource ('the property's own street'), and distinguishes from suburb-wide tools by emphasizing the street focus and the comparison data.

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 implies usage for a property's street and contrasts with suburb-wide figures, noting it 404s rather than falling back. It doesn't explicitly name alternative tools like suburbs_street_forecasts, but the context of 'the property's own street' clearly scopes when to use it. It could be stronger with explicit alternatives, but the guidance is clear enough.

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