Microburbs Australian Property Data

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds significant value by disclosing that it is free, uses fuzzy token-based matching, handles plurals and Census synonyms, and covers ~17k fields. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed but efficient, front-loading the core purpose, then providing matching details, an example, and usage direction. Every sentence earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple search tool with no output schema, the description covers what it does, how to use results, pricing, matching nuances, and scale. An agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (both `limit` and `query` have descriptions). The description adds extra meaning by explaining that `query` performs fuzzy matching over field names/codes/topics/labels and gives concrete examples. It does not add much about `limit` but the schema covers it, so this is above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool discovers statistical fields via fuzzy search over ABS field names, codes, table topics, and column labels. It differentiates itself from the sibling `area_stats_values` by explicitly directing the agent to use returned codes with that route, making its purpose distinct.

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 explicit usage guidance: it is free, used for discovery, and the returned codes feed into the priced `/area-stats/SAL/{suburb}/values` route. It also explains the fuzzy matching behavior and synonym handling, so the agent knows when to prefer this over 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful extras: the cost signal 'Free (0c)' and the completeness claim 'every suburb, LGA, postcode, etc.' There is no contradiction, and the description does not overstate behavior beyond what a list endpoint would do.

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, front-loaded with the core action, and includes the valuable /values routing. However, 'Free (0c)' and '**Free.**' are redundant, repeating the same cost information twice. The duplication keeps it from a perfect 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?

The combination of the description and fully-covered schema gives an agent enough to call the tool correctly. Minor gaps exist around the exact output shape and default-limit behavior, but the schema already documents limits and defaults, and the purpose is simple enough that these are not critical.

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 baseline applies. The description adds only the contextual hint that returned names feed into /values, but it does not explain individual parameters beyond what the schema already provides. This is acceptable because region_level, limit, and query are each well-described in 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 states a specific verb 'List' and a clear resource: regions that exist at a level, with concrete examples ('every suburb, LGA, postcode'). It is immediately distinguishable from sibling tools like area_stats_fields because the target object, regions, is explicit. The title reinforces the same purpose 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?

The description explicitly routes the agent to use this tool to discover exact region names to pass to /values, which establishes a clear before-values workflow. It does not enumerate exclusions against other list tools like suburbs_list or lga_list, but within the area_stats family the routing is concrete and actionable.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the mode=sa1 behavior (per-SA1 breakdown) and the price per call, which are useful behavioral details beyond the annotations. It doesn't contradict annotations, but it doesn't disclose error handling or rate limits either.

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 three sentences, front-loaded with the purpose, and each sentence earns its place: the core function, the special mode behavior, and the price. No fluff 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?

Given the tool's simplicity and the schema covering all parameters, the description is complete enough. It explains the key behavioral switch (mode=sa1) and includes pricing, which is relevant context. Without an output schema, the description still clarifies that it returns 'statistical field values' for a region, which 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?

Schema description coverage is 100% and all parameters have detailed descriptions (e.g., fields: 'Comma-separated field codes (from /fields). Required, 1-5 per call.'). The description repeats this constraint and the mode behavior, but adds no new parameter semantics beyond the schema. Baseline 3 is appropriate when the schema carries the load.

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 ('statistical field values for one region') and a clear action (fetch by passing fields). It distinguishes from sibling tools like area_stats_fields and area_stats_regions, which likely list fields or regions rather than values. The name and title reinforce this.

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 implies when to use it: when you need statistical field values for a region. It also explains the special mode=sa1 for SAL level, giving context on a specific use case. It does not explicitly exclude alternatives or mention when not to use it, but the purpose 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?

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral details: returns up to 10 candidates, ranked by Meilisearch score, and costs 1¢ per call. It does not describe error cases or the exact response payload, but the core behavior is transparent.

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 tight and well-structured: action first, then prerequisite usage context, then output characteristics and pricing. Every sentence earns its place with no redundancy or 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?

For a single-parameter, read-only lookup tool, the description combined with the schema and annotations is complete. It explains the purpose, when to use it, the candidate limit and ranking, and the cost. Nothing needed for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already documents the single 'address' parameter with type, example, minLength, and a description. The tool description repeats 'freeform address string' but adds no meaningful semantic detail beyond what the schema 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 clearly states a specific verb and resource: 'Resolve a freeform address string to candidate G-NAF identifiers.' It also positions the tool as a prerequisite for property routes, which helps distinguish it from the many property tools. However, it does not explicitly differentiate it from the sibling geocode_suburb 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?

'Use this before calling any /v1/properties/{gnaf_id}/... route' is an explicit, concrete usage instruction with a clear rationale: those endpoints require a GNAF in the path. It lacks an explicit when-not-to-use or mention of geocode_suburb as an alternative, so it falls short of a 5.

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

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

Annotations already cover readOnly, idempotent, non-destructive. The description adds the free cost detail which is valuable and not in annotations. It also mentions the requirement to obtain canonical SAL names, which is behavioral context about the output's purpose.

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?

Very concise, two short paragraphs plus a bold 'Free.' The key usage context is front-loaded. Every sentence adds value - the autocomplete purpose, the prerequisite note, and the free cost indicator.

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 an autocomplete tool with simple parameters and no output schema, the description is complete. It explains why the tool exists (for canonical names), when to use it, and the cost. 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 parameters are well-documented. The description doesn't add much beyond that, but it reinforces the 'partial' nature of the q parameter which aligns with schema. No extra syntax needed, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it autocompletes a partial suburb search string against the ABS SAL list - specific verb and resource. It also distinguishes itself from the sibling geocode_address by focusing on suburb names. It even references the subsequent use of /v1/suburbs/{name}/... 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?

Explicitly tells when to use: before calling /v1/suburbs/{name}/... endpoints that require canonical SAL names. Also notes it's free, implying no cost considerations. It implicitly distinguishes from geocode_address which likely handles addresses.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the return shape, the flat-cost model, and the per-call price, which are genuinely useful behavioral details beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: it states the resource, the filter, the output shape, and the cost in four short pieces. Every sentence earns its place and there is 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?

For a simple list tool with one optional parameter, the description is complete: it specifies the output fields, the optional filter, the closed-world scope of all Australian LGAs, and the price. Since there is no output schema, providing the row shape is essential and is done well.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema already explains the state parameter including examples and national count. The description mostly restates the filter behavior, so it adds no significant semantic value 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 identifies the resource as all Australian LGAs and the operation as returning them, with an optional state filter. 'Returns {lga, state} per row' makes the tool's output explicit, and the naming/scope distinguishes it from lga_profile and region-list siblings.

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 optional state filter gives some usage direction, but the description never says when to prefer this tool over alternatives like lga_profile, sa4_list, or suburbs_list. The intended use is implied rather than 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?

Annotations already establish that this is read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond that: it clarifies that the hierarchy stops at state/GCCSA rather than continuing through SA4, and it discloses the per-call cost of 3 cents. It does not overpromise or contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely tight: two substantive sentences plus a pricing note. The key output scope and the important SA4 nesting caveat are front-loaded, and every clause earns its place without fluff 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, read-only lookup tool, the description covers the essential context: what is returned, what is deliberately not returned, and the cost. There is no output schema, but the description conveys the core response shape well enough. It is slightly light on input-format guidance, but the overall tool is simple.

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 only defines lga_name as a required string, and schema description coverage is 0%. The description indirectly indicates that the parameter is an LGA identifier by describing the tool as returning the LGA's parent chain, but it does not specify expected format, examples, or how names are resolved. For a single self-descriptive parameter this is adequate but not detailed.

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—LGA's parent chain—and the expected output scope: state plus GCCSA, with SA4 explicitly excluded. It lacks an explicit verb like 'returns' or 'gets', so it stops just short of a fully specific statement, but it is readily distinguishable from sibling tools like lga_list or sa4_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?

The description implies when to use the tool: when an LGA's upward geographic parent chain is needed. The caveat that LGAs are not strictly nested in SA4 gives useful usage context and sets an expectation about what this tool will not provide, though it does not explicitly name alternatives or state exclusion conditions.

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

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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint). The description adds valuable context: the requirement that 'sal' is currently the only supported scope, the pricing (3¢ per call), and a payload-size warning for LGAs. These go beyond the structured annotations and are useful for the agent.

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: two sentences plus a price line. The core purpose is front-loaded, followed by a constraint and a cost note. There is no fluff or redundant 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 tool is simple (one required param, no output schema, annotations cover safety). The description covers purpose, constraint, and price. It does not explicitly state the return format (e.g., list of codes), but that is largely inferable from the name and context. Adequate for the complexity.

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 parameter 'sal' is already described as a required suburb code. The description repeats this requirement without adding format, examples, or further semantics. It does not compensate for any schema gaps because there are none.

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 lists mesh-block codes for a given suburb, with a specific verb implied by the title and reinforced by the description. It distinguishes from siblings like mbs_profile (single mesh block) and suburbs_shapes_mesh_blocks (geometry) by noting the suburb-scoped listing and the current limitation to SAL.

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. It only mentions that other scopes (nationwide/LGA/SA3) are not yet available, which is a constraint, not a usage recommendation. There is no mention of sibling tools or conditions for selecting this one.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the cost per call (3¢) which is useful, but it does not describe any other behavioral aspects such as rate limits, authentication, or error handling. Since annotations cover the main behavioral traits, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of two lines, and front-loads the main content. The inclusion of pricing is efficient and useful. 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?

