A wide range of validated governmental statistics and datasets.
Argentina IPC general level (INDEC, base Dec 2016=100) monthly, with month-over-month inflation %. Source: API Series de Tiempo (INDEC).
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | National (default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose important context: the specific index (IPC), base period (Dec 2016=100), monthly frequency, the month-over-month inflation calculation, and the public source (API Series de Tiempo/INDEC). However, it does not mention the response format, whether historical time series are returned, or any limitations around the optional region parameter.
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, information-dense sentence. It front-loads the primary subject ('Argentina IPC general level'), then packs the base, frequency, metric, and source in an efficient order. Every phrase contributes substantive information, with no repetition 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?
The tool has only one optional parameter, no output schema, and no annotations. The description names the two key data outputs (level and month-over-month inflation) and the source, which is a reasonable minimum. However, because there is no output schema, a complete description should also clarify the return shape (e.g., time series fields, pivot dates, units) and any behavior around the 'region' parameter; these are absent.
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, 'region', is already fully described in the schema as 'National (default)', giving 100% schema description coverage. The tool description adds no additional parameter-level meaning and does not mention the region parameter at all, so it provides no 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 states the resource ('Argentina IPC general level'), the underlying data source (INDEC, base Dec 2016=100), the frequency (monthly), and the derived metric (month-over-month inflation %). Though not a verb phrase, it unambiguously identifies what the tool provides and is distinct from the sibling CPI tools for Australia and the UK as well as from non-CPI Argentina 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 the tool is for Argentina-specific CPI data, and the name and content make that easy to infer. However, it does not explicitly state when to choose this tool over the sibling au-cpi or uk-cpi, nor does it mention any exclusion conditions. The usage context is clear but left to inference rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Argentina province total populations from the INDEC 2022 Census (final results). No province → national total.
| Name | Required | Description | Default |
|---|---|---|---|
| province | No | Province name (optional; default national total). e.g. "Buenos Aires", "Córdoba", "Neuquén" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It discloses the data source and the key default behavior: 'No province → national total.' It does not detail output format or units, but this is a simple lookup and the disclosed behavior is meaningful.
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?
One compact sentence front-loads country, scope, and source, then adds the conditional national-total behavior. Every word 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 tool with one optional parameter and no output schema, the description supplies the essential context: source, scope, and default behavior. It could state the exact return value shape or enumerate province names, but the schema examples plus the census-specific wording keep it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the province parameter is already documented as optional with a default national total and examples. The description reinforces this behavior but adds little beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies an exact resource: Argentina province total populations from the INDEC 2022 Census, with a clear national total fallback. This is specific and distinguishes it from other country-specific demographic tools among the 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 description makes clear it is for Argentine province population data and explains the default when no province is supplied. It does not explicitly name alternatives or exclusions, but the country/scope context is unambiguous enough for routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Argentina 4-digit postal code → postal region/provinces/cities via the Correo Argentino leading-digit scheme.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | Argentina 4-digit numeric postal code (e.g. 1000 = CABA) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It discloses a meaningful trait: the lookup uses the Correo Argentino leading-digit scheme, implying approximate region/province/city mapping rather than a full street-level address. However, it does not mention output format, invalid code handling, or other 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 a single, compact sentence that front-loads the country and input format, and uses an arrow to convey the operation without wasted words. Every phrase contributes either scope or method 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 description adequately covers the input, output categories, and lookup method, which is enough for an agent to understand the tool's basic function. It omits exact response structure and error behavior, but given the low complexity, this 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?
The only parameter, postcode, is already fully documented in the input schema with its format and an example. The description adds no new parameter-level meaning beyond restating that it is an Argentine 4-digit postal code. With 100% schema coverage, the baseline of 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 uses an arrow to clearly express a mapping from an Argentine 4-digit postal code to postal region/provinces/cities, identifying the resource and expected output. The 'Correo Argentino leading-digit scheme' detail further differentiates it from other country-specific postcode lookup siblings, though the verb is implied rather than 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?
There is no explicit guidance on when to use this tool versus alternatives, and no named sibling tool. However, the description and tool name clearly scope it to Argentina, so an agent can infer it is the right choice for Argentine postal codes among the many country-specific lookup siblings. This is implied usage, not explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Argentina national holidays by year (Ley 27.399), with floating days shown on their applied (transferable-to-Monday) dates and Good Friday computed from Easter.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Year (optional; defaults to current) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully discloses that floating days appear on their applied transferable-to-Monday dates and that Good Friday is computed from Easter, which are non-obvious behaviors. However, it does not describe the return format, possible year constraints, or other edge-case behavior, so it is 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?
The description is a single concise sentence that front-loads the core purpose (Argentina national holidays by year) and then adds the two most important behavioral specifics. Every phrase earns its place 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?
For a single-optional-parameter read-only lookup, the description is largely complete: it identifies the country, legal basis, and the key calendar-adjustment behaviors. It omits an explicit statement of the return value structure, but the output is reasonably inferable as a list of holidays, and no output schema exists to demand more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single 'year' parameter fully, including its optionality and default-to-current behavior, so schema coverage is 100%. The description adds no further parameter-specific detail, matching the baseline of 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 states the resource (Argentina national holidays) and scope (by year, under Ley 27.399), making it clear what the tool provides. It lacks an explicit verb like 'list' or 'get', but the noun phrase is unambiguous and effectively differentiates it from au/nz/uk public holidays.
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 the tool: when Argentina national holidays are needed for a given year. It does not explicitly name alternatives or exclusions, but among the sibling set the country scope and holiday-specific wording provide clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Argentina national school year (Feb–Dec, winter break in July), provincial dates flagged flexible.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Year (optional; defaults to current) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It adds useful behavioral detail: the school year runs Feb–Dec, there is a winter break in July, and provincial dates are flagged as flexible. It does not, however, describe what the tool returns or how the flexibility flag appears for a given year.
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?
One compact sentence front-loads the country and immediately provides the operative calendar facts; there is no filler or repetition. Every phrase adds information about scope or flexibility.
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 lookup the description is mostly sufficient: country, calendar range, break, and flexibility are all present. The lack of an output schema or explicit return-format statement leaves a minor gap in whether the agent should expect individual term dates or a yearly summary.
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, year, is already fully described in the schema with its optionality and default ('Year (optional; defaults to current)'), so the description adds no parameter-level meaning. Baseline 3 is appropriate given 100% 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 resource as Argentina's national school year and gives its calendar span (Feb–Dec, July break), which is enough to recognize the tool as a school-terms lookup for Argentina. It lacks an explicit verb like 'returns' or 'provides,' but the country and calendar details distinguish it from sibling school-term 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?
No sentence tells an agent when to prefer ar-school-terms over au-school-terms, nz-school-terms, or uk-school-terms; the only differentiator is the country label in the name and first word. There are no exclusions or alternative routing hints, so an agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Argentina time zone (America/Argentina/Buenos_Aires, UTC-3). No DST since 2009.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It adds useful behavioral context by stating 'No DST since 2009,' implying the offset is fixed, but it does not disclose what the tool actually returns (e.g., current local time, offset, or a timezone string) or how that output is formatted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler; the essential identifying information is front-loaded and the DST caveat adds value. Every part 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, read-only lookup the description is sufficient for selection and invocation, but because there is no output schema the description should have clarified what the tool returns. The core timezone facts are present, yet the response semantics remain ambiguous.
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 is empty with 0 parameters, so there is nothing for the description to explain. The rule for zero-parameter tools gives a baseline of 4, and the description appropriately adds no parameter noise.
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 providing Argentina's timezone, including the IANA zone and UTC offset, which separates it from ar-cpi, ar-weather, and the other country-specific timezone tools. However, it is stated as a noun phrase rather than a verbed action like 'Returns' or 'Provides', so it stops short of the strongest framing.
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 rather than stated: an agent can infer it should call this tool when Argentina timezone information is needed, especially alongside sibling timezone tools for other countries. There is no explicit when-to-use/when-not-to-use guidance or mention of alternatives, and the DST note only loosely signals applicability for post-2009 dates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Argentina national unemployment rate (INDEC EPH punctual, total agglomerations), monthly.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | National (default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden and does add value by specifying the source (INDEC EPH punctual), coverage (total agglomerations), and monthly cadence. It does not mention return shape, units, revision/update lag, or how the region parameter behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no filler, front-loading the statistic and geographic scope. Every phrase adds meaningful context: country, metric, source, coverage, and frequency.
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-optional-parameter lookup, this is minimally viable: it tells the agent what data is returned and from where. However, without an output schema it leaves units, date range, exact response structure, and region value handling to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the only parameter. The description's mention of 'national' and 'total agglomerations' corroborates the default region but adds no new accepted values or formatting 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 identifies a precise resource: Argentina's national unemployment rate from INDEC EPH, with source and monthly frequency. It is clearly distinct from sibling tools like ar-cpi, ar-demographics, and au-unemployment, though it lacks an explicit action 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 context implies use whenever an agent needs Argentina's national unemployment rate. It does not explicitly state when not to use it or name alternatives, leaving usage mostly inferred from the country and metric.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest observation (temp, rain, wind) + 7-day forecast for Argentina cities via Open-Meteo. 1-day TTL.
| Name | Required | Description | Default |
|---|---|---|---|
| suburb | Yes | Argentina city, e.g. "Buenos Aires", "Córdoba", "Ushuaia" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It adds useful context by naming the data source (Open-Meteo), the data categories returned (temp, rain, wind, forecast), and the 1-day TTL caching behavior. It does not describe output structure or error handling, but for a simple read-only weather lookup this is reasonably 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 two short sentences with no filler. The first sentence front-loads the core purpose and geographic scope, and the second adds the TTL detail, which is relevant but secondary.
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 no annotations, the description covers the essential context: what data is returned, where it applies, where it comes from, and how fresh it is. It lacks explicit units and response format details, but these are minor for an agent deciding whether and how to call this simple weather tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single 'suburb' parameter fully with a description and examples like 'Buenos Aires', 'Córdoba', and 'Ushuaia'. The tool description reinforces the Argentina-city scope but does not meaningfully add new parameter-level detail beyond what the schema already provides. Baseline 3 is appropriate given 100% 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 states exactly what the tool does: it returns the latest observation (temp, rain, wind) and a 7-day forecast for Argentina cities. This clearly distinguishes it from sibling tools like ar-cpi and ar-demographics, as well as from au-weather or nz-weather via the Argentina 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?
The phrase 'for Argentina cities' provides clear geographic context for when this tool is appropriate. It does not explicitly name alternatives or state when not to use it, but the country scoping plus sibling names like au-weather and nz-weather make the routing obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quarterly building activity (8752.0) — value of work done and commenced at LGA level. Complements building approvals.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | AU state code: NSW, VIC, QLD, SA, WA, TAS, NT, ACT | |
| suburb | Yes | Suburb name, e.g. "Parramatta" | |
| postcode | No | 4-digit postcode, narrows disambiguation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It usefully conveys that the data is quarterly, covers value of work done and commenced, and is aggregated at LGA level. It does not disclose read-only nature, parameter behavior, default scoping, or return format, so it provides only partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs the essential facts: data source, cadence, measures, and geography. Every clause adds value, and the sibling relationship is stated without excess verbiage.
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 data source, metric, frequency, and geographic level, which is reasonably complete for a data-retrieval tool. However, with no output schema and three parameters that affect geographic disambiguation, it does not explain how the query parameters map to results or what the returned time series looks like.
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 documents all three parameters — state, suburb, and postcode — with 100% coverage, so the baseline is 3. The description's mention of 'LGA level' hints at the geographic filtering role of these parameters but adds no concrete detail about how suburb, state, or postcode are combined or disambiguated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource — quarterly building activity from ABS catalog 8752.0 — and clarifies the key measures (value of work done and commenced) and geography (LGA level). It also distinguishes the tool from the sibling au-abs-building-approvals by noting it complements rather than duplicates that data. However, it lacks an explicit verb such as 'returns' or 'retrieves', 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 phrase 'Complements building approvals' gives useful context that this tool covers building activity rather than approvals, and implies these two tools can be used together. It does not explicitly state when to choose this tool over alternatives or when it should not be used, so the usage guidance remains implied rather than fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Monthly building approvals (dwellings, value, by type) at LGA level from ABS BA_LGA2024/2025. Agents frequently ask “how many houses/units approved in this LGA last year?”
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | AU state code: NSW, VIC, QLD, SA, WA, TAS, NT, ACT | |
| suburb | Yes | Suburb name, e.g. "Parramatta" | |
| postcode | No | 4-digit postcode, narrows disambiguation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does add useful behavior: monthly frequency, LGA-level aggregation, the ABS source, and the measured attributes. Still, it does not disclose the output shape, how suburb maps to an LGA, or the temporal coverage, so the behavioral picture is incomplete.
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 no filler. The first sentence front-loads source, frequency, granularity, and content; the second adds a realistic user query that helps agents recognize intent.
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 gives enough domain context for an agent to recognize when this tool applies, but with no output schema it omits response structure and disambiguation behavior. This is adequate but leaves clear gaps for an agent predicting what the tool will return.
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%, with all three parameters (state, suburb, postcode) described inline. The description adds LGA-level context but does not add parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: monthly building approvals with dwellings, value, and type at LGA level from ABS BA_LGA2024/2025. It is differentiated from siblings by content, but it lacks an explicit verb such as 'returns' or 'retrieves' and does not directly distinguish itself from the closely named sibling au-abs-building-activity.
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 example query 'how many houses/units approved in this LGA last year?' implies when this tool is relevant. However, it does not state when not to use it or point to alternatives such as au-abs-building-activity, leaving usage guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Australian Bureau of Statistics demographics at LGA level: Estimated Resident Population (ERP), SEIFA Index of Relative Socio-economic Advantage and Disadvantage (IRSAD), and selected census characteristics (median age, median income, household size, dwelling type). Quarterly/annual releases.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | AU state code: NSW, VIC, QLD, SA, WA, TAS, NT, ACT | |
| suburb | Yes | Suburb name, e.g. "Parramatta" | |
| postcode | No | 4-digit postcode, narrows disambiguation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the data release frequency ('Quarterly/annual releases'), which is a useful behavioral trait. However, it does not state whether the tool is read-only, requires authentication, has rate limits, or what the response format is. Significant behavioral aspects remain undisclosed.
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, well-structured sentence that front-loads the essence (ABS demographics at LGA level) and then enumerates the content. No unnecessary words 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?
The description lists the data types but omits crucial context: how to interpret the output (no output schema), the relationship between suburb input and LGA output, and whether historical time series are returned. The mention of release frequencies hints at temporal data but does not clarify response structure. An agent calling this tool would still be uncertain about the actual return 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 description coverage is 100%, so the baseline is 3. The description adds no information about the parameters beyond what the schema already provides. It does not explain how the 'suburb' input maps to LGA level, which is a notable semantic gap given the description specifies LGA-level data.
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 provides Australian Bureau of Statistics demographics at LGA level, listing specific data types (ERP, IRSAD, census characteristics). This distinguishes it from sibling tools like building activity or crime. However, it does not explicitly differentiate from similar demographic tools like nz-demographics beyond the country reference.
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. It does not mention that it covers only Australian demographics or that nz-demographics should be used for New Zealand. There is no explicit condition or scenario provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ABS Average Weekly Earnings (AWE) full-time adult ordinary-time earnings, Persons, All industries. Semi-annual. Region defaults to National.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | ABS region or "National" (default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It adds useful context: the series is semi-annual and defaults to National. However, it does not mention whether the tool returns a time series, the latest value, or any other output characteristics, leaving significant behavioral 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 a single compact sentence that conveys the data identity, frequency, and default region without fluff. It is not front-loaded with an action verb, but every word carries 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 one-parameter lookup with no output schema and no annotations, the description covers the data identity and basic scope but leaves the response format and whether it returns a single value or a series unspecified. An agent may be uncertain about what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single region parameter, and the schema already states it is an 'ABS region or "National" (default)'. The description only reaffirms the default, adding minimal new 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 identifies a specific ABS statistical series (Average Weekly Earnings, full-time adult ordinary-time earnings, Persons, All industries) with enough precision to distinguish it from sibling tools like au-income or au-cpi. It lacks an explicit verb like 'get' or 'returns', but the resource and scope are 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 usage by naming the exact data series, but it does not explicitly say when to use this tool versus alternatives such as au-income. The 'Semi-annual' and 'Region defaults to National' hints provide some context, but no routing guidance or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RBA cash rate target (F1.1 monthly average, series FIRMMCRT). Returns the most recent 12 observations (date + rate).
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Always "National" (RBA policy rate) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a read-only operation ('Returns'), an output limit (most recent 12 observations), output shape (date + rate), and data provenance (F1.1 monthly average, series FIRMMCRT). It does not mention update frequency or authentication, but for a public statistical data fetch this is strong 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?
Two concise sentences with no filler. Every part contributes either the resource identity, the series identifier, or the exact return contract. The most important 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, no-output-schema read tool, the description plus schema gives an agent enough to call it correctly: no required parameters, output is known, and the source series is specified. Minor details like date format or update cadence are not included, but they are not essential 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 100%, and the schema already explains that the sole parameter 'region' is always 'National'. The description adds no parameter-specific detail, but none is needed because the schema handles it. This matches the baseline-3 expectation for high 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 resource (RBA cash rate target), names the exact series (FIRMMCRT), and states the action ('Returns the most recent 12 observations'). It does not explicitly contrast with sibling tools, but the resource is unambiguous enough that an agent can tell it apart. Sibling differentiation is not as explicit as in a tool that names alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: if an agent needs the latest RBA cash rate observations, this is the tool. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternative tools are mentioned. The description provides enough context for a straightforward lookup, but not explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ABS quarterly CPI YoY change (6401.0) for Australia or capital-city region. Returns latest period and YoY percentage.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | ABS region or "National" (default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that it 'Returns latest period and YoY percentage', which is a useful behavioral detail about output. However, it does not explicitly state safety characteristics (e.g., read-only, no side effects) or any limitations, leaving some assumptions for the agent. The description is not misleading but is minimal in 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 a single sentence of about 20 words, front-loaded with the core purpose and output. Every word adds value, with no fluff or repetition. It is exceptionally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, no output schema, and no annotations, the description is nearly complete. It specifies the data source (ABS 6401.0), the scope, and the output (latest period and YoY percentage). The only minor gap is a lack of explicit note about the absence of side effects, but for a CPI retrieval tool that is not a significant omission. The agent can call it correctly with the given information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the single parameter 'region' has a description ('ABS region or 'National' (default)'). The tool description adds a mild hint about scope ('Australia or capital-city region'), but this is largely redundant with the schema. While the description does reinforce the parameter's meaning, it does not add significant new semantics beyond the schema, so a baseline score of 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 ('Returns') and resource ('ABS quarterly CPI YoY change (6401.0)') and clarifies scope ('for Australia or capital-city region'). It clearly differentiates from siblings like au-abs-building-activity or au-cash-rate by focusing on CPI data, so an agent can identify its purpose 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 context (Australia or capital-city region) but does not explicitly state when to use this tool versus alternatives or when not to use it. It is implied that this is the go-to for Australian CPI, but no explicit exclusions or alternative references are given. This is adequate but not proactive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ATO Taxation Statistics by postcode: median and mean taxable income, individuals lodging returns, and median net tax. Annual release (~1 year lag), currently 2022-23. High demand for property and market analysis agents.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | 4-digit Australian postcode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses data vintage and update frequency, but does not explicitly state read-only behavior, output format, or behavior for missing/invalid postcodes.
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 well-structured: core resource and fields first, then data vintage, then use cases. Every sentence adds relevant context and there is no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup, the description covers the resource, the returned statistics, temporal coverage, and likely use cases. It lacks only explicit notes on invalid postcodes or missing data, which are minor for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'postcode' is already fully described in the schema as a 4-digit Australian postcode. The description merely reuses 'by postcode' and adds no format, example, or edge-case guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies an ATO taxation statistics resource for postcodes and enumerates its specific data fields (median/mean taxable income, individuals lodging returns, median net tax). It differentiates from siblings by geographical/statistical scope, but lacks an explicit action verb such as 'returns' or 'retrieves'.
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 intended-use context ('High demand for property and market analysis agents') and useful timing context (annual release, ~1 year lag, 2022-23), but does not explicitly state when to prefer this over alternatives like nz-income or au-abs-demographics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NSW Environmental Planning Instrument hazard layers: flood planning areas and landslide risk land, queried by point or suburb. Coverage is sparse — some LGAs have no hazard polygons mapped; responses flag coverage honestly.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude within NSW (-38.5..-27.5). Provide with lng instead of suburb. | |
| lng | No | Longitude within NSW (140.5..154.5). Provide with lat instead of suburb. | |
| hazard | No | Which hazard layer: "flood", "landslide", or "all" (default) | |
| suburb | No | NSW suburb name, e.g. "Wollongong". Provide either suburb OR lat+lng. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It adds a genuine behavioral trait with 'responses flag coverage honestly' and implies a read-only query through 'queried'. However, it does not describe the response shape, error or ambiguity handling, or concretely explain what 'flag coverage' means in the returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler: the first names the resource, layers, and query modes, and the second provides the single most important caveat about coverage. Every clause carries operational value.
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?
Parameter selection is well covered by the schema, and the sparse-coverage caveat is a useful addition. However, there is no output schema, so the description should at least hint at the return format or content; it only says responses 'flag coverage honestly', leaving the response model vague.
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 already documents all four parameters at 100% coverage, including the either-or relationship between lat/lng and suburb and the 'flood'/'landslide'/'all' hazard values. The description only restates the point-or-suburb query mode generally, adding no 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 opens with the specific resource, 'NSW Environmental Planning Instrument hazard layers', then enumerates the exact layers ('flood planning areas and landslide risk land') and query modes ('queried by point or suburb'). This clearly distinguishes it from all sibling tools, none of which target hazard data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes when it applies ('queried by point or suburb') and includes the sparse-coverage caveat ('some LGAs have no hazard polygons mapped'), which is important for interpreting absent results. It does not explicitly name an alternative or state when not to use it, but the sibling list contains no comparable hazard tool, so the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolves any 4-digit Australian postcode to its dominant Local Government Area (LGA, 2024) and Statistical Area Level 2 (SA2, 2021) using ABS ASGS Edition 3 correspondence tables (population-weighted ratios). Unlocks cleaner LGA/SA2 joins for demographics and building lookups.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | 4-digit Australian postcode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It clearly discloses the mapping methodology (ABS ASGS Edition 3 correspondence tables, population-weighted ratios) and the critical 'dominant' resolution behavior, which matters because postcodes often overlap multiple LGAs/SA2s. It does not describe error handling or return format, but the core behavioral traits are 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?
Two sentences with no filler. The first sentence front-loads the action, input, outputs, and methodology; the second adds practical value by stating the use case. 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 single-parameter lookup with no annotations and no output schema, the description covers the core behavior and use case. However, it omits expected return structure (e.g., whether codes or names are returned) and behavior for invalid or unmapped postcodes, which an agent might need to handle confidently.
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 already fully describes the single parameter as '4-digit Australian postcode' (100% schema description coverage). The tool description repeats the '4-digit' concept but adds no new parameter-level detail, so the baseline of 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 uses a specific verb ('Resolves') with a clear resource ('4-digit Australian postcode' to 'dominant LGA and SA2'), and distinguishes itself from sibling data-table tools by the postcode-to-geography mapping function. Including ABS ASGS Edition 3 and population-weighted ratios makes the purpose precise and 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 final sentence implies usage context ('Unlocks cleaner LGA/SA2 joins for demographics and building lookups'), but it does not explicitly state when to use this tool versus alternatives or when not to use it. No sibling lookup tool exists among the listed siblings, yet the description still leaves the decision to inference rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Property crime incidence rates for Australian suburbs: break-and-enter, motor vehicle theft, other theft. Rates are per 100,000 residents, annualised.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | AU state code: NSW, VIC, QLD, SA, WA, TAS, NT, ACT | |
| suburb | Yes | Suburb name, e.g. "Parramatta" | |
| postcode | No | 4-digit postcode, narrows disambiguation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden. It usefully adds that rates are per 100,000 residents and annualised, which clarifies the metric type. However, it does not disclose the time period covered, the response shape, or any limitations, leaving some behavioral ambiguity.
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, naming the dataset, geography, crime types, and units in two short sentences. There is no redundant wording 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 simple three-parameter lookup with fully documented schema, the description captures the essential subject and metric. It does not mention the specific time period or whether results are broken down by crime type, but the tool is simple enough that these gaps 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 schema already documents all three parameters. The tool description adds context about crime categories and units, but it does not add meaning specific to the state, suburb, or postcode parameters 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 identifies the resource: property crime incidence rates for Australian suburbs, with specific crime categories. It lacks an explicit action verb like 'returns' or 'provides', but the subject matter is sufficiently unambiguous and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention exclusions, disambiguation strategies, or compare itself to related Australian statistics tools, so an agent must infer suitability 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.
Australian public holidays for all states/territories: full list for a year plus the next upcoming holiday with days-away. Ideal for scheduling, payroll, travel, and long-weekend questions.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Calendar year (default: current year) | |
| state | No | NSW, VIC, QLD, SA, WA, TAS, NT, ACT, or ALL (default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does a good job by stating the output includes a full yearly list and the next upcoming holiday with days-away, information not present in the schema. It does not mention response formatting or data source details, 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?
Two concise sentences with no filler. The first sentence states the resource and output content, the second gives use cases. Every phrase earns its place, and the most important 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?
This is a simple two-optional-parameter tool with no output schema and no annotations. The description explains the main return values, covers the geographic scope, and mentions relevant use cases. It could be more explicit about how the state parameter filters results, but the schema covers that, so overall the description is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description mentions 'year' and 'all states/territories' but does not add meaning beyond what the input schema already documents for the two parameters. It does not introduce any new parameter details or format constraints.
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 (Australian public holidays) and what it returns: a full yearly list plus the next upcoming holiday with days-away. It lacks an explicit verb like 'get' or 'list', but its meaning is unambiguous and it distinguishes itself from siblings such as nz-public-holidays and au-school-terms by the Australian holiday focus.
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 concrete use cases ('scheduling, payroll, travel, and long-weekend questions'), which tells an agent when this tool is relevant. It does not explicitly state when not to use it or name alternative tools, but the context is clear enough for selection among the provided siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public school term dates for each Australian state/territory (4 terms per year). For parents, travel, and childcare planning agents.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Calendar year (default: 2026) | |
| state | Yes | NSW, VIC, QLD, SA, WA, TAS, NT, or ACT |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses data content and term count but not how results are returned (e.g., term start/end dates, JSON shape) or whether output covers future years beyond the default. The 'public school' qualifier and 4-terms-per-year detail add some useful 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?
Two short sentences front-load the core purpose and then add the intended audience. No filler or redundant restatement of schema 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 simple data-lookup tool with fully documented parameters, this is mostly complete, but there is no output schema and the description does not specify the return format or that it provides start/end dates. An agent would need to infer the exact response structure from the tool name and schema 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 100%, so the description is not required to document parameters. The narrative adds no new semantics beyond the schema's 'year default 2026' and state abbreviations, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear resource ('public school term dates') and scope ('each Australian state/territory'), and '4 terms per year' clarifies granularity. It does not use an explicit retrieve/provide verb, but the meaning is unambiguous and the Australian scope distinguishes it from nz-school-terms.
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 second sentence names concrete use cases (parents, travel, childcare planning), giving clear context for when to invoke. It does not explicitly state when not to use it or mention alternatives such as au-public-holidays or nz-school-terms, though the scope makes the main distinction implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Australian time zones per state: IANA zone, standard/DST offsets, current offset and local time, and whether daylight saving is active. Answers "what time is it in Perth" and "is it daylight saving" instantly.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | NSW, VIC, QLD, SA, WA, TAS, NT, or ACT (default: all states) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it does a good job by enumerating the returned data: IANA zone, standard/DST offsets, current offset, local time, and DST status. It also signals a read-only informational behavior and fast lookup. It does not discuss edge cases or data sourcing, but for a simple lookup tool the main behavior is clearly conveyed.
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: two sentences that front-load the core data elements and then give concrete example questions. Every sentence contributes useful information, and there is no redundant restatement of the tool name or 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 simple optional-parameter lookup tool, the description covers the essential behavioral contract: what data is returned and what questions it answers. Since there is no output schema, the explicit enumeration of output fields compensates well. It might be slightly improved by noting the output format or handling of invalid states, but those are minor gaps given the low 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 coverage is 100%, so the parameter's meaning is already documented in the input schema. The description adds context by mentioning states and the example "Perth", but it does not materially expand on the schema or clarify behavior for omitted versus provided state values beyond the schema's default note.
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 providing Australian time zone information per state, listing specific output fields: IANA zone, standard/DST offsets, current offset, local time, and DST status. The examples, "what time is it in Perth" and "is it daylight saving", reinforce the concrete use cases and help distinguish it from sibling tools like nz-timezone.
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—whenever Australian time zone or DST questions arise—and the examples make the intended queries explicit. However, it does not explicitly state when not to use it or mention alternatives such as nz-timezone for New Zealand inquiries, leaving the agent to infer the geographic boundary from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ABS monthly unemployment rate (6202.0). Regions: National, NSW, VIC, QLD, SA, WA, TAS. State aliases accepted (e.g. 'New South Wales'->NSW). NT/ACT not available from the ABS LF flow (returns 404 'no data').
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | National, NSW, VIC, QLD, SA, WA, or TAS (NT/ACT have no 6202.0 series) |
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 usefully discloses that state aliases are accepted and that NT/ACT returns a 404 'no data' error, but it does not describe the output format, units, default behavior when region is omitted, or whether historical series are returned.
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 four short, information-dense sentences. Every sentence contributes either the core purpose, allowed values, alias behavior, or a notable error condition, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool, the description covers source, regions, aliases, and an important limitation. However, there is no output schema and the description does not specify what the tool returns (e.g., latest value, time series, percentage), nor the default behavior when the optional region parameter is omitted.
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 100% coverage for the region parameter, so the baseline is 3. The description adds value beyond the schema by explaining that state aliases are normalized (e.g., 'New South Wales' -> NSW) and that NT/ACT is not supported, clarifying the parameter's practical 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 clearly identifies the tool as providing the ABS monthly unemployment rate (6202.0), which distinguishes it from sibling tools like au-cpi or au-awe. It lacks an explicit verb like 'returns' or 'gets', but the resource and scope are 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 usage for monthly unemployment rate lookups and explicitly lists allowed regions plus NT/ACT exclusion. However, it does not name alternative tools or provide explicit 'use this when...' versus 'use that when...' guidance, leaving the selection logic somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ABS Job Vacancies (JV) — total vacancies (thousands), All sectors / All industries, Original estimates, quarterly. Region defaults to National.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | ABS region or "National" (default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the data source, estimation type, frequency, and default region behavior. It does not explicitly say the operation is read-only, but the nature of a data-query tool makes that inherent. The disclosed details add meaningful context beyond a simple name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence with no filler. It front-loads the dataset name and packs in units, scope, frequency, and default behavior efficiently.
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 low-complexity tool with one optional parameter and no output schema, the description covers the essential facts: data source, metric, units, scope, frequency, and default region. It does not enumerate valid region values, but the schema's parameter description partially addresses that. Overall, it is 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?
Schema coverage is 100% for the single region parameter, so the schema already documents it. The description reinforces the default ('Region defaults to National') but adds no new parameter-level semantics beyond what the schema states.
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 dataset (ABS Job Vacancies) with detailed attributes: total vacancies in thousands, all sectors/industries, original estimates, quarterly. This clearly distinguishes it from sibling tools like au-unemployment or au-cpi 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 gives clear context about the data (quarterly, national default) but does not explicitly state when to use this tool versus alternatives. Since sibling tools cover different economic indicators, the intended use is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest observation (temp, rain, wind) + 7-day forecast for Australian suburbs via Open-Meteo. 1-day TTL.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | AU state code (NSW, VIC, etc.) | |
| suburb | Yes | Suburb name, e.g. "Parramatta" | |
| postcode | No | 4-digit postcode for tie-breaking |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It usefully discloses the data source (Open-Meteo) and the 1-day TTL, but it does not mention limitations, ambiguity handling beyond the schema's tie-breaking note, or output format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, information-dense sentence that front-loads the core result, scope, source, and cache TTL. Every phrase adds value with no redundant or filler language.
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 straightforward lookup tool, the description covers the essential return contents, geographic scope, data source, and freshness. With no output schema or annotations, a bit more detail about units or response shape could help, but nothing critically 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 each parameter in the schema already has a meaningful description, including postcode's tie-breaking role. The tool description itself does not add much parameter-level meaning, so the baseline of 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 identifies the resource (Australian suburb weather) and the payload (latest observation plus 7-day forecast). It lacks an explicit action verb, but the intent is unmistakable and it is distinct from all sibling tools, none of which are weather-focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this for current conditions and forecasts for Australian suburbs. It does not explicitly name alternatives or exclusions, but no sibling tool competes for weather lookups, so the usage context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full service catalog with complete param specs, return fields, prices, and cache TTLs. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool is free and that it returns full catalog data, but it does not disclose whether it has side effects, requires authentication, has rate limits, or how the data is returned. The lack of explicit read-only or safety context leaves important 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 a single compact sentence that front-loads the core purpose and lists the catalog's key contents. The additional 'Free.' fragment is short and communicates a relevant fact without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description does well by outlining exactly what the catalog contains: param specs, return fields, prices, and cache TTLs. It doesn't provide details on response format or potential size, but those are secondary for such a simple, self-describing read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to document beyond the schema. Since the schema has 100% coverage for its empty properties and the description doesn't need to explain parameters, the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning the full service catalog and specifies the contained information (param specs, return fields, prices, cache TTLs), making the purpose evident. It does not explicitly differentiate from the sibling list_services, so it misses some opportunity to distinguish itself.
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 a complete catalog of service details is needed, but it gives no explicit guidance on when to use this tool versus list_services or other alternatives. There is no when-not-to-use guidance or mention of how this tool relates to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Server health check: status, registered services, endpoint map. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only status operation and discloses the returned content categories plus that it is free, which is useful. However, it does not state response format, authentication needs, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: it states the tool's purpose first, then lists the key returned information, and closes with the free pricing note. Every part 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 health-check tool, the description is reasonably complete. It names the main return categories and pricing. It does not specify the exact response schema, but the lack of output schema is offset by the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter meanings. The schema already covers this completely, and the description adds no conflicting or missing parameter information.
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 this as a server health check and lists the resources it reports on (status, registered services, endpoint map). It is distinct from the data-specific sibling tools, though it does not explicitly differentiate itself from list_services, which might also expose services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical invocation timing, or why a caller would choose this over list_services or other catalog-like tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List data services offered by this server: ids, countries, prices, and required params. Optional country filter (ISO 3166-1 alpha-2, e.g. "AU", "US", "GB"). Free.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO 3166-1 alpha-2 country code filter, e.g. "AU" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. 'List' implies a safe read operation, and 'Free' discloses cost, while the listed fields describe the response. However, it does not confirm absence of side effects, pagination behavior, or what happens when the country filter matches nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first front-loads the purpose and return contents, the second covers filtering and cost. 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, parameterless-required list tool, the description covers what the agent needs: what is listed, the optional filter, and pricing. Since no output schema exists, the explicit mention of response fields (ids, countries, prices, required params) is helpful, though a bit more detail on return shape would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds the word 'optional,' the ISO standard, and multiple example codes, but these are largely redundant with the schema's own parameter description and length constraints.
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?
Uses a specific verb ('List') and resource ('data services offered by this server'), and enumerates exactly what the response covers (ids, countries, prices, required params). This clearly distinguishes it from the sibling data-service tools, which are the things being listed.
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?
States the optional country filter, gives the ISO format with examples, and notes that the tool is free. The intended use as a catalog/discovery tool is clear from context, though it does not explicitly name alternatives or say when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stats NZ Business Demography Statistics: number of enterprises and employees by ANZSIC industry division, national total, latest year and full 2000+ history.
| Name | Required | Description | Default |
|---|---|---|---|
| industry | No | ANZSIC industry division code (e.g. "A" Agriculture, "C" Manufacturing) or name. Optional — omit for full latest-year breakdown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining what the tool does. It discloses the data dimensions, time span, and national scope, which is useful. However, it does not mention output format, update frequency, data caveats (e.g., rounding or suppression), or any access 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 a single compact sentence that front-loads the source, topic, and key attributes. Every clause conveys meaningful information, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description provides the essential context: what data is returned, at what granularity, and for what time range. It could be slightly more explicit about the output format, but the low parameter complexity keeps the risk 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?
Schema coverage is 100% for the single optional industry parameter, including the meaning and an example. The tool description adds context about ANZSIC industry divisions and the historical series, but the parameter itself is already well-documented 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 clearly states the resource: Stats NZ Business Demography Statistics, and specifies the data contents (number of enterprises and employees by ANZSIC industry division, national total, latest year, full history). This distinguishes it from sibling tools like nz-demographics or nz-income, though it lacks an explicit 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 explicit guidance is given about when to use this tool versus sibling statistics tools. The only usage hint is the schema note about omitting the industry parameter for a full breakdown. An agent must infer that this is the tool for business demography data rather than population or income data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NZ Police Recorded Crime Victims Statistics by police district. Victimisations by offence type, age group, and sex. Monthly series from 2021, latest year per district. Source: policedata.nz victimisations-demographics CSV.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | NZ Police district, e.g. "Auckland City", "Canterbury", "Wellington", "Counties Manukau" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the data source, time range, and aggregation dimensions, which is useful. It does not describe the output shape, update latency, or any limitations beyond 'latest year per district'.
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 no filler. It front-loads the core subject, then gives dimensions, time series, and source attribution efficiently. 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 statistics tool, the description covers the dataset scope, granularity, time range, and source. It does not describe the exact return format, but the data dimensions are stated clearly enough for an agent to understand what it will receive.
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 'region' is fully described in the schema with examples. The description's phrase 'by police district' aligns with the parameter but adds no extra semantics beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource: NZ Police recorded crime victim statistics, filtered by police district, with breakdowns by offence type, age group, and sex. It lacks an explicit verb like 'get' or 'list', but the content is specific and distinguishes it from sister tools such as au-property-crime and nz-demographics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for NZ police-district-level victimisation data and notes the monthly series from 2021. However, it does not explicitly state when to prefer this tool over alternatives, nor does it mention exclusions such as Australian crime data or offender statistics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stats NZ subnational Estimated Resident Population (June 2025, Aotearoa Data Explorer). Accepts region names (resolved to the region’s main territorial authority) or exact TA names, plus "Total NZ".
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | NZ region name, e.g. "Auckland", "Canterbury" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses a non-obvious behavior: region names are resolved to the region's main territorial authority. It also flags the special 'Total NZ' input. It does not describe output shape or error behavior, but for a simple data lookup it provides meaningful behavioral 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?
Two sentences with no filler. The first sentence front-loads the data source and subject; the second covers all accepted input variations. Every clause contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter look-up tool, the description is nearly complete: it states the dataset, the accepted inputs, and a behavioral nuance. It does not explicitly state the return value, but 'Estimated Resident Population' strongly implies the output. Absence of an output schema is a minor gap, not a critical one.
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?
Though schema coverage is 100%, the description significantly expands parameter meaning. It clarifies that 'region' accepts not only region names but also exact TA names and 'Total NZ', and explains how region names are normalized. This goes well beyond the schema's simple 'NZ region name' description.
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: Stats NZ subnational Estimated Resident Population for June 2025. It is clearly distinguishable from NZ and Australian siblings by data source and topic, but it lacks an explicit action verb like 'retrieves' or 'returns'. The intent is still unambiguous from the context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what inputs are accepted (region names, TA names, 'Total NZ') but does not mention when to prefer this tool over alternatives or when not to use it. Usage is implied—obtain NZ population data—but no exclusions or sibling comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stats NZ Household Economic Survey (HES) expenditure by NZHEC category. Average weekly spend, % households reporting, and sampling error. Survey years: 2007, 2010, 2013, 2016, 2019, 2023.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | NZHEC category code (e.g. "01" Food, "02" Alcohol, "03" Clothing). Optional — omit for full latest-year breakdown. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure, and it does reasonably well by naming the returned measures (average weekly spend, % households reporting, sampling error) and the available survey years. It does not describe behavior for invalid categories or how missing-category defaults work, but those are partly covered by the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, front-loaded sentences with no filler. Each clause contributes either the source, the data measures, or the temporal scope, making it easy for an agent to parse quickly.
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-optional-parameter data lookup, the description plus schema is largely complete: source, measures, category meanings, and survey-year availability are all covered. The absence of an output schema is mitigated by the explicit list of returned measures, though exact response formatting is not described.
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 single parameter is already documented in the input schema. The description reinforces the NZHEC-category focus but adds no syntax, defaults, or validation details beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific resource (Stats NZ Household Economic Survey) and domain (expenditure by NZHEC category), which distinguishes it from NZ income, demographics, and crime siblings. It lacks an explicit verb like 'retrieve' or 'query', but the noun phrase is unambiguous enough for tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: when NZ household expenditure data are needed, this tool is relevant. However, there is no explicit statement of when to use this tool versus alternatives such as nz-income or nz-demographics, and no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stats NZ median weekly earnings by region (Aotearoa Data Explorer LEED). 13 labour-graphing regions, latest Jan/June issue.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | NZ region name, e.g. "Wellington" |
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 adds useful behavioral context: the data comes from Stats NZ LEED, is limited to 13 labour-graphing regions, and reflects the latest Jan/June issue. However, it does not describe the response format, what happens for invalid regions, or any data caveats.
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 compact sentence that front-loads the core purpose, then adds source and scope details efficiently. There is no filler, and every phrase contributes 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 simple one-required-parameter tool with full schema coverage, the description is reasonably complete: it conveys what data is returned, from which source, for which regions, and how recent it is. It could list valid region names or describe the output shape, but those are minor gaps given the simple interface.
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 already documents the single required 'region' parameter with an example, and schema description coverage is 100%. The description only reinforces 'by region' and mentions 13 regions without enumerating valid values or specifying formatting, so it adds only marginal 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's purpose: retrieving Stats NZ median weekly earnings by region. It names the data source (Aotearoa Data Explorer LEED), the metric (median weekly earnings), and the scope (13 labour-graphing regions), making it easy to distinguish from sibling Australian income tools or NZ household expenditure.
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 context is implied: use this for New Zealand regional income data. However, it does not explicitly state when to use it versus alternatives such as nz-household-expenditure or au-income, nor does it mention any exclusions. The sibling names provide differentiation only implicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reserve Bank of New Zealand Official Cash Rate (B2 daily-close series). Trailing-12 distinct observations. Announcements are ~7-weekly.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Always "National" (RBNZ policy rate) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It usefully states that the series is daily-close, contains trailing-12 distinct observations, and updates roughly every 7 weeks. However, it does not describe the response format, whether anything is mutated, or how the single optional parameter affects 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?
Three terse sentences with no filler or repetition. The most identifying fact is front-loaded, and the trailing-12 and cadence details add useful specificity without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple optional-parameter data tool, the description states the series, scope, and recency, which is reasonably complete. However, with no output schema, it omits the return value shape or format, and it does not clarify how the optional region parameter should be handled 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?
The input schema already documents the only parameter with 100% coverage: region is always 'National' per the RBNZ policy rate. The description adds no further parameter-level meaning, but the schema alone is sufficient here, so a baseline score of 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 identifies the resource as the Reserve Bank of New Zealand Official Cash Rate, with series code B2 from a daily-close series. It does not use an explicit verb like 'returns' or 'fetches', but the resource and scope are unmistakable and distinct from sibling tools such as au-cash-rate.
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 when-to-use or when-not-to-use guidance, and does not mention alternatives like au-cash-rate for other central bank rates. The announcement cadence and trailing-12 details are data characteristics, not usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolves any NZ suburb or locality name to its Territorial Authority and Stats NZ population estimate via the LINZ Suburbs and Localities dataset (~5,900 places). Exact-name match plus prefix fallback. The join key that unlocks NZ crime/demographics/income lookups.
| Name | Required | Description | Default |
|---|---|---|---|
| suburb | Yes | NZ suburb or locality name, e.g. "Ponsonby" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses useful behavior beyond the schema: exact-name match with prefix fallback, dataset source, and approximate place count. However, with no annotations provided, it does not describe no-match behavior, ambiguity handling, or output format, leaving meaningful 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?
Two crisp sentences front-load the core purpose and immediately add scope, matching behavior, and usage context. Every phrase 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?
The tool is simple with one parameter, but there is no output schema and no annotations. The description omits failure/fallback ambiguity behavior and return shape, so an agent may not know what happens on no match or how results are structured.
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 parameter schema already includes an example ('Ponsonby'). The tool description adds no extra parameter-level semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Resolves') plus the resource ('any NZ suburb or locality name') and the expected outputs (Territorial Authority, Stats NZ population estimate). The LINZ dataset reference further anchors what the tool does and sets it apart from the data-query 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 join-key sentence clearly implies when this lookup should be used: before NZ crime, demographics, or income lookups. It does not name alternatives or explicitly say when not to use it, but the intended context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
New Zealand public holidays: national holidays (Waitangi, Matariki, Anzac, etc. with observed-date shifts) plus regional anniversary days. Verified against Employment NZ. Unknown years return an explicit notice.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Calendar year (default: current year) | |
| region | No | NZ region for anniversary day, or ALL (default): Northland, Auckland, Waikato, Bay of Plenty, Gisborne, Hawke’s Bay, Taranaki, Manawatu-Whanganui, Wellington, Tasman/Nelson, Marlborough, West Coast, Canterbury, Otago, Southland, Chatham Islands |
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 observed-date shifts are included, that regional anniversary days are covered, that data is verified against Employment NZ, and that unknown years return an explicit notice. It does not mention response format, date ranges, or any limits, so transparency 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 well-structured sentences deliver the core purpose, scope, data source, and an important edge-case behavior. Every clause adds value and the most 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 simple lookup tool with two optional parameters and no output schema, the description covers the essential context: what holidays are included, regional handling, accuracy, and unknown-year behavior. It omits an explicit description of the return shape, but that is a minor gap given the tool's low 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 coverage is 100%, so the parameters year and region are already documented in structured form. The description adds context about observed-date shifts and regional anniversary days, which helps interpret the region parameter, but it does not add detailed semantics beyond the schema. 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 identifies the resource (New Zealand public holidays) with specific examples (Waitangi, Matariki, Anzac) and distinguishes national holidays from regional anniversary days. It differentiates from sibling tools such as au-public-holidays and nz-school-terms by focusing on NZ public holidays specifically.
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: whenever New Zealand public holidays are needed for a year and region. It does not explicitly state when not to use it or name alternatives like nz-school-terms or au-public-holidays, leaving the boundary to inference rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
New Zealand public school term dates (nationally uniform) per the Ministry of Education, with official start-window flexibility flagged. Unknown years return an explicit notice.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Calendar year (default: current year) | |
| school_type | No | primary, secondary, or both (default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It usefully flags official start-window flexibility and states that unknown years return an explicit notice. It does not describe the output shape, but this is a minor gap for a simple lookup 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?
One compact, front-loaded sentence covers the core purpose and scope, and a second sentence adds edge-case behavior. No filler or redundant restatement of the schema.
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 geographic scope, data source, national uniformity, and unknown-year behavior, while parameters are handled by the schema. Without an output schema, slightly more return-structure detail would make it fully complete, but no essential calling context 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?
Input schema coverage is 100%, with year and school_type already described in the schema. The description adds no parameter-specific semantics, so the 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 names a specific resource (New Zealand public school term dates) and distinguishes it from siblings like au-school-terms and nz-public-holidays by scope and jurisdiction. It lacks an explicit main verb such as 'returns' or 'gets', 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 provides clear context: this tool is for New Zealand public school term dates, so an agent can select it over Australian or holiday-related siblings. It does not explicitly name alternatives or state when not to use it, but the jurisdictional and topical scope is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
New Zealand time zones with live DST status: Mainland (Pacific/Auckland) and Chatham Islands (Pacific/Chatham, +12:45). Computed from IANA at runtime — correct for any future date.
| Name | Required | Description | Default |
|---|---|---|---|
| zone | No | Mainland or Chatham Islands (default: both) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states that it computes from IANA at runtime, ensures correctness for any future date, and reports live DST status. This gives clear expectations about dynamic behavior and scope. It does not mention output format, but for a read-only informational tool this is sufficient.
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 well-structured sentences front-load the core purpose and zone breakdown, then add the runtime behavior note. No wasted words; all information is relevant and quickly 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 tool with one optional parameter and no output schema, the description covers the essential context: what zones are included, the default behavior (both), and the dynamic nature of the data. The only minor omission is an explicit statement of the return value structure, but the phrase 'live DST status' implies the output includes DST indicators, and the tool's simplicity makes this acceptable.
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 parameter 'zone' with a description covering values and default. The description adds valuable semantic detail by mapping 'Mainland' to Pacific/Auckland and 'Chatham Islands' to Pacific/Chatham, providing contextual meaning beyond the raw schema. This enhances the agent's ability to pick correct values.
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 provides New Zealand time zones with live DST status, explicitly naming the two zones (Mainland and Chatham Islands) and their IANA identifiers. This clearly distinguishes it from sibling tools like au-timezone (Australia) and nz-public-holidays.
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: it is for New Zealand time zone information and any future date. However, it does not explicitly state when to prefer this over au-timezone or other related tools, nor does it mention any exclusions or fallback logic. The guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest observation (temp, rain, wind) + 7-day forecast for NZ cities/regional seats via Open-Meteo. 1-day TTL.
| Name | Required | Description | Default |
|---|---|---|---|
| suburb | Yes | NZ city or regional seat name, e.g. "Auckland", "Christchurch", "Queenstown" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the behavioral disclosure burden. It adds meaningful traits: data comes from Open-Meteo, results are cached with a 1-day TTL, and coverage is limited to NZ cities/regional seats. It does not mention units or error behavior, but for this simple tool the provided transparency is above baseline.
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 short sentences to cover output type, geographic scope, data source, and cache freshness. Every phrase earns its place, and key 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 tool with no output schema and no annotations, the description provides enough context to understand what the tool returns and under what constraints. It is missing explicit return-format details and usage alternatives, but the low complexity of the tool keeps this from being a significant 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?
The input schema already documents the only parameter with 100% coverage, including examples. The description repeats that the location is an NZ city or regional seat, which adds little beyond the schema. No additional parameter semantics such as formatting rules or special values are provided.
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: latest weather observation (temp, rain, wind) and a 7-day forecast for NZ cities/regional seats via Open-Meteo. It is easily distinguishable from the au-weather sibling due to the explicit 'NZ' scope. It lacks an explicit retrieval verb, but the intended action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for NZ weather lookups by location, and the NZ scope helps separate it from Australian weather tools. However, it does not explicitly state when to prefer this tool over alternatives like au-weather, nor does it mention any exclusions or fallback conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
UK CPI 12-month inflation rate (ONS MM23 D7G7). Official, monthly.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | UK (default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states 'Official, monthly,' which describes data provenance and frequency, but does not explain whether the tool returns a single value, a time series, or any other output characteristics. No read-only or side-effect information is given.
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, with no wasted words. It packs the core metric, source identifier, and data quality into two short sentences, which is ideal for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description is adequate but leaves gaps. It does not state what the tool returns (e.g., latest rate vs. historical series) and there are no annotations to cover safety or side-effect behavior. The low complexity raises the bar slightly, but missing return information keeps it from being 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 only parameter, 'region', is fully described in the schema with 'UK (default)'. The description adds no additional meaning about parameters, so the baseline of 3 applies due to 100% schema description 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 resource as the UK CPI 12-month inflation rate, with a specific source code (ONS MM23 D7G7). This differentiates it from sibling tools like au-cpi or uk-unemployment, 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?
There is no guidance on when to use this tool or when to prefer an alternative. The description does not mention sibling tools, exclusions, or prerequisites, leaving the agent to infer that it should be used for UK CPI queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Street-level crime for a postcode via the UK police data API: latest-month counts by category, prior-month total, and trend. England & Wales only.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | UK postcode (e.g. SW1A 1AA) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains the data source, the geographic scope, and the exact output structure (category counts, prior-month total, trend), which makes the tool's behavior reasonably 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 entire description is one efficient, front-loaded sentence. It conveys source, scope, output, and geographic limitation without any 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 single-parameter tool, the description covers the essential elements: what data is returned, from which API, for which geography, and the trend comparison. It does not detail error handling or exact dates, but this is adequate given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the postcode parameter already includes a clear example in the schema. The description repeats that the tool works 'for a postcode' but adds no additional 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 specifies the tool's purpose: retrieving street-level crime data for a postcode from the UK police data API, including latest-month counts by category, prior-month total, and trend. The geographic qualifier 'England & Wales only' distinguishes it from sibling crime tools like au-property-crime and nz-crime.
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 context: it is for UK postcodes and limited to England & Wales. It does not explicitly name alternative tools for other regions, but the geographic scope effectively implies when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
UK / England / Wales / Scotland / Northern Ireland + English regions mid-year population (2019 vintage). ONS mid-year-pop-est, age-total.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Geography: UK (default), England, Wales, Scotland, Northern Ireland, or an English region name. |
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 usefully discloses the data source (ONS), vintage (2019), and variable type (mid-year population estimate, age-total), which goes beyond minimal identification. However, it does not state what the response contains, whether any rows/aggregations are returned, or any limitations such as data availability by region.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loads the key geographic scope, with no filler words. It is telegraphic and somewhat cryptic ('ONS mid-year-pop-est, age-total'), which slightly hurts readability, but every phrase carries 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 simple one-optional-parameter read-only tool, the description is mostly adequate: it names the geography options, source, and vintage. However, with no annotations and no output schema, it would be stronger if it stated that the result is a population count or a structured dataset per region, and clarified what 'age-total' means for the returned 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 description coverage is 100%, so the schema already documents the region parameter, including the UK default and acceptable geographies. The description repeats those geographies and adds the 2019 vintage context, but it does not materially deepen the meaning of the parameter 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 identifies a specific resource: mid-year population estimates for UK geographies, with geographic scope and vintage clearly stated. It lacks an explicit verb like 'get' or 'list,' but the phrase 'mid-year population' makes the purpose evident. The geography list also differentiates it from sibling tools like au-abs-demographics and uk-house-prices.
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 about when to use this tool versus alternatives. While sibling names suggest it is the UK demographics tool, the description itself does not mention conditions, exclusions, or why an agent should choose it over other uk-* or demographics tools. Usage context is only implied by the subject matter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
UK AWE whole-economy total pay including arrears, seasonally adjusted (ONS EMP KAB9). Monthly.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | UK (default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it does convey data-treatment behavior: monthly frequency, seasonally adjusted, and including arrears. It does not explicitly state that the tool is read-only or describe the response shape, but for a data lookup the disclosed series characteristics are meaningful.
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?
One compact sentence front-loads the series identifier and packs the key qualifiers (whole-economy, total pay, arrears, seasonally adjusted, ONS code, monthly) 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 tool with only one optional parameter and no output schema, the description is largely sufficient: it identifies the exact series, its source code, coverage, adjustment, and frequency. It omits explicit return-value semantics or units, but this is a minor gap at this low 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 coverage is 100%, with the region parameter already described as 'UK (default)', so the schema handles parameter documentation. The description adds no further parameter semantics, matching the baseline for high 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 names a specific economic series—UK AWE whole-economy total pay including arrears, seasonally adjusted—with the ONS code and monthly frequency. It clearly differentiates from siblings like uk-unemployment and uk-cpi, though it lacks an explicit verb such as 'returns' or 'retrieves'.
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 UK prefix and AWE series identity imply the tool is for UK average weekly earnings data, and 'Monthly' sets the time dimension. However, there is no explicit guidance about when to choose it over alternatives such as au-awe or uk-vacancies, nor any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Median house price by Local Authority (2018 vintage, ONS house price statistics for small areas). Query by postcode (resolved to its LA) or LA name.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Or a Local Authority name (e.g. "Birmingham") | |
| postcode | No | UK postcode (resolved to Local Authority) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden of behavioral disclosure. It usefully explains that postcodes are resolved to Local Authority level and that the data is 2018 vintage. However, it does not state what happens if both or neither parameter is provided, nor describe the output shape or currency.
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 concise sentences with no filler. The core dataset, source, vintage, and query modes are all front-loaded efficiently.
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 no output schema, the description does not explicitly require at least one of the two optional parameters, nor does it describe the return value beyond the implied median price. This ambiguity matters because both parameters are marked optional. Still, the core lookup behavior is adequately covered.
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 complete, so the baseline is 3, but the description adds meaningful semantics: it clarifies that postcode and LA name are alternative query modes via 'or'. This is especially valuable because the schema marks both parameters optional and the region parameter description is fragmentary.
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 resource — median house price by Local Authority — and adds the data source and vintage (2018, ONS house price statistics). It is clearly distinguishable from sibling tools like uk-postcode-lookup because it is about house-price statistics, not location resolution.
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 the tool is relevant: when an LA-level median house price is needed, queried either by postcode or by Local Authority name. It does not name alternatives or exclusions, but no direct house-price sibling exists, so the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
UK household income (median/mean, disposable/gross/post-tax/final/original) from the ONS effects of taxes and benefits on income table. Latest reference year 2020-21.
| Name | Required | Description | Default |
|---|---|---|---|
| income | No | Income definition: disposable (default), gross, post-tax, final, original | |
| measure | No | median (default) or mean |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the data source and reference year but does not describe return format, read-only nature, pagination, or any rate limits. For a data retrieval tool, this lack of behavioral detail is a notable 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 two concise sentences with no wasted words. The first sentence front-loads the core resource and available options, and the second sentence adds the reference year. The parenthetical list is dense but acceptable.
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 only two optional parameters and no output schema, the description provides sufficient context to invoke it. However, it does not clarify whether the result is a single value, a time series, or a table, leaving some uncertainty about the expected response shape.
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 already documents both parameters with descriptions, and coverage is 100%. The description's parenthetical list (median/mean, disposable/gross/post-tax/final/original) repeats the parameter options without adding extra semantic detail such as value formats or constraints, so it stays at the 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 specifies the resource ('UK household income') and its source ('ONS effects of taxes and benefits on income table'), which distinguishes it from sibling tools like uk-earnings. However, it lacks an explicit verb (e.g., 'retrieve' or 'fetch'), so the exact action is implied rather than stated.
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 context that this tool returns UK household income data, but it gives no guidance on when to use this tool versus alternatives such as uk-earnings or uk-cpi. Usage is implied rather than explicitly stated, with 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.
Resolves any UK postcode to its Local Authority (admin_district), ward, constituency, LSOA, NUTS region, and coordinates. Write-through to postcodes.io with 30-day Redis caching.
| Name | Required | Description | Default |
|---|---|---|---|
| postcode | Yes | UK postcode (e.g. SW1A 1AA) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It adds useful context about the postcodes.io dependency and 30-day Redis caching, and implies a read-only operation. However, it does not cover failure modes, error handling, or any auth/rate-limit considerations.
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 concise sentences with no filler. The first sentence front-loads the core purpose and outputs; the second adds relevant caching/backend detail. 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 low-complexity one-parameter tool, the description covers the essential behavior, lists the expected return fields, and notes the caching behavior. Since no output schema exists, enumerating admin_district, ward, constituency, LSOA, NUTS, and coordinates is valuable. It omits invalid-postcode behavior but is otherwise sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single 'postcode' parameter with a format example, so description-level parameter explanation is unnecessary. The description adds only the UK scope and output-field context, which is a modest addition. Baseline 3 applies due to 100% schema description 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 states a specific verb ('Resolves') and resource ('any UK postcode'), and enumerates the output fields. The explicit 'UK' scope clearly distinguishes it from the sibling au-postcode-lookup and nz-place-lookup 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 clearly identifies the intended context: UK postcode resolution. It does not explicitly name alternatives or when-not-to-use conditions, but the UK scope is unambiguous and sufficient for selecting this over country-specific siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
UK bank holidays by division (England & Wales, Scotland, Northern Ireland) with next-holiday countdown. Source: gov.uk bank-holidays.json.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Year to return holidays for (optional; defaults to current year) | |
| division | No | Division: ALL (default), england-and-wales, scotland, northern-ireland |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds useful non-obvious context by stating the source (gov.uk bank-holidays.json) and the next-holiday countdown feature. For a read-only public data lookup, this is adequate, though it doesn't describe response format or staleness.
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 compact sentence that front-loads the resource and scope, then adds the countdown behavior and data source. There is no filler, repetition of schema details, or unnecessary 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 with zero required parameters and fully documented input schema, the description is nearly complete: it names the domain, divisions, source, and countdown feature. It does not detail the exact response structure, but that is a minor gap for this simple holiday-data lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds human-readable division names, but the schema already documents both parameters and their defaults, so the description provides little additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (UK bank holidays), the scope (by division), and a distinguishing feature (next-holiday countdown). It lacks an explicit imperative verb like 'List' or 'Get', but the noun-phrase style is unambiguous and the UK scope separates it from the AU/NZ public-holiday 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 description makes it clear this tool serves UK bank holiday queries and supports division-specific lookups, which is sufficient context for an agent to route to it. It does not explicitly name alternatives or state when not to use it, but the sibling tool names make the intended domain obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
England state-school term dates per academic year (Autumn/Spring/Summer) on the majority-of-LA pattern, with an explicit note that individual local authorities may vary.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Start year of the academic year (optional; defaults to current) | |
| school_type | No | both (default) or term |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does disclose the key limitation: results follow the majority-of-LA pattern, not any single authority, and scope is limited to England state schools. However, it does not describe the output shape, return values, or any side-effect profile, though this appears to be a read-only lookup.
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 focused sentence that front-loads the core resource and scope. The phrase 'with an explicit note that' is mildly redundant, but the sentence is otherwise efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple data-lookup tool, the description covers the main data scope and the most important limitation. However, with no output schema and no annotations, it would benefit from clarifying the return structure and the exact meanings of the school_type parameter values. It is 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?
Schema coverage is 100%, so the schema itself documents both parameters. The description adds the term names Autumn/Spring/Summer, which partially clarifies the 'term' value, but it does not explain what 'both' vs 'term' actually return under 'school_type'. The parameter description in the schema remains ambiguous.
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 and scope: England state-school term dates per academic year, broken into Autumn/Spring/Summer terms. The geographic qualifier immediately distinguishes it from au-school-terms and nz-school-terms, and the 'majority-of-LA pattern' adds important precision.
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 when to use the tool: for England state-school term dates on the common local-authority pattern. The caveat that individual local authorities may vary appropriately warns against using it for LA-specific queries. It does not explicitly name alternatives or exclusions, but no direct UK alternative appears among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
UK time zone and DST status across Europe/London (GMT +0 / BST +1). Computed from IANA at runtime.
| Name | Required | Description | Default |
|---|---|---|---|
| zone | No | Zone to return: Europe/London (default; only one for UK) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears the full disclosure burden. It states that the timezone is computed from IANA at runtime, implying a dynamic current result, and lists the two possible offsets (GMT+0 / BST+1) tied to DST status. It does not enumerate exact return fields, but for a simple read-only timezone lookup this is sufficiently 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 two short sentences with zero filler. The core resource and scope are front-loaded, and the runtime computation detail is placed in the second sentence without bloating the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description covers the essentials: what is returned (UK time zone and DST status) and how it is derived (IANA at runtime). It does not detail the output structure, but that is not a significant gap given the tool's simplicity and the complete parameter schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the single optional `zone` parameter, including its default and constraint. The description adds no parameter-specific meaning, which matches the baseline 3 when schema already carries the semantic 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 clearly names the resource: UK time zone and DST status, with Europe/London and GMT/BST offsets, which distinguishes it from sibling timezone tools like au-timezone and nz-timezone. It lacks an explicit verb such as 'get' or 'returns', but 'time zone and DST status' plus 'Computed from IANA at runtime' adequately conveys the 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?
The context is clear: this is the UK-specific timezone/DST tool, and the schema notes that Europe/London is the only zone. It does not explicitly name alternatives or when-not-to-use, but the sibling tool set and the 'UK' scope make the intended usage unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
UK unemployment rate, seasonally adjusted, 16+ (ONS LMS MGSX). Monthly.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | UK (default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It usefully states that the data is seasonally adjusted, covers ages 16+, is from the ONS series MGSX, and is monthly. However, it does not describe the return format, time range, or whether it returns a single value versus a time series, which leaves some behavioral ambiguity.
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 compact, front-loaded sentence that includes the key identifying facts: geographic scope, metric, adjustment type, age coverage, source series ID, and frequency. There is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup tool with no output schema, the description covers the essential data definition and monthly frequency, which is mostly sufficient for an agent to select and invoke it. It does not explicitly state the return value shape, but given the low complexity and the row schema coverage, this is a minor gap rather than a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'region' has 100% schema description coverage with 'UK (default),' so the schema already documents the parameter adequately. The description adds no further detail about how the region parameter behaves or what alternative values might be valid, but the baseline of 3 is appropriate given the high 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 resource as the seasonally adjusted UK unemployment rate for ages 16+ and includes the ONS series ID (MGSX), which distinguishes it from sibling tools like uk-vacancies or uk-cpi. However, it lacks an explicit verb such as 'returns' or 'provides,' so the action is only implied by the noun phrase and tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives enough context to infer that this tool should be used when UK unemployment-rate data is needed, and it is clearly a data lookup rather than an action. It does not explicitly state when not to use it or how it compares to related siblings like uk-earnings or uk-vacancies, so usage guidance is implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
UK job vacancies, thousands, total services, seasonally adjusted (ONS LMS JP9Z). Monthly.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | UK (default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose useful data attributes: seasonally adjusted, thousands, total services, and monthly frequency. However, it does not state what the response contains, how the region parameter behaves, or any assumptions/limitations, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with no wasted terms; the key identifiers are front-loaded. It sacrifices a bit of readability for brevity, but every phrase carries 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 simple one-parameter tool with no output schema, the description identifies the series and units but omits an explicit statement of what is returned and how region filtering works. It is minimally sufficient but leaves the agent needing to infer the operational contract.
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 parameter description 'UK (default)' is clear on its own. The tool description adds no extra meaning to the region parameter, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource (UK job vacancies), the units (thousands), the series (total services, seasonally adjusted, ONS LMS JP9Z), and frequency (monthly). It is specific enough to distinguish from uk-unemployment and au-vacancies, 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 choose this tool over alternatives like au-vacancies or uk-unemployment. The source code and metadata imply a UK labour-market series, but no exclusion criteria or selection conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest observation (temp, rain, wind) + 7-day forecast for UK cities via Open-Meteo. 1-day TTL.
| Name | Required | Description | Default |
|---|---|---|---|
| suburb | Yes | UK city name, e.g. "London", "Manchester", "Glasgow" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and does meaningful work: '1-day TTL' discloses cache freshness, 'via Open-Meteo' discloses data provenance, and the parenthetical enumerates return content. The read-only nature is self-evident from 'observation/forecast'. Minor gaps like error behavior for unknown city names remain, but the key behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver scope, data content, data source, and freshness with zero filler. Every element earns its place, and the content summary is front-loaded ahead of the TTL note.
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 and no annotations, the description compensates by summarizing the return payload (temp, rain, wind, 7-day forecast) and freshness behavior (1-day TTL). Small gaps — forecast granularity (daily vs hourly) and error handling for invalid place names — remain, but nothing blocks 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 100% — the suburb property already has a complete description ('UK city name, e.g. London, Manchester, Glasgow') — so the baseline 3 applies. The description's 'UK cities' phrase reinforces the schema constraint but adds no new parameter meaning beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource ('UK cities'), the exact data delivered ('latest observation (temp, rain, wind) + 7-day forecast'), and the data source (Open-Meteo). The 'UK' scope cleanly distinguishes it from the weather siblings au-weather and nz-weather, and no other uk-* sibling overlaps on weather.
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 'UK cities' qualifier provides clear, unambiguous geographic context that routes agents to this tool for UK weather queries and away from au-weather and nz-weather. It does not explicitly name alternatives or state when-not-to-use conditions, but the scope is explicit rather than merely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
ar-cpiar-demographicsar-postcode-lookupar-public-holidaysar-school-termsar-timezonear-unemploymentar-weatheruk-demographicsuk-house-pricesuk-incomeuk-crimeuk-weatheruk-cpiuk-earningsuk-unemploymentuk-vacanciesuk-postcode-lookupuk-public-holidaysuk-school-termsuk-timezonenz-weathernz-business-demographynz-household-expenditurenz-crimeau-abs-building-activityau-abs-building-approvalsau-abs-demographicsau-aweau-cash-rateau-cpiau-incomeau-nsw-hazardau-postcode-lookupau-property-crimeau-public-holidaysau-school-termsau-timezoneau-unemploymentau-vacanciesau-weatherget_cataloghealthlist_servicesnz-demographicsnz-incomenz-ocrnz-place-lookupnz-public-holidaysnz-school-termsnz-timezoneClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Every tool maps to a clearly distinct dataset or lookup, with country prefixes and topic names separating overlapping domains. Even similar tools like au-abs-building-activity and au-abs-building-approvals are unambiguously differentiated by their descriptions.
The data tools follow a consistent country/topic hyphenated pattern (au-*, nz-*), making resource selection predictable. The meta tools (get_catalog, list_services, health) break this pattern with imperative/underscore names, but this is a minor and understandable deviation.
At 26 tools, the set is on the heavy side and slightly exceeds the typical comfortable range. However, each tool represents a genuinely distinct data service, and the clear grouping by country and topic keeps the surface navigable.
The server covers a broad range of common agent data needs for Australia and New Zealand: demographics, income, building, labour, weather, time, holidays, school terms, and place resolution. Minor gaps exist, such as no NZ building data or broader international coverage, but core workflows are well supported.