DwellDelta - Australian rent check and property indicators

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

Beyond the readOnly/idempotent annotations, the description discloses the critical cross-state caveat that the states are not one series and cannot be summed or compared, that figures are new-bond medians rather than advertised rents, that many figures rest on few bonds, and that answers carry their own quarter and source limits. That is exactly the kind of non-obvious caveat an agent needs before quoting numbers.

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

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

The core purpose is front-loaded, but the body is a dense run-on of clauses with internal redundancy (the 'new-bond medians, not advertised rents' point is effectively made twice) and no structural break between purpose, state differences, and parameter rules. Most sentences do work, but the packing makes it harder to scan than its content warrants.

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 high-complexity tool spanning three publishers with divergent geographies and classifications, the description covers sourcing, comparability limits, fallback behavior, and refusal semantics; with an output schema present it does not need to explain return shape. The one real gap is what happens when area and council are both provided.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it explains the default when neither area nor council is supplied (state-level figure), and that unspecified dwelling_type/bedrooms yields every publisher-reported breakdown rather than an aggregate. It stops short of stating precedence if area and council are both passed, which keeps it out of the top band.

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 opening sentence names the exact measure (median weekly rent of new bonds lodged in the latest quarter, all dwellings), the accompanying figures (bond count, year-on-year change), and the per-call scope (one state per call), plus the publisher behind each state. It also explicitly routes Victoria elsewhere ('Victoria is in vic_rents'), so an agent can separate this from a sibling without opening the schema.

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

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

Strong on when-to-use conditions and exclusions within its own domain: one state per call, NSW uses postcode/council while WA uses locality, and 'with neither, the answer is the state's own figure'. It also states refusal behavior for unpublished dwelling/bedroom combinations. It does not, however, position itself against rent_check or market_indicators, so sibling selection outside vic_rents is left to inference.

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

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

Annotations already declare the tool is read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds useful behavioral context by disclosing the inclusion of licences and explicit coverage limitations, without contradicting 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 a single, front-loaded sentence with no wasted words. The parenthetical list of limitations is dense but every item directly serves scope clarification.

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 an output schema available, the description need not explain return values. For a zero-parameter informational tool, it adequately covers sources, licences, and limitations, giving the agent enough to know what this tool does and does not provide.

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

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

The tool takes zero parameters, so parameter semantics are not applicable and the baseline is 4. No parameter documentation is needed.

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

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

The description clearly identifies the resource: data sources, licences, and coverage limitations behind DwellDelta's figures. It distinguishes itself from data-returning siblings by focusing on provenance and scope, though it uses a noun phrase rather than 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?

The 'what it cannot answer' list gives strong negative guidance, effectively telling the agent when not to expect answers from this tool. However, it does not explicitly name sibling alternatives or state a positive 'use this when' condition.

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 read-only, idempotent, non-destructive behavior, so the description does not need to repeat safety details. It adds substantive context beyond annotations: all figures are observed rather than forecast, and each carries period, source, licence, and limits.

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

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

The description front-loads the resource and indicator list, then adds the forecast caveat and geography behavior. The long enumeration is justified by the tool's broad scope, though it is somewhat dense.

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

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

An output schema exists and annotations cover the safety profile, so the description need not explain return values. It supplies the indicator scope, the no-forecast caveat, and the optional geography behavior; the main remaining gap is explicit sibling routing.

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 would be 3. The description adds useful semantics by saying geography narrows the answer to figures for one place and giving examples such as NSW, Australia, and Sydney.

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

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

The description names the resource and enumerates the indicator families covered, making the tool's scope concrete. It does not explicitly distinguish itself from rent-focused siblings such as area_rents, rent_check, or vic_rents, 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?

It states that figures are observed only and not forecasts, and explains that geography narrows results to one place. However, it gives no explicit when-to-use guidance versus sibling tools or exclusions, so usage is implied rather than routed.

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

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

Beyond the annotations, the description discloses important data-quality behavior: UNUSUAL marks indicate lines set by a few very large sales or many identical prices and are not a going price, totals may be moved by marked rows, and other marks also mean the line is not a going price. It also states that each answer names the dwelling type, quarter, source line, and limits, giving rich behavioral context for interpreting results.

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

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