The description covers the main purpose and output structure (the chains), but lacks details on parameter format, return format (codes vs names), and error behavior. Given the tool's simplicity and annotation coverage, it's adequate but not 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?

The schema only defines mb_code as a string with no description, and the description does not explain the expected format or content of mb_code (e.g., whether it's a numeric code, length, or example). With 0% schema coverage, the description fails to compensate, leaving the agent without guidance on how to construct a valid 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 explicitly states that the tool returns the mesh block's upward ABS chain (SA1, SA2/3/4, GCCSA, state) and the parallel admin chain (LGA, suburb, postcode). This is specific about the resource (mesh block) and the output, distinguishing it from sibling profile tools like lga_profile or sa4_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 when a mesh block code is known and the parent geographic chains are needed, but it does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions or prerequisites. Given the clear subject, it's inferred 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds 'authoritative' and 'Free' as useful context, but does not describe authentication expectations, response shape, or any potential caching behavior.

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 front-load the purpose and add a cost note with no filler. 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?

For a zero-parameter account self-info tool, the description is nearly complete: it names the two outputs and the cost. Without an output schema, it could be more explicit about what 'key identity' includes, but the brevity is appropriate for such 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?

There are zero parameters jewellers, and schema description coverage is trivially 100%. The description correctly says nothing about parameters because there are none, meeting the baseline for a parameter-less 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 uses a specific verb ('Return') and names two concrete resources: key identity and the authoritative Autumn credit balance. This clearly distinguishes it from the data-query siblings, none of which cover account identity or credit balance.

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 use this tool: when an agent needs the current user's identity or authoritative credit balance. There are no plausible sibling alternatives for this purpose, so explicit exclusion is unnecessary.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool's safety profile is known. The description adds valuable behavioral context beyond these: 'No authentication required and not metered' and 'Returns immediately.' These details inform the agent that the tool is lightweight and has no side effects, which is useful for deciding to use it in polling scenarios. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of two sentences. The core purpose is front-loaded ('Returns immediately if the API is up'), followed by two important usage constraints (no auth, not metered) and a safety note. Every sentence adds value, and there is no wasted wording. It is well-structured and 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 simple, parameterless health check, the description is complete. It covers the tool's purpose, the conditions under which it should be used (polling from monitoring systems), and its safety profile (no auth, not metered). The annotations already handle the read-only and idempotent aspects. No output schema is present, but for a health check, the return format is likely trivial and not necessary to describe. An agent has all the information needed 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?

The tool has zero parameters, and the input schema is empty. Per the rubric, a zero-parameter tool receives a baseline score of 4 because there is no need for parameter documentation. The description appropriately focuses on the tool's behavior rather than parameters, which is correct for a parameterless health check.

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, specific purpose: 'Returns immediately if the API is up.' This identifies the tool as a health check, which is distinct from the many data-retrieval siblings. It names the resource (API) and the action (checking availability), so an agent can immediately understand what it does without confusion.

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 clear usage context: 'safe to poll from a load balancer, uptime monitor, or status dashboard without affecting your usage.' This tells the agent when it's appropriate to call the tool (for health checks and monitoring). However, it does not explicitly mention alternatives or when not to use it, such as distinguishing from ping_head, which is a sibling that likely performs a HEAD request. Still, the intended use case is well conveyed.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds useful extras: results are bucketed and nearest-first, and each call costs 10¢. That pricing disclosure is materially relevant to invocation decisions. Rate limits/auth are not mentioned, but the annotation safety profile lowers the burden.

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 tight sentences: the first front-loads the output categories, radius, and ordering; the second states the price. There is no filler, and the backtick parameter reference is precise.

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 read-only lookup, this covers the output categories, radius, ordering behavior, and cost, with safety covered by annotations. It does not describe the exact return shape or clarify that gnaf_id identifies the property, so it is slightly incomplete for an agent without prior 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?

The schema already documents radius_m fully, and the description merely reuses it as a radius filter rather than adding parameter detail. The required gnaf_id has no schema description and the description does not explain it either, so at 50% schema coverage the definition under-serves 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 clearly names the resource—curated nearby amenities for a property—and specifies the categories and radius behavior, so an agent can tell it is an amenity lookup. It lacks an explicit verb such as 'Returns' and does not name any sibling, though the category list implicitly separates it from transport/schools nearby 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?

Usage context is implied: an agent should call this when it needs supermarkets, green spaces, or restaurants/cafes around a property. There is no explicit when-to-use/when-not-to-use guidance or alternative routing, which matters given nearby sibling tools like properties_transport_nearby and properties_schools_nearby.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the bar for additional disclosure is lower; even so, the description contributes zero behavioral context beyond the price. Pricing is not a behavioral trait.

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 not concise in a useful way: the single sentence is spent on price rather than tool behavior, so this is under-specification rather than well-structured completeness.

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 output schema, and many closely related sibling endpoints, the description is severely incomplete. Nothing in the description tells the agent what data will be returned or how this bundled call relates to the individual properties_basics_* tools.

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 mention gnaf_id or explain what value to pass or what its format is. The parameter name is suggestive, but the description itself adds no semantic meaning.

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 text is only '**Price: 23¢ per call.**' – it never states what action the tool performs or what 'all basics' includes. The name and title hint at a bundle of basic property attributes for a G-NAF ID, but that is inference, not a stated 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?

No when-to-use guidance is given, and no alternatives are mentioned despite an extensive sibling set including properties_basics_bath_count, properties_basics_bed_count, properties_basics_dwelling_type, etc. An agent cannot determine whether to call this bundle or a specific basics endpoint.

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

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

Annotations already disclose read-only, idempotent, and non-destructive behavior, so the description only adds 'latest matching listing' and the explicit 5¢ per-call price. It does not discuss no-match behavior, missing bathroom data, or response format, but with annotations present this is acceptable.

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 the primary function first and the cost isolated as a separate line. No filler, repetition, or unnecessary schema 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?

For a one-parameter, read-only lookup, the main purpose and cost are covered, and there is no output schema to document. However, the missing parameter definition and absence of guidance for no-match or missing-value cases leave it minimally adequate rather than 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 never names or defines gnaf_id. The only hint is 'matching listing,' which weakly connects the required parameter to the property identifier, but format, source, and required-value semantics are left 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 the exact result ('Bathroom count') and its source ('from the latest matching listing'), so an agent knows what data it returns. It relies on the title and sibling names rather than explicit wording to distinguish it from properties_basics_bed_count and similar tools, which keeps it from 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?

No guidance is given on when to call this tool instead of sibling tools like properties_basics_bed_count, properties_basics_dwelling_type, or properties_basics_all. The phrase 'latest matching listing' implies recency but does not state selection criteria, 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?

Annotations already declare readOnly, idempotent, and non-destructive behavior, lowering the burden on the description. The description adds the 'latest matching listing' nuance and the per-call price, but it does not clarify behavior when no listing exists, whether null is possible, or what the return shape is.

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 first states the result, and the second states the price. The essential information is front-loaded and 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?

For a tool with one required parameter and no output schema, the description omits important context: what gnaf_id means, what the returned value looks like, and what happens if no matching listing exists. It is minimally usable but leaves ambiguity.

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 gnaf_id, and the description does not explain that this parameter identifies the property. While the parameter name is suggestive, no format, source, or example is provided, so the description fails to 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 result is a 'bedroom count from the latest matching listing', which clearly identifies the resource (property) and field (bed count). However, it does not explicitly differentiate itself from sibling tools like properties_basics_bath_count or properties_basics_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?

No guidance is given on when to use this tool versus the many related property basics tools. The description implies a simple single-field lookup but provides no exclusions, prerequisites, or alternative 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the price (5¢ per call) and examples of possible values, which are useful behavioral context. However, it does not describe error behavior, what happens if gnaf_id is invalid, or the return format beyond examples. Since annotations carry the safety burden, this is adequate but not 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?

The description is extremely concise: two sentences, one for the purpose and one for the price. It is front-loaded with the main purpose and contains no fluff. 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?

For a single-parameter read-only lookup with no output schema, the description is mostly sufficient: it states the purpose and gives examples. However, it omits usage guidance (when to use vs siblings) and does not describe the return structure or any error conditions. Given the tool's simplicity and the annotations covering safety, it 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?

The schema has a single required parameter gnaf_id with no description (schema coverage 0%). The tool description does not explain what gnaf_id is or how to obtain it. The name 'gnaf_id' suggests a geocoded national address identifier, but the description provides no guidance on its format or source. The description adds no meaning to the parameter beyond the parameter 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 the dwelling type (house, unit, townhouse, etc.) for a property. It is specific about the resource and the value domain, but does not differentiate it from sibling tools like properties_basics_all which might also return this field. The verb is implied (returns) and the resource is a property via gnaf_id.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus the many siblings such as properties_basics_all, properties_basics_bed_count, etc. The description does not mention any alternatives or conditions for selection. An agent would have to infer from the name that this is a specific attribute lookup.

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

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

Annotations already communicate read-only, idempotent, and non-destructive behavior, so the description only needs to add context beyond that. It adds the cadastral-feed source and the per-call price, but does not disclose response shape or failure modes. This is adequate but not 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 short sentences, each with a distinct purpose: state what the tool returns and where the data comes from, then disclose the cost. There is no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, read-only, well-annotated tool, this is nearly complete: the schema supplies the required input, the description states the output unit and source, and annotations cover safety. The main missing piece is explicit parameter semantics, but the overall complexity is low.

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 sole parameter gnaf_id has no schema description (0% coverage), and the description does not explain what a GNAF ID is, what format it takes, or how to obtain one. The description adds no parameter-level meaning beyond the schema's name and type.

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 ('parcel land area'), the unit ('square metres'), and the data source ('cadastral feed'), which distinguishes it from sibling basic-property tools like bed count or dwelling type. It lacks an explicit verb, but the noun-phrase form 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 guidance on when to use this tool instead of properties_basics_all or properties_valuation_land_values, and no mention of how to obtain a gnaf_id or what prerequisites exist. The agent must infer usage context entirely from the name and schema.

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

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

The description adds useful context beyond the annotations: it specifies the data source ('latest matching listing') and the cost ('5¢ per call'). However, the annotations already cover read-only, idempotent, and non-destructive hints, so the description's added behavioral info is limited to the listing lookup nuance and pricing. It does not disclose potential error conditions or response format.

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—one line plus the price—with no fluff. It front-loads the core purpose. However, it is arguably too terse to be fully useful; the brevity is appropriate but comes at the cost of missing essential details.

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 low complexity (single parameter, no output schema), the description is incomplete. It does not clarify what gnaf_id refers to, what 'latest matching listing' means, or what the return value looks like (e.g., an integer count). Without an output schema, these gaps leave the agent guessing about the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has zero description coverage for the sole parameter gnaf_id, and the description does not explain what this identifier is or how it is used. For a single-parameter tool, the description should at least indicate that gnaf_id identifies the property; it fails to compensate for the schema's lack of detail.

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 a parking-space count from the latest matching listing, specifying the resource (property) and the attribute (parking count). It does not explicitly differentiate from sibling tools like properties_basics_bath_count or bed_count, but the naming convention and the 'latest matching listing' qualifier make the intent 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?

There is no guidance on when to use this tool versus alternatives such as properties_basics_all or the other per-attribute basics tools. The description does not mention conditions or exclusions, leaving the agent to infer usage context from the tool 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?

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds no behavioral information. It does not mention that it is read-only, nor does it disclose any operational characteristics such as response format or rate limits. The pricing note is not behavioral disclosure.

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 not concisely informative; it is a pricing string with no functional content. It is under-specified rather than concise, providing no structure or front-loaded useful 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 tool that likely returns a bundle of comparable property data, the description is completely inadequate. There is no explanation of output, required parameter, or intended use case. Given the complexity implied by the name and sibling tools, the description leaves an agent without any guidance.

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 (gnaf_id) with no description, and schema coverage is 0%. The description does not explain what gnaf_id represents or how it should be provided. It adds zero meaning beyond the raw type.

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 a pricing note ('Price: 74¢ per call.') and does not state what the tool does. The name hints at 'All comparables — bundle', but the description provides no verb, resource, or scope. It fails to distinguish from siblings like properties_comparables_cma_comp_set.

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. There is no mention of when to call it, what inputs are expected, or any exclusions. The pricing note gives no usage 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the cost per call (60¢) and clarifies the output is a top comparable set, which is useful but does not disclose return format, pagination, or any limitations beyond what annotations imply.

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 brief and front-loaded with the core purpose, followed by a useful pricing note. No unnecessary words are present, though the extreme brevity leaves out important operational context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter tool with no output schema, the description should at least clarify what data is returned and what gnaf_id refers to. It only states 'top comparable sales' and a price, leaving an agent to guess about response structure, parameter semantics, and how this compares to related tools.

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 gnaf_id or how it relates to the subject property. The phrase 'subject property's value' weakly implies gnaf_id identifies that property, but the description does not compensate for the lack of 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 the tool returns top comparable sales used to triangulate the subject property's value, which identifies both the resource (comparable sales) and the purpose (valuation triangulation). It is clear enough to distinguish from sibling tools like properties_comparables_all by 'top comparable sales', 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?

There is no guidance on when to use this tool versus sibling tools such as properties_comparables_all, properties_comparables_cma_single_comp, or properties_comparables_recent_sales_nearby. The phrase 'used to triangulate... value' implies a use case, but no explicit context, exclusions, or alternative routing 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?

The description adds the selection criterion 'highest dist_score' and the pricing detail, which go beyond the annotations that already declare readOnlyHint, idempotentHint, and destructiveHint. However, it does not disclose what happens if no comparable exists, error behavior, or the exact structure of the returned comparable. The annotations cover safety, but the behavioral context is sparse.

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—one sentence and a pricing note. It gets to the point without wasted words. It is front-loaded with the core purpose. However, it is so brief that it omits essential parameter and usage details, which slightly detracts from its effectiveness.

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 parameter and no output schema, the description should explain what 'comparable' means, what dist_score is, and what the return value looks like. It only says 'single best comparable' without elaboration. The annotations cover read-only and idempotency, but the description leaves significant gaps 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 description does not explain the gnaf_id parameter at all. Schema description coverage is 0%, and the description fails to compensate by describing what gnaf_id represents or how it is used. The agent is left to infer that it identifies the property, but this is not stated.

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 the single best comparable from the CMA set, selected by highest dist_score. This clearly distinguishes it from siblings like properties_comparables_all (all comparables) and properties_comparables_cma_comp_set (the set). 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?

No guidance is provided on when to use this tool versus the alternative comparable tools. The name implies it is for the single best comparable, but the description does not explicitly say 'use this when you need only the best' or contrast with the all/set variants. No exclusion criteria or context is given.

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

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

Annotations already establish a read-only, idempotent, non-destructive operation. The description adds pricing transparency (4¢ per call) but does not disclose radius size, result count, default ordering, or empty-result behavior. With annotations covering safety, this is adequate but 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 description is short and front-loaded: first sentence states the data returned, second states the cost. No filler is present, though it is terse enough that key details are omitted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should explain what a call actually returns, but it only says 'recent comparable sales' without clarifying fields, radius size, sorting, or limits. Given 80+ siblings, the lack of routing context also hurts 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 provides only a gnaf_id string with 0% coverage, and the description does not explain what gnaf_id is, where to obtain it, or how it maps to the 'subject parcel'. The phrase 'subject parcel' is an implicit tie, but it does not add meaningful parameter 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 states that the tool returns recent comparable sales within a small radius of the subject parcel, which is a clear resource and scope. It does not explicitly name sibling alternatives or use a verb like 'returns', so it misses 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?

No guidance is given about when to prefer this tool over sibling comparables tools such as properties_comparables_all or properties_comparables_cma_comp_set. The phrase 'small radius' implies a use case, but no conditions, exclusions, or alternatives are 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?

Annotations already establish read-only, idempotent, and non-destructive behavior, so the description does not need to repeat that. It adds useful behavioral context beyond annotations: the 30¢ per-call cost, the GeoJSON output format, and the 1 km buffer scope with per-mesh-block stats. It does not contradict any annotation.

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 dense sentences with no filler. The primary output and its stats are front-loaded, and the price is cleanly separated at the end. 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 read-only tool, the description covers the output format, scope, and cost, and lists the included stats. However, the required gnaf_id remains undocumented, and there is no nod to when this fits among the many related property-context siblings. With no output schema, slightly more structural or usage context would be needed to be fully self-contained.

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%: geojson is well documented in the schema, but the required gnaf_id has no schema description and the description does not explain its format or role beyond the word 'property'. The description adds essentially no parameter meaning beyond what the schema already provides for geojson.

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 and scope precisely: GeoJSON mesh-block polygons within a 1 km buffer of the property, with the accompanying per-block statistics. This is enough to distinguish it from related shape/stat tools such as suburbs_shapes_mesh_blocks and mbs_list. It lacks an explicit verb like 'returns' or 'lists', but the deliverable 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?

There is no guidance on when to use this tool versus the many nearby sibling tools, such as properties_context_nearby_for_sale, properties_surroundings_properties, or suburbs_shapes_mesh_blocks. The only operational note is the price, which does not help an agent choose among 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: results are newest first, capped at 30, and include AVM and rent-yield comparison. It also discloses the price (20¢ per call), which is a meaningful operational detail beyond annotations. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences plus a pricing note. It front-loads the core purpose, then adds the key constraints (newest first, max 30, AVM/rent-yield comparison) and pricing. Every sentence earns its place; no filler or repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only list tool with annotations covering safety and idempotency, the description is largely complete. It states the result ordering, cap, and included comparisons. The main gap is that gnaf_id is not explained, and there is no output schema, so the agent doesn't know the exact return shape. However, the description's mention of AVM and rent-yield comparison gives a reasonable sense of the output. A 4 is fair.

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%: radius_km has a description, but gnaf_id has none. The description adds meaning by explaining that radius_km is the search radius and that results are limited to 30, but it doesn't explain what gnaf_id is or how to obtain it. Since the schema covers half the parameters and the description partially compensates, a 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: returns currently for-sale listings within a radius of the property, with AVM and rent-yield comparison. It distinguishes itself from sibling tools like properties_comparables_recent_sales_nearby and suburbs_listings_for_sale by focusing on nearby for-sale listings around a specific property with AVM/rent-yield comparison. However, it doesn't explicitly name a sibling alternative, so it doesn't fully earn 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 implies usage context: when you need for-sale listings near a property with AVM and rent-yield comparison. It does not explicitly state when to use this vs alternatives like properties_comparables_recent_sales_nearby or properties_sale_history. The radius_km parameter and 'newest first, max 30' provide some context, but no explicit exclusions or alternative 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?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the cost of 15¢ per call and clarifies the bedroom band comes from listing history. These are useful but do not go beyond the safety profile already handled by annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: one sentence describing the data content and a separate bolded cost line. Every word earns its place, and the cost is clearly separated. No redundancy or 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?

For a tool with one parameter and no output schema, the description conveys the core return content (bedroom band and 10-year price series) and the per-call cost. However, it omits practical information such as how to obtain a valid gnaf_id and what exactly the price series contains (e.g., median, annual), so it is minimally adequate rather than 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?

With 0% schema description coverage, the description must explain the single parameter, gnaf_id, but it does not. It only refers to 'the subject', never explicitly mapping that to the gnaf_id input or describing its format. The name alone is insufficient for an agent unfamiliar with the domain.

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 specifies a distinct data resource: the subject property's bedroom band and the suburb's 10-year price series for that band. It clearly differentiates from siblings like properties_basics_bed_count or properties_sale_history, though it lacks an explicit verb such as 'returns' or 'provides'.

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 instead of alternatives. There are no conditions, exclusions, or references to sibling tools, leaving the agent to infer usage solely from the name and description.

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

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

Annotations declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds no behavioral context beyond the price. It does not contradict annotations, but it contributes nothing about data scope, return format, or edge cases. The description fails to disclose any meaningful behavior.

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, not conciseness. The single sentence about pricing does not earn its place as a substitute for a functional description. It omits essential information and is not front-loaded with 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?

For a tool that bundles all planning data for a property, with one required parameter and no output schema, the description is completely inadequate. An agent cannot determine what data is returned, how to interpret the result, or when to use it. The description leaves all critical context 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 description coverage is 0% and the description does not explain the gnaf_id parameter at all. The name hints at a GNAF identifier, but the description provides no clarification of its format, semantics, or required value. The parameter is left entirely undefined.

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 the price ('**Price: 8¢ per call.**') and provides no statement of what the tool does. The name and title hint at a planning bundle, but the description itself does not define the verb, resource, or scope. It fails to distinguish from many related planning 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?

There is no guidance on when to use this tool versus the numerous sibling tools such as properties_development_zoning_code or properties_development_zoning_overlays. No context, alternatives, or exclusions are mentioned.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety behavior. The description adds useful context by noting the code is returned only 'when the council ships one,' implying possible absence, and enumerates the returned fields. However, it does not describe what happens when the council does not provide a code, or any rate-limit/auth behavior.

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 definition is two sparse sentences: it states the output, the caveat, and the price with no filler. Every sentence earns its place and the most important identifying information 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?

For a one-parameter, read-only, idempotent tool, the description covers the primary output, the conditional absence, and the price. Still, it omits any explanation of gnaf_id and the empty/missing-data behavior, so an agent must infer identifier semantics from the name alone.

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 for the undocumented gnaf_id parameter. It only says 'at the property's point' and never explains what a GNAF ID is, its expected format, or how to obtain it. The bare parameter name leaves too much to inference.

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 primary zoning code at the property's point, along with the human-readable name and the broader category. It distinguishes from overlay-focused siblings through the word 'primary' and the listed return fields, but it has no explicit verb and does not name a sibling.

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 over properties_development_zoning_overlays or properties_development_all. The 'primary' wording implies this is the base zoning result, but there are no explicit when-to-use or when-not-to-use instructions, nor any prerequisites for obtaining gnaf_id.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is safe and idempotent. The description adds the cost note and the spatial scope (intersecting the parcel). However, it does not disclose the structure of the returned overlays or whether multiple overlays are returned. Given annotations, a score of 3 is reasonable.

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 sentences: the first clearly states what the tool does, and the second gives the pricing. It is front-loaded with the key information and has no wasteful content. This is an example of effective conciseness.

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, no output schema, and clear annotations. The description provides minimal but sufficient context for a simple lookup. However, it lacks guidance on what the output will contain (e.g., list of overlay names), which could be important for the agent to know if it needs further processing. It is adequate but not rich.

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 only the 'gnaf_id' parameter with 0% description coverage Rosetta Stone. The description does not explain what 'gnaf_id' is or how to obtain it, but the tool's name and context suggest it is a property identifier. Since there is only one parameter and it is likely common across sibling tools, the schema's type definition is minimal. The description could add 'the property's G-NAF identifier' but does not. Baseline 3 is okay.

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 development overlays that intersect a property's parcel, which is clear enough. However, it does not explain what 'development overlays' are or how they differ from the sibling tool 'properties_development_zoning_code' and 'properties_development_all'. The purpose is clear but lacks 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?

There is no guidance on when to use this tool versus alternatives like 'properties_development_zoning_code' or 'properties_development_all'. It only mentions that it requires a 'gnaf_id' implicitly through the schema, but does not direct the agent to alternative tools for zoning codes or broader development data. This is a significant gap for a tool in a large family.

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 annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds one behavioral/operational detail: the call costs 80¢. It does not describe response behavior, scope, or bundle composition, but there is no contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one short sentence, but it is under-specified rather than genuinely concise. It spends its only sentence on pricing while omitting the core purpose, making the structure unhelpful for tool selection.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only one-parameter tool with no output schema, the definition omits what the tool returns, what 'bundle' includes, and how it differs from the separate sale/rent history tools. The title hints at the purpose, but the description is far from complete enough for correct 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?

The single required parameter gnaf_id has 0% schema description coverage, and the description provides no meaning, format, or usage guidance for it. The agent is left with only the parameter name and type.

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: 80¢ per call.' and never states what the tool does. The purpose must be inferred from the title and name, and there is no verb/resource statement to distinguish it from sibling history 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?

There is no guidance on when to use this tool versus alternatives like properties_sale_history or properties_rent_history. The price-only text provides no selection criteria, exclusions, or context for choosing the bundle.

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

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

Annotations already provide read-only, idempotent, and non-destructive hints, but the description adds value by specifying the enrichment details (address, property type, bed/bath/garage) and pricing (30¢ per call), which helps the agent anticipate cost and data scope without redundant repetition.

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, with two sentences. The first sentence is information-dense, stating the core function and enrichment details. The second sentence provides pricing. No wasted words, and the most critical information 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?

For a simple tool with one parameter and no output schema, the description is mostly adequate but missing key context about the required parameter (GNAF ID). It does not mention the output format or any edge cases. Given the tool's simplicity, it is minimally sufficient, but more guidance on the parameter would improve 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?

Schema coverage is 0%, meaning the parameter 'gnaf_id' is undocumented in the schema. The description does not explain what a GNAF ID is or how to obtain it. However, the description implies it is a property identifier, but it does not provide format or source guidance, so the description partially compensates but not fully.

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 adjoining-parcel neighbours enriched with data from the latest matching listing, using a specific identifier. It distinguishes from similar tools like 'suburbs_hero_neighbours' and 'properties_context_nearby_for_sale' by focusing on property-level neighbours with listing enrichment.

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 does not mention when not to use it or under what conditions a different tool is preferable. The agent must infer usage from the name and description alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds valuable operational context: the price per call (3¢) and the scope of the response (full hierarchy and admin chain), which go beyond the annotations. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences plus a price note, with the primary function front-loaded. There is no redundancy or filler; every word earns its place. The price is clearly highlighted at the end, making it easy for the agent 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 simplicity (one parameter, read-only, no output schema), the description covers the core purpose, the scope of the return (hierarchy and admin chain), and cost. It does not detail the exact output fields or error handling, but for a profile tool that returns a known set of ABS keys, this is likely adequate. The mention of 'every ABS key' provides sufficient context for the agent.

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 only gnaf_id with 0% description coverage, so the description must compensate. The phrase 'Resolve a GNAF' explicitly indicates that gnaf_id is a GNAF identifier, adding meaning beyond the bare schema. While it does not specify the format or origin of the GNAF, for a single required parameter this is sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (resolve) and resource (GNAF) with a clear outcome: the full ABS Statistical Geography Standard hierarchy and parallel admin chain. It distinguishes from siblings like geocode_address by focusing on the comprehensive geo-profile rather than a single geocoding result. The phrase 'Call this once to get every ABS key' reinforces its purpose as the one-stop tool for ABS keys.

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 implies usage: use it when you need the full ABS hierarchy for a given GNAF. The explicit 'Call this once' suggests it is the primary method for that need, but it does not name specific alternatives or state when not to use it. This is clear context but lacks explicit exclusions, so a 4 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds scope ('All For Rent records'), sort order, and price, but does not disclose pagination behavior, response size, or any access limitations.

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, with the core behavior front-loaded in the first sentence and the pricing clearly separated. There is no filler or redundant restatement of the 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 tool with one required parameter and no output schema, the missing parameter semantics and lack of sibling differentiation leave real gaps. An agent could call it, but correctly interpreting gnaf_id and choosing this over properties_rent_history_latest requires guesswork.

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 explains what gnaf_id means, what format it should take, or how it maps to the property. The parameter name hints at a geographic identifier, but the agent receives no explicit 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 states a clear resource ('All For Rent records') and an ordering ('most-recent first'), which distinguishes it from a single-latest record endpoint. It doesn't explicitly name the sibling alternative, but the scope is specific enough to understand the tool's function.

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 closely related siblings like properties_rent_history_latest, properties_sale_history, or properties_history_all. The intended selection criteria are only implied by the name and title.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description need not repeat safety. It does add a crucial behavioral detail: 'Price: 10¢ per call,' which is useful cost information. However, it does not describe the response format or whether the record includes all fields or just rent amount, leaving some behavioral transparency gaps.

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 a single clear sentence plus pricing. It is front-loaded with the core purpose. However, it is so minimal that it borders on under-specification rather than efficient conciseness, though the structure itself is clean.

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 there is no output schema, the description should clarify what the response contains, but it does not. It also fails to explain the parameter or any edge cases (e.g., what happens if no rent history exists). The tool is simple but the description leaves too much to the agent's inference, especially with no parameter documentation.

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, has 0% schema description coverage. The description does not explain what gnaf_id is, how to obtain it, or any format details. Since the schema provides no help and the description adds nothing, the parameter semantics are essentially undocumented, making this a critical 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 'Most-recent For Rent record,' which clearly identifies the operation: returning the latest rent record for a property. Combined with the title, it distinguishes itself from properties_rent_history (full history) and properties_sale_history_latest (sales version). The verb is implied but the resource is explicit 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?

No guidance is provided on when to use this tool versus properties_rent_history or other property history tools. It does not state that this is for the single most recent observation, nor does it mention alternatives. The usage is implied by the name but not explicitly 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?

Annotations already establish the operation as read-only, idempotent, and non-destructive, so the description only needs to add non-obvious behavior. It does explain the geojson=true behavior, including the 1km-radius clipping and the inclusion of geojson_meta. However, it contains a contradictory pricing statement ( 'Flat 30¢' vs '**Price: 48¢ per call.**' ), which undermines its reliability as a behavioral/contractual disclosure.

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 the pricing information is presented twice and with conflicting values: first 'Flat 30¢' and later '**Price: 48¢ per call.**'. This redundancy and inconsistency suggests a lack of careful editing and reduces the clarity of an otherwise brief definition. The core behavioral information is front-loaded, but the price contradiction is a structural flaw.

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 endpoint with read-only/idempotent annotations, the description covers the primary behavior (all risk overlays in one call) and explains the optional geojson enhancement. It does not describe the default response payload or how the various risk overlays are presented, but the lack of an output schema makes a more verbose contract description desirable. The pricing mistake is a minor gap in an otherwise complete definition.

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 provides a full description of the geojson parameter, and the description essentially restates that behavior without adding new meaning. The required gnaf_id parameter is not described in the schema or in the description, leaving the caller to infer it is a property identifier. With 50% schema coverage boundaries, the description should have clarified gnaf_id, 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 phrase 'Every property-level risk overlay in one call' clearly indicates that this tool returns all risk overlays for a property in a single request. The title 'bundle' and the presence of individual risk sibling tools help distinguish it from single-overlay endpoints. It lacks an explicit verb like 'retrieve', but the usage context is unmistakable.

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 emphasizes that this is a bundle of all property risk overlays, implying it should be used when a caller wants all overlays at once rather than calling individual overlay endpoints like properties_risks_bushfire. However, it does not explicitly state when to prefer this over the individual tools, nor does it mention any limitations or when those alternatives would be better. The 'may grow' note hints at long-term stability of the offering but offers no direct comparison.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds genuinely new behavioral context: the 1 km radius, the crucial 'found nearby ≠ on-property' semantics, and the 15¢ cost per call — none of which are in the structured 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?

Two sentences plus a bolded price line. The core function is front-loaded, and every clause earns its place — the semantic clarification and price are both high-value, non-redundant 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 read-only tool with one required parameter and no output schema, the description covers the essential ground: the search radius, the misinterpretation risk, and the cost. It doesn't enumerate the full response shape, but the single most dangerous semantic trap is explicitly disclosed.

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 required `gnaf_id` is undocumented in both the schema and the description, which fails to compensate for that gap. The 1 km radius mention adds little value since the schema's geojson parameter already states the 1km-radius clipping behavior.

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 action and resource: bushfire-prone-area overlays within 1 km of a property. The title and scope differentiate it from the suburb-level suburbs_risks_bushfire and the other properties_risks_* hazard tools, though it never explicitly names a sibling.

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?

When to use the tool is implied by the property-scoped 1 km framing, but there is no explicit when-to-use or when-not-to-use guidance and no alternative tool is named. The `on_property` clarification is about interpreting results, not about selecting between competing 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds a useful price signal and names the risk categories returned, but does not disclose output format, geometry type, or any other runtime behavior beyond what annotations imply.

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, followed by the price. There is no filler or repetition of annotations, and every sentence earns its place, though the content is thin.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should at least hint at what the overlay contains or returns; it only gives examples without explaining the response shape or how detailed the risk data is. The one required parameter is not explained, and there is no routing guidance among the many sibling risk tools, leaving the definition incomplete for reliable 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 description does not mention gnaf_id at all. Since the schema provides no explanation and the description does not compensate, an agent gets no help understanding what identifier to supply or how it relates to the property.

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 as an environmental-risk overlay and gives concrete examples (contamination, salinity), which distinguishes it from sibling risk tools like bushfire, flood, or erosion. It lacks an explicit verb such as 'get' or 'return', but the noun-phrase style still communicates the tool's subject well.

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 alternatives like properties_risks_all, properties_risks_bushfire, or properties_risks_flood. The subject matter is implied, but there are no explicit when-to-use, when-not-to-use, or alternative-routing instructions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond annotations by clarifying the spatial semantics of a returned row, preventing a likely misinterpretation of the result. It also discloses the per-call price, which is helpful operational context.

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 exceptionally concise: two sentences that front-load the core purpose, then add the critical result-interpretation caveat and pricing. Every sentence earns its place, 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?

For a simple read-only lookup with one required parameterid and a boolean option, the description covers the core purpose, spatial scope, result semantics, and cost. It does not describe the full response shape, but there is no output schema and the `on_property` mention gives enough signal about what to expect. The main minor gap is parameter semantics for `gnaf_id`.

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 beyond its name. The tool description does not compensate for this gap—it does not explain that `gnaf_id` identifies the property or specify the expected identifier format. The 'within 1 km' mention adds spatial context but not parameter-level 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?

States a specific resource (coastal/soil erosion overlays) and a precise spatial scope ('within 1 km'), with a verb 'Read' that makes the operation clear. It does not explicitly differentiate itself from sibling risk tools like properties_risks_flood, but the erosion-specific subject matter makes its 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?

Provides clear interpretive guidance on reading the `on_property` result, warning that a returned row means 'found nearby' rather than 'this property is eroding.' This is strong usage context, though it does not explicitly state when to choose this tool over alternatives such as properties_risks_all or properties_risks_flood.

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

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

Annotations already cover read-only and idempotent behavior. The description adds meaningful behavioral context: results are modelled, limited to 1 km, the non-intuitive on_property semantics, and the 10¢ per call cost. This goes beyond what annotations provide.

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 plus a price callout. The core purpose is front-loaded, followed by the critical interpretation caveat and cost. 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?

Given the tool's simplicity, strong annotations, and helpful geojson schema, the description is nearly complete. It covers purpose, proximity semantics, and cost. It does not describe the full response shape beyond on_property, and there is no output schema, so a small gap remains.

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 well, including its clipping radius. The tool description reinforces the 1 km scope but does not explain gnaf_id or add parameter-level meaning beyond the schema. With 50% schema coverage, the description partially compensates but not fully.

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 what the tool provides: modelled flood overlays within 1 km. The resource and scope are specific. However, it does not explicitly differentiate from close siblings like properties_risks_historical_flood or properties_risks_all, 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 usage is implied from the purpose, and the description gives an important interpretation caveat ('a returned row means found nearby, not this property floods'). However, it does not say when to prefer this tool over alternative flood/risk tools, nor does it provide explicit exclusions or alternative 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the 'found nearby' vs 'is heritage-listed' distinction, the 1 km radius, and the pricing note (3¢ per call). It doesn't describe pagination or response format, but the key behavioral nuance is disclosed.

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 with zero waste. The critical semantic clarification ('found nearby', not 'heritage-listed') is front-loaded, followed by the radius scope and pricing. 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 simple read-only tool with 2 parameters and no output schema, the description covers the essential context: what it returns, the radius, the semantic caveat, and cost. It doesn't describe the response structure, but with no output schema and a simple boolean geojson parameter, the description is largely complete. A minor gap is not explaining what fields appear in a returned row.

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 doesn't add meaning for gnaf_id beyond the schema. The 'within 1 km' context helps interpret the geojson clipping behavior, but the description doesn't compensate for the undocumented gnaf_id parameter. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Heritage-listing overlays within 1 km' and clarifies the key semantic distinction that a returned row means 'found nearby', not 'this property is heritage-listed'. This clearly distinguishes it from sibling tools like properties_risks_all or properties_development_zoning_overlays.

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 for when to use the tool: when you need heritage-listing overlays within 1 km of a property. It doesn't explicitly name alternatives or exclusions, but the 'within 1 km' scope and the 'found nearby' clarification imply the use case. It could be improved by explicitly contrasting with a sibling like properties_risks_all or suburbs_risks_heritage_share.

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

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds valuable non-obvious semantics: a returned row means 'found nearby', not that the property itself flooded, and it discloses the 3¢ per-call cost. This goes beyond the structured annotations without contradicting them.

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?

Every sentence earns its place: the data scope, the critical interpretation warning, and the price. It is short, front-loaded, and free of 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?

For a single-parameter, read-only tool, the description is largely complete: it states the data returned, the key misinterpretation risk, and cost. It could be more complete by describing the output structure and when to use the sibling flood tool, but the essential calling context is present.

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, its format, or how it identifies the property. The mention of on_property relates to output, not input, so the description fails to compensate for the low 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 description clearly states the tool returns recorded historical flood extents within 1 km, with a specific resource and scope. It does not explicitly name or differentiate the sibling properties_risks_flood, but the 'historical-flood overlay' title and 'within 1 km' scope make the purpose reasonably distinct.

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 use case: query historical flood extents for a property via gnaf_id. It provides no explicit when-to-use guidance or alternatives, such as pointing to properties_risks_flood for current flood risk, but the context is enough to infer the basic scenario.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the price and a vague 'near the parcel' but does not disclose what the tool returns (e.g., a boolean, a distance, or a detailed report). Without an output schema, this lack of behavioral detail 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 extremely concise, using two sentences to state the purpose and price. It is front-loaded with the core function and includes the cost, which is useful. However, it is so brief that it sacrifices essential detail; this is conciseness but not necessarily effective communication.

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's simplicity (one parameter, no output schema), the description is minimal but insufficient. It does not clarify the output type, does not differentiate from the numerous sibling risk tools, and does not provide any usage context beyond the bare statement. An agent would struggle to know exactly what data it receives or how to 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 zero description coverage, and the tool description does not explain the 'gnaf_id' parameter at all. The parameter name is somewhat self-explanatory (an identifier), but the description offers no guidance on format, source, or required values, leaving the agent to infer.

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 ('high-voltage power-line easement') and implies a proximity check ('near the parcel'), which is clear enough to distinguish from other risk tools like bushfire or flood. However, it lacks an explicit verb (e.g., 'returns', 'checks') and does not specify the nature of the result (boolean, distance, etc.), so it's slightly vague but still informative.

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 instead of the many sibling risk tools (e.g., properties_risks_all, properties_risks_bushfire, or the suburb-level suburbs_risks_hv_power_lines). The description only mentions the price and a general statement, providing no context for selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds the important behavioral nuance about the meaning of returned rows and the price per call, which are not covered by annotations. This exceeds the baseline for a read-only 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 two sentences plus a price note, with the core purpose and interpretation warning front-loaded. Every sentence adds value and there is no fluff. It is an excellent model of concise, high-signal writing.

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 tool with two parameters and no output schema, the description covers the essential meaning and interpretation. It omits details about the geojson parameter's output format, but that is documented in the schema. The absence of an explicit usage-vs-alternatives note is a minor gap, so a 4 is appropriate.

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% (geojson described, gnaf_id not). The description does not mention or elaborate on any input parameters, leaving gnaf_id unexplained. With half the parameters undocumented in the schema and no guidance in the description, the agent lacks semantic understanding of the required 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 provides landslide-risk overlays within a 1 km radius and explicitly distinguishes the meaning of a returned row ('found nearby') from an actual property risk. This is a specific verb-resource pairing and directly addresses the most common misinterpretation, making it stand out from sibling risk 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?

It provides crucial context on how to interpret results (a row means nearby, not at risk) and the 1 km scope. However, it does not explicitly advise when to choose this tool over alternatives like properties_risks_all or other risk-specific tools; that is left to the name and sibling 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?

Annotations already cover readOnly, idempotent, and non-destructive behavior, so the description doesn't need to restate those. It adds the price constraint ('2¢ per call') and the 'near the parcel' spatial context, both useful beyond the annotations. However, it does not disclose what the overlay contains (geometry, list, boolean) or behavior when no black spot exists.

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, one for purpose and one for price, with no redundant phrases. The core function is front-loaded and every word earns its place. This is a model of minimal, purposeful writing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and only a 12-word description, an agent lacks details about the response structure, the meaning of gnaf_id, and when to choose this over properties_risks_all. The price note is helpful, but the overall context is thin for a tool in a large family of risk overlays.

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 gnaf_id, and the description does not define gnaf_id. The only hint is 'near the parcel', which implies the identifier refers to a parcel but does not explain its format or provenance. This is insufficient compensation 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 'Mobile-coverage black-spot overlay near the parcel' clearly identifies the resource (mobile black-spot overlay) and its scope (near the parcel). It is readily distinguishable from sibling risk tools like properties_risks_flood or properties_risks_bushfire because it names a unique subject. However, it lacks an explicit verb such as 'retrieves' or 'returns', so it reads as a noun phrase rather than an action.

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 like properties_risks_all or other risk overlays. The description does not state whether this is a standalone risk check or part of a broader risk assessment, nor does it mention exclusions. An agent must infer usage from the tool 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?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds the cost ('4¢ per call') which is extra transparency beyond annotations. However, it does not describe the output format or any side effects, but given annotations cover safety, this is a minimal but valid addition.

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 brief and to the point, with no wasted words. It front-loads the core function and adds the cost note. It is appropriately sized for the simplicity of the tool, though it could have added a bit more context 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 one parameter, no output schema, and annotations that cover the safety profile, the description is still incomplete. It does not explain what 'overlay' means in terms of the response, nor does it clarify the gnaf_id parameter. An agent would need to infer or look elsewhere. The description is not sufficient for confident invocation without additional 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?

The schema lists one required parameter, gnaf_id, but has zero description coverage. The description does not explain gnaf_id or its expected format. The tool name implies it's a parcel identifier, but that inference is not explicit in the description. With 0% schema coverage, the description should compensate but 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 clearly identifies the tool's function: providing a public-housing concentration overlay for a specific parcel. The phrase 'near the parcel' indicates the scope and the resource is explicit. It distinguishes from siblings like properties_surroundings_public_housing by being risk-related, though not fully explicit. The verb is implied but context makes it 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?

There is no guidance on when to use this tool versus the many sibling tools (e.g., properties_risks_all, properties_risks_environment, properties_surroundings_public_housing). No conditions or alternatives are mentioned, leaving the agent to infer based on naming.

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

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

Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint). The description adds ordering (most-recent first) and the price per call, which are useful. However, it doesn't describe output format, pagination, or other behavioral traits. Given annotations handle safety, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two short sentences. The primary function is front-loaded, and the cost is clearly stated. 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 tool with one parameter and no output schema, the description is minimal. It fails to explain what gnaf_id is, what the response looks like, or how it differs from similar tools. The annotations cover safety, but the description lacks essential context for correct 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% for the single parameter gnaf_id. The description does not mention this parameter at all, adding no meaning beyond the bare schema. The agent must infer that gnaf_id is a property identifier, which is not stated.

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 all Sold and For Sale records, most-recent first, identifying the resource and scope. It doesn't explicitly differentiate from similar siblings like properties_history_all or properties_sale_history_latest, so it's not 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?

