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

With no annotations, the description must carry behavioral context. It discloses that dimensions are returned in key order and that code_search filters by label substring, but it omits permissions, rate limits, pagination, and the full output 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 sentences, front-loaded with the core action and followed by usage guidance. No filler or repetition.

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

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

For a simple two-parameter read tool with no output schema, the description is complete. It explains what is listed, the key-order format, and how to narrow large result sets with code_search.

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 both parameters. The description adds value by giving a concrete example of when to use code_search ('rent' in CPI's INDEX), which is beyond the schema text.

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

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

States a specific verb and resource: list an ABS dataflow's dimensions in key order and their codes. It also explains the downstream purpose (building an SDMX key for abs_get_data), which distinguishes it from the sibling that retrieves data.

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

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

Clearly says to use this tool before abs_get_data when constructing an SDMX key, and advises using the code_search parameter for large codelists. It does not explicitly cover when not to use it or how it relates to abs_search_dataflows.

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

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

With no annotations, the description carries the full burden and does add one real behavioral trait: an empty/wide key can return thousands of series, a large-response warning. It says nothing about auth, rate limits, pagination, or the return shape, so for an unannotated data tool it remains only partially 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?

Three short sentences, front-loaded with the core fetch action, then the key-narrowing warning, then the last_n tip. Nearly every sentence earns its place; only the dataflow-parameter provenance could be tightened.

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?

Covers the essential key-usage and last_n semantics for a 5-param fetch tool, but with no annotations and no output schema, it omits the return format and result shape that an agent would need to consume the response, leaving a gap.

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 80%, so the schema already documents key, start, end, and last_n. The description reinforces the key-narrowness constraint and the last_n shortcut but adds no format/syntax detail beyond what the schema provides, matching the baseline-3 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?

States a specific verb (Fetch) and resource (any ABS dataflow) and ties the SDMX key to the sibling tool abs_describe_dataflow, which helps distinguish it from abs_search_dataflows and the specialized get_cpi/get_labour_force tools. Clear, though it doesn't explicitly say why to prefer it over the specialized 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?

Gives practical guidance ('Keep keys narrow', 'Use last_n to just get the latest values') and warns that an empty key on a big dataflow returns thousands of series. However, it never states when to use this generic tool versus the purpose-built siblings (get_cpi, get_cash_rate, etc.), leaving that routing 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose that it returns dataflow ids, which is behaviorally important for chaining. However, it doesn't mention result limits, pagination, authentication, or ranking behavior for a search tool with 1,000+ records.

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, front-loaded with the core action and scope, followed by when-to-use and return value. Zero waste and highly scannable.

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

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

For a single-parameter discovery tool, the description covers purpose, usage context, examples, and return value sufficiently. It lacks output structure details (e.g., what a dataflow id looks like) but is otherwise complete enough for an agent to invoke 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%, so the parameter is already documented with examples ('wage price index', 'building approvals'). The description adds catalogue context (1,000+ datasets) but doesn't add syntax or format details beyond the schema. Baseline for full coverage plus minor value is a low 4.

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 (Search) and resource (ABS Data API catalogue, 1,000+ datasets) with the keyword mechanism. It clearly distinguishes itself from direct data-fetching siblings like get_cpi, get_labour_force, and abs_get_data by being a discovery 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?

It explicitly names when to use it ('when CPI and Labour Force don't cover the question') and provides concrete example topics (wages, building approvals, population, retail trade, GDP). It also routes the agent forward: 'Returns dataflow ids for abs_describe_dataflow.'

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

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

With no annotations, the description carries the full burden; it does disclose the semantic nature of the value (target rate, monthly averaging, annualised percent) and the schema covers the default range behaviour. It says nothing about data freshness, how far back history goes, revision policy, or that the call is a side-effect-free read, so real behavioural gaps remain.

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, no waste, and the identifying information (what the series is, its frequency and unit) is front-loaded before the usage hints. Every clause 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 two-optional-param read tool with no output schema, the description supplies the essential semantics: unit, frequency and intended analyses. Only the shape/ordering of returned observations and the data's historical coverage are left unspecified, which is a minor gap.

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%: start and end are documented with format, pattern and omission semantics. The description adds no parameter-level detail beyond that, so the baseline 3 for schema-does-the-work applies.

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

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

States a specific resource (RBA cash rate target), its transformation (monthly average) and its unit (% per year), which is exactly the level of precision needed to separate it from siblings like get_lending_rates or get_exchange_rates. An agent can tell what it retrieves 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?

Gives concrete trigger phrasings ('what's the cash rate', rate hikes/cuts over time) and a comparative use case (lining rates up against CPI, rents or jobs), which implicitly points at sibling datasets. It stops short of stating when not to use it or naming an alternative tool explicitly, so it lands just under 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully defines the semantics and units of each measure ('1.0 = no gap', shares of Tue-Thu, tap-ons per day), but says nothing about return format, pagination, data freshness, or rate limits.

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

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

A single dense paragraph where every clause carries information about a distinct measure; the core measure (friday_gap) is front-loaded before the secondary views. 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?

With no output schema, the description should characterize the returned data. It explains units and the 1.0 baseline for the gap measures but never describes the response shape, series structure, or how the six views differ in their output format.

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 75% and the 'view' enum has no per-value descriptions in the schema, so the description's detailed gloss on each of the six view values (friday_gap, monday_gap, evening_volume, baseline, cbd_hourly, suburban_morning) adds real meaning. It also confirms the Sydney CBD default that the schema only implies.

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 source: TfNSW Opal tap data measuring how Sydney commutes since COVID. It clearly separates itself from the RBA/ABS siblings in a different domain, though it never states the verb explicitly or that it returns a time series.

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

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

No explicit when-to-use or when-not-to-use guidance, and no named alternatives. Usage is only implied through the explanation of each view, which does help an agent pick the relevant measure (e.g. friday_gap for return-to-office) but leaves the choice unstated.

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

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

No annotations are supplied, so the description carries the full disclosure burden. It usefully conveys the unit semantics of each measure (% change vs index level) and the trimmed_mean preference, which is real behavioral value, but it says nothing about response shape, series granularity, or whether results are paginated/truncated.

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?

Four dense sentences, front-loaded with the data source and immediately followed by the measure decision, then item selection, then the code-lookup fallback. No sentence is filler; each one corresponds to an actual decision the caller must make.

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 six-parameter read tool with no annotations and no output schema, the description covers the two hardest choices (measure and item) and points to the sibling needed for custom codes. Remaining gaps (city semantics, date-range behavior, return structure) are adequately handled by the schema itself, though the lack of any output-shape hint keeps it short of full completeness.

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

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

Schema coverage is high (83%), so the baseline is 3, but the description adds meaning the schema lacks: it explains the otherwise-undocumented 'measure' enum in concrete terms and gives a worked item selection ('rents' for rent inflation) plus the escape hatch of raw ABS codes. The adjustment and city parameters are left to the schema, which already documents them.

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

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

Names a specific resource (ABS monthly Consumer Price Index inflation) with its two axes of granularity (item and capital city), so an agent immediately knows this is the Australian CPI endpoint rather than any of the rate/labour-force siblings. The data source is explicit, leaving no ambiguity about what is returned.

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 routes the agent between the three measure values ('annual_change' for year-on-year inflation, 'monthly_change' for month-on-month, 'index' for price levels) and flags the RBA-preferred underlying measure (trimmed_mean). It also names the sibling tool abs_describe_dataflow for retrieving raw ABS index codes, which is exactly the kind of alternative-routing guidance that prevents misuse.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the unit convention, the RBA source, the coverage start (2023 for daily data), and the default aggregation rule, but is silent on auth requirements, return shape, missing-data behavior, and any rate limits.

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

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

Two dense sentences with zero filler, front-loading the resource and unit convention before the cadence detail. Every clause carries information an agent needs.

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

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

For a four-parameter, annotation-free read tool with no output schema, the description covers source, units, coverage window, and default aggregation. The main remaining gap is output structure and default currency selection, but the schema carries most parameter detail.

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 75%, so the schema already documents start/end formats and the monthly toggle. The description reinforces the default cadence and adds the 'last value of each month' aggregation rule, which the schema does not state, but adds nothing for the currencies array or the start/end bounds.

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 verb and resource (Australian dollar exchange rates) and adds the decisive interpretation detail — units of foreign currency per A$1 — plus the TWI inclusion. That scope is unmistakably distinct from the rate siblings (get_cash_rate, get_lending_rates) and the macro siblings (get_cpi, get_labour_force).

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

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

Usage is only implied: the description establishes this is the FX-rate tool and notes the default aggregation, but never states when to choose it over rba_series or a generic series fetcher, nor any when-not condition. An agent can infer the fit from the resource, but nothing is 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?

With no annotations, the description carries the full burden. It usefully discloses units (rates in %, counts in thousands) and the default adjustment basis, which matters for interpreting output. It does not describe the response shape, row/column layout, or any limits, so the behavioral picture is incomplete for a 6-parameter data 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?

Three compact sentences, front-loaded with the dataset and scope, then units, then default basis. Almost every clause earns its place; 'and more' is the only vaguely padded phrase.

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 6-parameter tool with no output schema and no annotations, the description covers source, frequency, geography, units, and default adjustment, but omits any sense of the returned data structure and leaves sex and period parameters to the schema. Adequate but with visible gaps.

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

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

Schema description coverage is only 33%, so the description must compensate. It adds meaning for measures (rates vs counts), states ('Australia or any state/territory'), and adjustment (seasonally adjusted default and why). It says nothing about the sex parameter or the start/end period semantics, leaving part of the gap unfilled.

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 (get) plus a named dataset and its scope: ABS Labour Force survey, monthly, covering unemployment rate, participation, employment, for Australia or any state/territory. An agent can tell this apart from get_cpi or get_cash_rate by the dataset named, though no sibling is explicitly referenced.

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

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

Usage is implied by the dataset name rather than stated: nothing says when to prefer this over abs_get_data or rba_series, and there are no exclusions. The note that seasonally adjusted figures are 'what news reports quote' gives a mild steer toward the default, but no explicit when-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden. It does usefully disclose data semantics: rates are advertised, expressed as % per year, and reported monthly. It says nothing about the return shape, ordering, default selection of rates, or freshness beyond what the schema implies, so gaps remain.

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

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

A single dense sentence, front-loaded with the data source and frequency, then the category breakdown. No filler and nothing redundant with structured fields.

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 3-parameter, zero-required retrieval tool with no output schema, the description adequately conveys what data comes back, but it omits the default `rates` selection (owner_occupier_variable_discounted), the meaning of omitting start/end, and any note about the latest-release boundary. No output schema means return expectations rest entirely on this text.

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 67% and the `start`/`end` parameters are already documented in-schema, so the schema does most of the work. The description's enumeration of loan categories maps conceptually onto the `rates` enum values, adding a little meaning, but it never mentions date-range semantics or the default rate.

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 exactly what is returned: RBA indicator lending rates, advertised, % per year, monthly, broken down by loan category. An agent can distinguish this from siblings like get_cash_rate or get_exchange_rates by the resource named. It stops short of an explicit verb or an explicit sibling contrast, so it is clear but not maximally differentiated.

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

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

There is no when-to-use guidance, no mention of alternative tools (e.g. get_cash_rate for the policy rate vs. this for advertised lending rates), and no prerequisites. Usage is only implied by the data being described.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses a non-obvious mode: a `table`-only call returns a series listing rather than data, and subsequent calls retrieve values. It does not state that the operation is read-only, mention pagination, auth, or rate limits, which is a modest gap for a zero-annotation 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?

Two tightly written sentences with the fallback role front-loaded followed by the calling protocol. Every clause earns its place; no redundancy with the title or restated parameters.

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?

Six parameters, all documented in-schema, one required, no output schema. The description covers the workflow completely enough to invoke correctly, but with no output schema it stops short of hinting at the returned data shape (e.g. time-series values), leaving that to inference.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by clarifying the relationship between `table`, `series`, and `search` - that table alone lists series and series/search are the two alternative narrowing paths - which the schema documents only as isolated fields.

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 purpose - a fallback RBA series retriever - and names concrete tables it covers (f6, f2, g1, d1). It explicitly positions itself against the focused sibling tools (get_lending_rates, get_cash_rate, etc.) by framing itself as the catch-all for what they miss, so an agent can route without opening schemas.

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

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

Gives explicit when-to-use ('data the focused tools don't cover') plus a concrete two-step invocation protocol: call with just `table` to list series, then call again with `series` ids or a `search` phrase. The alternative inputs are named with their selecting condition.

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