The core purpose is front-loaded in the first sentence, and the subsequent details about source, caveats, and output content are relevant. The description is dense and somewhat lengthy, but each sentence carries useful information for correct interpretation of this data tool. Minor trimming could improve readability without losing meaning.

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 schema richness, annotations, and output schema, the description is complete: it covers the data source, geographic scope, parameter defaults, output content, and important caveats about data marks and limitations. An agent has enough information to invoke the tool correctly and interpret its results responsibly.

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

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

Schema coverage is 100%, so the schema already documents all three parameters. The description adds useful default behavior not fully captured in the schema: with neither area nor council, the answer is the state's own figures, and it explains the dwelling-type categories in plain terms. This goes beyond the schema baseline but does not exhaustively define every parameter edge case.

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 and scope: median sale prices of dwellings sold in the latest reported quarter in NSW, with quartiles, sales counts, and year-on-year change, broken down by postcode or council and dwelling type. It distinguishes itself from rent-focused siblings by specifying sale prices and explicitly excluding asking prices, valuations, and individual-sale figures.

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

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

It gives clear context for use: area or council names the place the question is about, and with neither the answer is the state's own figures. It also clarifies what the data is not (asking prices, valuations, individual home values), which implicitly routes agents away from valuation or rent tools. However, it does not name sibling tools or explicitly state when to use those 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?

The annotations already cover read-only, idempotent, non-destructive, closed-world behavior, and the description adds real substance: the index is city-wide, not suburb-level, so it is a coarse comparison; the response carries the months compared, the source, and the index's stated limits. It also explicitly frames the output as information rather than advice, which sets a useful boundary. It does not discuss error or edge behavior, such as a lease_start after the latest index release, but the output schema covers the return shape.

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

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

Two dense sentences are front-loaded with the comparison being made, then the granularity caveat, then what the response carries. Every clause earns its place; the final sentence is slightly packed but nothing is padding.

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 an output schema handling return values and annotations covering safety, the description supplies the remaining essentials: data source, comparison window, granularity limits, and the non-advice framing. It leaves out only edge behavior, such as what happens when lease_start postdates the index series.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters and the baseline is 3. The description adds meaning beyond that by constraining city to the eight capitals as a city-wide series rather than a suburb-level one, and the phrasing 'any proposed new rent' signals that proposed_rent is optional.

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 precise verb and resources: it compares a weekly rent and a proposed new rent with ABS rents index movement since lease start. The qualification that the index is city-wide, not suburb-level, separates it from the granular area_rents and vic_rents 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 context implies using the tool when someone wants to sanity-check a rent change against the index, and it implies a city-wide rather than a suburb-level question. However, the description never states when not to use the tool, nor does it name area_rents, vic_rents, or any other alternative for those cases, so an agent must infer the 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 that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds meaningful behavioral context beyond that: data provenance, licensing, the distinction between new-lease medians and advertised rents, and the fact that answers include quarter, source line, and source limits.

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

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

The description is appropriately sized and front-loads the source and metric before filtering behavior and caveats. It is a single dense paragraph, but every sentence contributes relevant information for selecting and interpreting 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?

Given the presence of an output schema, two well-documented optional parameters, and clear annotations, the description is complete enough for an agent to understand what the tool returns, how to filter it, and what caveats apply to the data.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying that suburb_group accepts part of a name, giving an example like "Brighton", and explaining that suburb_group or region narrows the answer to the relevant place.

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 resource and metric: Victorian rents from Homes Victoria's Rental Report, median weekly rent of new leases, lease counts, and year-on-year change for suburb groups and regions. It is more specific than the title alone, but it does not explicitly distinguish itself from sibling tools such as area_rents or rent_check.

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 explains how to narrow results with suburb_group or region, including that a partial suburb name works, which is useful usage context. However, it gives no explicit guidance on when to use this tool versus the sibling area_rents or rent_check, leaving the agent to infer the choice.

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