No guidance is provided on when to use this tool versus alternatives. Siblings such as properties_history_all, properties_sale_history_latest, and properties_rent_history exist, but the description offers no selection criteria 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the detail that the record could be 'Sold or For Sale,' which clarifies the data status, but it does not describe return format, pagination, or other behavioral traits. The price is a cost note, not behavioral. Minimal added value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences, with the purpose front-loaded and the price as an additional note. It is extremely concise and to the point, with no fluff or redundant phrasing.

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 a single parameter and no output schema, but the description does not explain the parameter, the return structure, or any caveats. It is minimal and assumes prior knowledge of gnaf_id. For a tool with zero schema coverage, this is inadequate for an agent to call it correctly without additional 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?

The schema has 0% description coverage and the description does not mention gnaf_id at all. Since the schema provides no meaning, the description should explain the parameter, but it doesn't. The agent is left without any semantic guidance 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 states 'Most-recent Sold or For Sale record,' which clearly indicates the tool returns the latest sale record for a property. It distinguishes from siblings like properties_sale_history (full history) and properties_rent_history_latest (rent) by the 'Sold or For Sale' and 'Most-recent' phrasing, though it doesn't explicitly mention 'property' or the input identifier.

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 guidance on when to use this tool versus alternatives. It does not mention that this is for quick access to the latest sale as opposed to full history, nor does it reference sibling tools or any context that would help an agent choose it over similar offerings.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description's job is to add context beyond that. It only discloses the 105¢ per-call price and says nothing about response contents, aggregation behavior, or failure modes.

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 and front-loaded, but this is under-specification rather than appropriate conciseness. A functional one-sentence tool description is missing, so the only sentence does not meaningfully help an agent understand 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?

With one parameter, no output schema, and no functional description, the definition is inadequate for correct invocation. It lacks purpose, parameter guidance, and any relation to the large sibling tool group, making it effectively unusable beyond knowing a cost.

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 schema description coverage is 0%. The description does not mention gnaf_id or its expected format, so it provides no compensation for the absent 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 contains only 'Price: 105¢ per call.' and states no function. The title 'Property · All schools — bundle' echoes the tool name and hints at aggregated school data, but there is no verb or explicit resource behavior, and no differentiation from 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 usage guidance is provided. The description does not say when to call this bundle versus the many sibling school tools, so an agent has no basis for selecting it over 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?

Annotations already provide readOnly, idempotent, and non-destructive hints. The description adds value beyond them with the ~5km approximation and the 5¢ per-call cost, but it does not disclose response behavior, edge cases, or any additional operational constraints.

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 exceptionally concise: two short sentences, with purpose and scope first and pricing separated into its own line. Every element earns its place 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?

For a simple one-parameter read-only endpoint, it covers the returned content and cost adequately. However, the unexplained gnaf_id parameter and lack of any input-format guidance leave a meaningful gap that the agent must infer.

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 sole parameter, gnaf_id, has 0% schema description coverage, and the description only obliquely refers to 'the property' without explicitly explaining what gnaf_id is or its expected format. The description does not compensate for the missing schema detail.

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 resource (schools near a property) with scope (~5km) and included data (rank, student counts). It is easily distinguishable from siblings like properties_schools_all and properties_schools_ranking, though it lacks an explicit verb.

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 choose this tool over related siblings such as properties_schools_all, properties_schools_ranking, or suburbs_schools_nearby. There are no exclusions, prerequisites, or alternative routing cues.

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 annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat safety information. However, it does add useful context about the data being ranked by NAPLAN/socioeconomic score, which is not inferred from the name alone. It does not disclose potential variability in the number of schools returned or any limits, which could be relevant for an agent.

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 two sentences, and the key purpose is front-loaded. The pricing note is a separate line, which is clear but could be considered extraneous for functional description, yet it is important for decision-making. The structure is efficient and avoids 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?

Given the tool's simplicity (one parameter, no output schema), the description is fairly complete, but it lacks details on the output format, such as whether it returns a list of school names, scores, or both. The ranking methodology is mentioned but not elaborated, which may be acceptable for a simple tool, but an agent might need more to fully utilize the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the parameter gnaf_id is not explained in the schema. The description also does not explicitly explain what gnaf_id is or how to obtain it, placing the burden on the agent to infer from naming conventions. Since there is only one parameter, the description should at least clarify its role, but it does not add meaning beyond the parameter 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 clearly states that it returns schools within ~5km of the property ranked by NAPLAN/socioeconomic score, which distinguishes it from broader school tools like properties_schools_all and properties_schools_nearby. It uses a specific verb 'ranked' and a clear resource, making the purpose easy to understand. However, it could be more explicit about how it differs from nearby schools or catchment 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 implies usage when a ranking of nearby schools by performance is needed, but it does not provide explicit guidance on when to use this tool versus alternatives like properties_schools_nearby or suburbs_schools_catchment. There is no mention of exclusions or specific scenarios, so the guidance is only implicit based on the description's focus on ranking.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the 404 behavior when no forecast row exists, and the pricing (20¢ per call). It also clarifies the semantic scope (street vs suburb comparison), which is beyond what annotations provide.

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 first sentence lists the key metrics, the second clarifies the 404 behavior, and the third states pricing. Every sentence earns its place 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?

For a single-parameter read-only tool with no output schema, the description covers the core semantics, the error behavior, and the cost. The only gap is that it doesn't describe the return format or structure, but with no output schema and a simple parameter, this is acceptable. The 404 disclosure is particularly valuable for an agent deciding whether to call this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden. The description implies the gnaf_id identifies the property whose street is profiled, but it doesn't explicitly explain what gnaf_id is or what format it should take. The description adds context about what the parameter is used for (the property's street), but the parameter itself is undocumented in 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 names a specific resource (the property's street), a clear verb (profile), and enumerates the exact metrics returned (median price, forecasts, growth, turnover, renter share, houses/units, suburb-wide medians, rank). It also distinguishes itself from suburb-wide tools by explicitly framing the comparison against the suburb.

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 what the tool does and implicitly when to use it (when you need street-level vs suburb-wide data). It names the alternative concept (suburb-wide figures) and explicitly says the tool does NOT fall back to suburb-wide data, which helps an agent avoid using it for a different question. However, it doesn't name a specific sibling tool as the alternative.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the per-property granularity and the price, but it does not disclose behavior for missing data, invalid gnaf_id values, or how the 'likely-owner-status' signal is expressed.

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: the first front-loads the core output, and the second gives the price. Both sentences earn their place, with no filler or repetition of annotation details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with no output schema, the description provides enough intent-level clarity to attempt a call, but it leaves out the response structure, interpretation of the owner-status signal, and the radius context beyond the title. Additional detail about the 200 m scope or expected output shape would make it 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?

The input schema provides only a required gnaf_id string with no description, and the description never mentions gnaf_id or explains how to obtain it. With 0% schema description coverage, the tool description should compensate for the parameter semantics, and 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 states the output content: latest sold/rent dates and likely-owner-status signal per nearby property. This is clear enough to infer the operation, though it lacks an explicit verb like 'returns' or 'lists' and does not differentiate itself from overlapping sibling tools such as properties_neighbours or properties_surroundings_properties.

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 alternatives. There are many nearby property-related sibling tools, but the description only explains what the tool returns and its price, never when it should be preferred or avoided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by specifying the output format (GeoJSON) and the cost (25¢ per call), which are not in the annotations. However, it does not disclose behavior such as error handling, empty results, or the exact meaning of 'around the subject' beyond the title's 200 m radius.

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, with two short sentences. The primary purpose is front-loaded ('Cadastral parcel polygons...'), and the cost is secondary. There is no filler or redundancy, 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 tool with one parameter and no output schema, the description is incomplete. It fails to explain the gnaf_id parameter, which is critical given zero schema coverage. It also omits the 200 m radius (though present in the title) and any information about error responses or empty results. The tool is simple, but the missing parameter documentation leaves an agent uncertain about how to construct a valid call.

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 for the single required parameter gnaf_id. It does not explain what gnaf_id is (e.g., a G-NAF identifier) or how it should be formatted. The only hint is the phrase 'for properties around the subject,' which implies gnaf_id identifies the subject property, but this is not explicit. The description adds minimal meaning 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 'Cadastral parcel polygons (GeoJSON) for properties around the subject.' This is a specific resource (cadastral parcels) and output format (GeoJSON), distinguishing it from siblings like properties_surroundings_properties or properties_surroundings_tenure. The title adds the 200 m radius, further clarifying scope.

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 does not mention any exclusions, alternatives, or conditions (e.g., 'use this when you need parcel boundaries' or 'for property details use properties_surroundings_properties'). Usage must be inferred from the name and description, but no direct comparison 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?

The annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is safe. The description adds the cost per call (15¢), which is useful, and the fixed 200-meter radius. However, it doesn't disclose any potential pagination limits, whether results are sorted, or if the call can fail without a valid GNAF ID. With annotations covering safety, the description's addition is moderate 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 extremely concise, consisting of one sentence for the core function and one for pricing. It is front-loaded with the essential information and has no filler words. Every word earns its place, 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 single-parameter read-only tool, the description suffices to understand the purpose but lacks details on input format (e.g., GNAF ID specification) and output structure (since no output schema exists). An agent might need to infer these from naming conventions or rely on trial, but the tool's simplicity mitigates the risk. It is complete enough for basic usage but not fully self-contained.

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 0%, so the description must compensate for the single parameter 'gnaf_id'. It does not explain what format the GNAF ID should take or where to obtain it, which is a gap. However, the parameter name is self-explanatory for a domain-aware agent, and the description's context of 'subject' property implies it is the identifier of the target property. This is marginal improvement over the schema, earning a baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns GNAF properties within 200 meters of a given property, including lat/lng and mesh block data. It uses a specific verb ('surrounding properties') and resource, and is distinguished from sibling tools like 'properties_neighbours' by the explicit distance filter and data attributes, though it doesn't name a specific alternative.

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 conveys its primary use case (spatial proximity analysis) and implies when to use it (when nearby GNAF properties are needed), but it does not explicitly state when not to use it or suggest alternatives such as 'properties_neighbours' or 'properties_surroundings_parcels'. The context is clear enough for an agent to infer, but lacks explicit routing 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds contextual scope ('around the subject' and 'public-housing classifier') and the price, but does not explain what a 'flag' means, how results are structured, or any quirks of the classifier. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise and front-loaded: the first sentence states the core function, and the second adds the price. Every word earns its place, with no filler or repetition of annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, read-only lookup with strong annotations, the core is present: what it returns (surrounding public-housing flags) and the subject identifier. However, the output is not described and no output schema exists, so an agent is left uncertain about the response shape or what 'flagged' means in practice.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain gnaf_id or its expected format. The phrase 'around the subject' vaguely implies gnaf_id identifies the property, but the agent must infer this. There is no compensation for the absent 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 states a clear resource and action: properties around the subject flagged by the public-housing classifier. The title adds the 200 m radius, which further clarifies scope. However, it does not explicitly distinguish the tool from siblings like properties_risks_public_housing or suburbs_shapes_public_housing_sa1.

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 usage guidance is provided. The description does not say when to prefer this tool over related siblings, nor does it mention exclusions or prerequisites. The only non-descriptive addition is pricing, which does not help with tool selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side effects. The description adds the data source (ABS Census 2021) and granularity (each mesh block), which is useful, but it does not disclose return shape, tenure categories, or any quirks. This is adequate given the strong 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 extremely concise: one sentence states the data product and granularity, and a second sentence gives the price. Information is front-loaded and no words are wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only tool, the description provides the essential context: what data, what geography, and price. However, there is no output schema, and the description does not enumerate the tenure categories or the exact output format, leaving some ambiguity for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single required parameter, gnaf_id, with 0% schema description coverage. The description never explains that gnaf_id identifies the subject property or how it should be formatted. The parameter name is somewhat self-explanatory, but the description adds no semantic value 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 identifies the resource: ABS Census 2021 tenure shares for each mesh block around the subject, with the 200 m scope in the title. It distinguishes from suburb-level tenure tools by specifying mesh-block granularity, though it lacks an explicit verb and does not name a sibling.

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_mesh_blocks or suburbs_demographics_tenure. There are no prerequisites, exclusions, or context about which property identifier is expected. Only the price is mentioned.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds the cost (5¢ per call) and a practical radius-widening tip, which is useful context. It does not describe output format or pagination, but the annotation coverage lowers the bar.

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 with a distinct purpose: stating the core function, providing a parameter tip, and giving pricing. The description is front-loaded with the main purpose and contains zero fluff. Excellent economy of 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 simple two-parameter read-only tool with rich annotations, the description covers the essential behavior and cost. It is missing explicit usage guidance vs siblings like properties_amenities_nearby, and it does not mention distance units or output shape. Overall adequate but 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 already documents radius_m fully (range and default), and the description adds a useful tip for when to widen it. However, the required gnaf_id has no schema description and the tool description does not clarify what it is or how to obtain it, leaving a significant gap for an agent trying to invoke the tool correctly.

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 ('nearest') and resource ('train / tram / bus / ferry stop') and clarifies output ('per mode, with distance'). It distinguishes from siblings like properties_amenities_nearby or properties_schools_nearby by the transport resource. However, it doesn't explicitly name any sibling alternative, which is a minor gap.

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 choose this tool over its many siblings. The only usage hint is about widening radius_m for distances beyond 1km, which is a parameter tip rather than tool-selection advice. There is no mention of when not to use it or what alternatives exist.

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

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

Annotations already declare readOnly, idempotent, and non-destructive. The description adds the cost (50¢ per call) and the condition that the property must be listed with a tracked agency, which implies potential failure or empty response otherwise. This is additional behavioral context not covered by annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences plus a price line, front-loading the purpose and listing the output metrics. No wasted words. Efficiently 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 a simple read-only tool with one parameter and no output schema, the description gives a good overview of what it returns and when it works, but it lacks explanation of the gnaf_id parameter. It also doesn't mention any error cases or response format details. Given the tool's simplicity, it is reasonably complete but could be better.

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 only gnaf_id with no description, and the description does not explain what gnaf_id is or its format. With 0% schema coverage, the description should compensate but doesn't. It only mentions the condition, not the parameter 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 reports the quoting accuracy of the property's current listing agency, listing specific metrics (cohort, median guide-vs-sold deviation, underquote rate, and 5 most-recent sales). It also includes a condition (only while listed), which distinguishes it from other valuation tools that focus on AVM, land values, etc.

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 a clear precondition: only while the property is listed for sale with a tracked agency. However, it does not explicitly compare with alternatives like properties_valuation_avm or properties_valuation_all, so it leaves it to the agent to infer when this is the right tool. It gives context but 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?

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent already knows this is a safe read operation. The description adds only the pricing detail (10¢ per call), which is useful but minimal. It does not disclose the response size, potential for large payloads, or that all valuation outputs are included.

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 (one phrase), but it is not misleading; it is minimal yet honest. However, it fails to provide essential functional information, so the conciseness is a tradeoff for completeness.

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 returns a comprehensive bundle of valuation outputs, the description is incomplete. An agent needs to know what data is included, the parameter format, and any constraints. With no output schema, the description should explain the return value, but it only states the price.

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 only one parameter, gnaf_id, with no description and 0% schema coverage. The tool description does not explain what gnaf_id is (likely a G-NAF identifier for a property) or how to obtain it. Since schema coverage is 0%, the description needed to clarify the parameter, 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 title and tool name indicate a bundle of valuation outputs, but the description only states the price, not what the tool actually does. It does not mention that it returns all valuation data for a property. An agent can infer it aggregates valuation outputs, but it is not 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 on when to use this tool vs. the individual valuation tools (e.g., properties_valuation_avm) or other sibling tools. The description does not mention that it is a cost-effective bundle for comprehensive valuation data, and no exclusions or alternatives are 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds valuable context: the cost (10¢ per call) and the nature of the output (point estimate, range, confidence score). This goes beyond the annotations without contradicting them.

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: one sentence plus a bolded price note. It front-loads the core purpose and includes the price as a separate line, making it easy to scan. Every element adds value with 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?

The description provides the key output elements (point estimate, range, confidence score) but omits details like units (presumably currency), how to interpret the range or confidence, and any error handling or edge cases. Since there is no output schema, more explicit return structure would be helpful.

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 no description for the single parameter gnaf_id (0% coverage). The description only says 'for a single GNAF' but does not explain what a GNAF is, its format, or how to obtain it. This is insufficient for an agent to correctly construct the parameter without prior knowledge.

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 an automated valuation (AVM) for a single property identified by a GNAF ID, returning a point estimate, an 80% range, and a confidence score. It distinguishes itself from other valuation tools (e.g., agent_quoting, land_values) by being the ML-based AVM, though it doesn't explicitly contrast with them.

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 valuation tools (e.g., properties_valuation_agent_quoting, properties_valuation_value_series). The agent must infer from the name and description alone, with no explicit conditions or alternatives mentioned.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the agent knows this is a safe, read-only, deterministic call. The description adds value by listing the exact data fields (YoY change, $/sqm, lot area, zoning) and the series years, which is useful. However, it does not disclose any potential limitations, such as data availability for all years or whether the query returns empty results for certain parcels, but the annotations cover the safety profile adequately.

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 concise, with two sentences. The first sentence lists the key data fields and the series name, which is immediately informative. The second sentence adds the pricing cue, which is relevant for cost-sensitive agents. No redundancy or filler. It is front-loaded with the essential data 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?

This is a simple, single-parameter read-only tool. The description, combined with annotationsainer, is adequate for an agent to understand what the tool returns and that it is safe to call. The main gap is the lack of guidance on how to interpret gnaf_id (e.g., where to get it) and whether the series always has all five years. Given the tool's simplicity and the output schema absence, a 3 is reasonable, but it could be improved with a note on data completeness or a hint to use geocoding tools to obtain gnaf_id.

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 only one parameter (gnaf_id) with no description (coverage 0%). The description does not explicitly define what gnaf_id is or how to obtain it, but the parameter name is self-explanatory as a geographic identifier. Given that there is only one parameter and it is required, the description could have clarified that it is a unique parcel identifier, but the context of the tool makes it inferable. Thus, the description partially compensates but not fully.

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 council land valuations for a specific parcel, with a 5-year series (val_2021..val_2025) including YoY change, $/sqm, lot area, and zoning. It identifies the resource (council land values) and the specific data fields. However, it does not explicitly distinguish itself from similar valuation tools like properties_valuation_value_series or properties_valuation_all, though the focus on land values is specific 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 does not provide any guidance on when to use this tool versus alternatives. It does not mention when to prefer this over properties_valuation_all or properties_valuation_value_series, nor does it state any prerequisites (e.g., needing a gnaf_id from geocoding). The only context is the price, which is not a usage guideline.

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 adds valuable behavioral context beyond the annotations: the fallback hierarchy from per-property to mesh-block to suburb investor-exposure, the specific LVR scenarios, and the per-call price. Since annotations already declare read-only, idempotent, non-destructive behavior, the description enriches rather than repeats them.

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 tight sentences: the first front-loads the core purpose and granularity, the second adds the crucial fallback behavior and price. No filler or redundant wording is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read-only tool without an output schema, the description provides the main operational context: property-level cashflow scenarios, fallback behavior, and cost. It does not enumerate exact output fields, but the stated data semantics are enough for an agent to invoke the tool appropriately.

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 has no descriptions, and the description only indirectly explains the single gnaf_id parameter as identifying a property via 'per-property'. This is a minimal but real semantic contribution. It does not specify the identifier format or how to obtain a valid GNAF ID, which would have compensated more fully for the 0% 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 description clearly identifies the tool as a negative-gearing stat, scoped to a single property with per-property cashflow scenarios at 80% and 105% LVR. It distinguishes itself from the many valuation and property siblings by its specific subject matter and granularity fallback. Although it lacks an imperative verb, the title and description combine to 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 implies use when the caller needs negative-gearing data at the finest available granularity, but it does not explicitly state when to choose this over alternatives like properties_valuation_all or other valuation tools. It provides useful granularity context but no exclusions or alternative 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful behavioral context: the data frequency (monthly for the last year, annual before that) and the house-only restriction. It doesn't disclose return format or pagination, but for a read-only series endpoint with annotations covering safety, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with zero waste. The core purpose and temporal granularity are front-loaded, the house-only restriction is stated, and the pricing note is a single compact line. 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 single-parameter read-only tool with annotations covering safety, the description is mostly complete. It tells the agent what the tool returns (modelled value over time), the frequency, and the house-only restriction. However, it doesn't mention what the response looks like (no output schema exists) or how to handle the 'no series' case for units, which could leave an agent uncertain about error handling.

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 carries the burden for the single parameter, gnaf_id. The description does not explain what gnaf_id is or how to obtain it, but the parameter name itself is fairly self-explanatory (a G-NAF identifier). With only one parameter and a clear name, the baseline is 3; the description adds no additional semantic detail 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 states a specific resource ('modelled property value over time') with a clear verb ('modelled'), and adds temporal granularity (monthly for the last year, annual before that). It distinguishes itself from sibling valuation tools by noting 'Houses only — units have no series', which helps differentiate it from properties_valuation_avm and properties_valuation_all. However, it doesn't explicitly name a sibling alternative, so it falls just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context on when the tool applies: it is for houses only, and units are excluded. This is an explicit exclusion that helps an agent avoid calling it for units. It doesn't name alternative tools for units or other valuation series, but the exclusion is strong enough to guide basic 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds valuable behavioral details: the return format '{sa4, state}' per row, the flat cost (3¢ per call), and the optional state filter. These go beyond annotations without contradiction.

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 sentences plus a cost line, with no fluff. It front-loads the core purpose, then the filter, return format, and cost. Every sentence earns its place, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.