ausdata-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.2
Disambiguation4/5
Most tools have clearly distinct purposes, especially the real_* series targeting different rates. However, releases and release_pulse overlap heavily, and cost_of_living vs regional_cost_of_living could cause confusion. Overall, the boundaries are fairly clear.
Naming Consistency3/5
There is a mix of verb_noun patterns (search_datasets, describe_dataset) and noun phrases (real_wages, economic_dashboard). While all names are readable and snake_case, the lack of a consistent verb_noun style across the whole set makes it feel inconsistent.
Tool Count2/5
With 28 tools, the set is too heavy. Many tools are narrow wrappers (e.g., real_cash_rate, real_mortgage_rate, real_savings_rate) that could be consolidated into a single parameterized tool. This exceeds the typical well-scoped range and feels bloated.
Completeness4/5
The server offers broad coverage of Australian economic and social data, including discovery (search, list, describe, get) and numerous snapshot tools. Minor gaps exist (e.g., national GDP, specific demographic datasets), but they are not critical for the apparent scope.
Average 4.3/5 across 28 of 28 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on May 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It explains the tool cross-sources RBA and ABS data and returns 5 indicators, but it does not state whether historical periods return exact matches, what happens on missing data, or any rate limits. It is not misleading but omits behavioral details that would enrich transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with no redundancy. The first sentence states the core purpose and examples, the second gives usage context, and the third adds cross-sourcing and efficiency value. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema and no output schema, the description is sufficiently complete for an aggregate snapshot tool. It states the exact indicators returned and the recommended use case. It does not describe the response structure, but that is less critical for a simple aggregate without nested objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, period, has full schema coverage (100%) with a description and examples for 'latest', 'YYYY-Qn', 'YYYY', and 'YYYY-MM'. The tool description adds no additional parameter-level information, so the baseline of 3 is appropriate—the schema covers the semantics accurately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('Get'), a specific resource (5 headline AU economic indicators), and lists them explicitly. It also distinguishes the tool from siblings by noting it replaces 5 separate sister-MCP calls, making it clear why this aggregated call is unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'Use this when an agent needs a macro economic snapshot.' It implies an alternative (making separate calls) but does not name specific sibling tools or provide when-not-to-use guidance. This meets the spirit of usage guidance but lacks formal exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must be transparent. It clarifies this is a live-data read operation from AEMO and lists the data fields returned. However, it doesn't mention potential latency, whether data is real-time or delayed, or any rate limits. It also leaves the behavior of the optional 'region' parameter to the schema, which is acceptable. Overall, adequate but with gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action, and each sentence adds value: what it returns, when to use it, and data source. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple snapshot tool with one optional parameter and no output schema, the description covers the essential aspects: purpose, usage, and data source. It lists the returned fields. It lacks explicit handling of the 'omit for all regions' behavior, but the schema covers that. The gap is minimal, so a 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter (region), including enums, examples, and a description. The tool description adds no new parameter semantics beyond reinforcing examples in the purpose. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a clear resource ('current AU NEM snapshot for a region'), and explicit scope (spot price, demand, renewable share, generation mix). It also provides example questions that make the purpose unmistakable. While it doesn't explicitly compare to sibling tools like nem_dispatch_5min, the focus on a 'current snapshot' is sufficiently distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directly states when to use it: 'Use this when an agent is asked...' with two concrete example questions. It does not mention alternatives or exclusions, but the clear usage context earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses data sources (ABS labour-force, national-accounts, residential-property indexes) and notes variability ('where state-level is published'), which adds useful context. However, it does not describe return format, error behavior, or any rate limits, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the tool's purpose and key metrics, and every sentence provides actionable information. It is concise without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 behaviors: what metrics are returned, the geographic scope, data sources, and usage instructions. Minor omissions (e.g., caveats about data availability for smaller territories) prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — the state parameter is fully described with enum values, examples, and a note on omission. The description reinforces this ('Pass a state code... omit for all') but does not add significant new meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Returns' and specifies the resource: an AU state-level macroeconomic snapshot covering five distinct metrics (unemployment rate, state final demand growth, dwelling-price change, CPI, population growth). It also scopes the tool to a state or all jurisdictions, making it easy to distinguish from sibling tools like economic_dashboard or state_fiscal_snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'Single call answers how is <state> tracking economically?' and explains how to use the state parameter ('Pass a state code to focus on one jurisdiction; omit for all eight states/territories'). However, it does not explicitly contrast with alternative tools or state 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.
Behavior3/5
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 return fields (nominal wage growth, CPI annual change, computed gap) and the quarterly frequency, but omits other behavioral details such as data source freshness, units, or an explicit statement that this is a read-only operation. This is adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and followed by useful context and an example. Every sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, optional-parameter tool with no output schema, the description covers the essential aspects: purpose, computation method, return fields, and an example range. It does not clarify behavior when start is omitted, but the schema and example provide enough context for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add parameter-level semantics beyond what the schema already provides, though the example usage is helpful. It neither enhances nor detracts from the schema's parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Get Australian real wages time series (Wage Price Index minus CPI).' It distinguishes itself from sibling tools like real_cash_rate and real_savings_rate by focusing on wage-specific data and its computation method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with the 'Greg Jericho chart' reference and a practical example range (2019-Q1 to 2024-Q4) for observing post-pandemic real wages collapse. However, it does not explicitly mention when not to use this tool or name alternatives, stopping short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It notes that it cross-sources ABS and RBA calendars, which is a behavioral trait. However, it does not mention any quirks like rate limits, pagination, or how missing data is handled. This is adequate for a read-only calendar tool, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: stating the main functionality, providing when-to-use examples, and noting the cross-source nature. No redundant or vague wording; it is compact and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (optional parameters, no output schema), the description is nearly complete. It explains the purpose, usage scenarios, and data sources. The only missing piece is an explicit description of the return format or structure, but since no output schema exists, the description could be slightly more detailed about what an event entry looks like. Still, it's adequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all four parameters, so the description adds minimal extra value. It does indirectly mention 'next N days' which maps to 'days_ahead', but essentially the schema already handles parameter semantics. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Get the upcoming AU economic release calendar' with specific details on content: ABS publication dates, RBA board meeting dates, and other scheduled data releases. It distinguishes itself from siblings by focusing on release calendar events, not economic data values or analytics. The use-case examples further clarify its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides trigger scenarios: "Use this when an agent is asked 'when is the next CPI release?' or 'when is the RBA next deciding on rates?'". This gives clear guidance on when to invoke the tool. It lacks explicit exclusions or mention of alternative tools, but the specificity of the use cases compensates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden for safety and behavior. It discloses the return type (matched datasets with IDs, sources, example queries) and provides natural-language examples, but it does not mention potential limitations (e.g., returns only catalog metadata, not data values), ordering, or any side effects. This is adequate but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a terse example list. It leads with the main verb and object, immediately states the return payload, and gives usage guidance. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward search tool, the description covers purpose, return value, and use case. There is no output schema, but the description tells the agent what to expect. It could be slightly more complete by noting the effect of the 'limit' parameter or the fact that it searches catalog metadata only, but the provided context is sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions for both 'q' and 'limit' are fully self-explanatory with examples, types, defaults, and constraints. Since schema coverage is 100%, the description adds no additional parameter-level semantics beyond reiterating examples, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' plus the specific resource 'catalog of curated Australian government datasets'. It distinguishes itself from sibling tools by focusing on searching when the dataset_id is unknown, and it mentions the return content (IDs, sources, example queries), making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the primary usage scenario: 'Use this when you don't know the exact dataset_id'. This is clear practical guidance, though it does not explicitly name alternative tools (e.g., list_datasets) or provide direct when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does indicate the tool is a read-only 'Returns' operation and lists data sources (ATO/ACNC), but it omits potential caveats like data freshness, update frequency, or any limitations on the aggregates. The 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, with the core purpose stated in the first sentence and supporting details (data points, sources, use cases) following. Every sentence earns its place; there is no fluff or repetition of schema information. The structure is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no annotations, and no output schema, the description must explain what the tool returns. It does a good job listing the key data points and the overall purpose, but it does not describe the shape of the response (e.g., JSON structure, units, formatting). For a zero-parameter read-only tool, this is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this with an empty object. Since there are no parameters to describe, the description does not need to add parameter-level semantics; the baseline of 4 applies. The description does not mention the absence of parameters, but that is unnecessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Returns') and a clear resource ('AU charity sector health snapshot'), followed by a list of the aggregates returned (total active charities, revenue, donations, employment, deltas). This makes the tool's function unambiguous and distinguishes it from sibling tools like 'health' or 'sectoral_employment_shift' which focus on different domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a clear use case: 'Single call answers how is the AU not-for-profit sector tracking?' and identifies target audiences (philanthropy, NFP-policy, grant-funder). While it provides strong context for when to use the tool, it does not explicitly mention any exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It clearly discloses the return content (SLCI for five household types and CPI) and indicates a read-only snapshot behavior. It does not mention data frequency or format, but for a no-parameter retrieval this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the action, second details the return payload and gives a usage example. No fluff, front-loaded, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description fully covers purpose, data content, and a practical use case. The only minor gap is explicit sibling differentiation, but that is not critical for a simple snapshot tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to document. The baseline of 4 applies, and the description correctly implies no input is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves an AU cost-of-living snapshot with specific data (ABS SLCI for five household types plus headline CPI). It does not explicitly differentiate from sibling tools like regional_cost_of_living, but the national scope and household-type focus are implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence gives an explicit trigger scenario ('Use this when an agent is asked how much are living costs rising for retirees vs workers?'), which is clear usage guidance. It does not mention when not to use or name alternatives, so it does not reach the level of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the cross-source nature (WGEA + ABS) and that it's a retrieval operation ('Get'), but it doesn't describe output structure, error behavior, or any limitations. There's no contradiction, but the description is not rich in behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (four short sentences) and front-loaded with the main action. Every sentence adds value: the action, the data sources, the use case, and a reminder of the cross-source nature. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides a reasonable high-level picture of what the tool returns (gender pay gap and labour-force composition). It could be more explicit about the response format, but for a simple tool with one optional parameter, it 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the industry parameter already documented in detail (accepts name, ANZSIC letter, or code; omit for national). The description adds context by linking the parameter to the reported use case but doesn't significantly extend 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the AU gender pay gap with industry context in one call.' It specifies the data sources (WGEA + ABS) and the resource (gender pay gap by industry), distinguishing it from sibling tools like real_wages or get_data by its focused scope and combined data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use this when an agent is asked what's the pay gap in <industry>?' or comparing AU industries on gender equity.' This is clear context for selection, though it doesn't name alternatives, it gives unambiguous triggers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden. It reveals two input forms (dotted vs split), period format conventions, and an example, but it omits details on response format, error handling, or explicit read-only confirmation. The disclosure is useful but not comprehensive for a mutation-capable-looking accessor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences plus one example: opens with the purpose, then gives usage guidance, then period formats and an example. Every sentence earns its place without redundancy or fluff, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, a nested filters object, no output schema, and no annotations, the description provides essential guidance for constructing a query, including input forms and period formats. It does not explain return format or error behavior, but for a generic accessor with a straightforward filter-and-period interface, it is reasonably complete for a first successful call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all 6 parameters with descriptions and examples (100% coverage), so baseline is 3. The description adds value by explaining the relationship between dataset_id and source (dotted vs split), period format rules depending on dataset, and a concrete usage pattern with filters, going beyond schema repetition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generic accessor for any curated Australian government dataset', using a specific function (accessor) and resource. It explicitly references search_datasets for discovery and distinguishes itself from specialized sibling tools by being generic and dataset-agnostic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit sequencing: 'Use search_datasets first to find the dataset_id, then call this with filters.' This gives clear context on when to use the tool. However, it does not explicitly name alternatives or state when to prefer specialized tools over this generic accessor, leaving a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It does list the data fields returned and sources, which is helpful. However, it does not disclose whether the snapshot is current-only or historical, national or regional, or its update frequency. These are important for an agent interpreting the answer to the comparison question, so the description only partially fulfills the transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with the primary action in the first sentence. Every sentence adds relevant information: the output components, the use case trigger, and the data sources. There is no fluff or redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool, the description is complete in listing what the snapshot contains and when to use it. It lacks an explicit statement about return format or regional granularity, but the output schema is absent and the description provides a clear list of metrics. This is adequate for a straightforward read-only snapshot, though a mention of historical comparability would elevate it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so the baseline score is 4. The description does not need to explain parameters that do not exist. It adds value by describing the output metrics, which compensates for the lack of schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function with the verb 'Get' and a specific resource: 'AU housing affordability snapshot.' It enumerates the key output components (median dwelling price, household income, price-to-income ratio, mortgage serviceability, rent burden), which distinguishes it from general economic or housing-related sibling tools. The mention of 'Cross-sources ABS + RBA' further clarifies its scope and source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit trigger: 'Use this when an agent is asked "is Australian housing more unaffordable than it was?".' This gives clear guidance on when to invoke the tool. It does not mention alternatives or when not to use it, but given the context, this is sufficient and better than many tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the data content, source (ABS GFS), and parameter behavior (omit for all eight jurisdictions). It does not describe return format or potential limitations, but for a read-only data query, it is adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding value: what it returns, usage examples, and parameter guidance. No redundant phrases or unnecessary detail. The main action is front-loaded with 'Returns'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must convey what the agent will get. It lists the key data points and source, and explains the parameter scope. It could specify whether data is annual or quarterly, but for a snapshot tool the listed metrics are sufficient for an agent to understand the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description already fully explains the state parameter including the enum values and the omission behavior, achieving 100% schema coverage. The tool description reinforces this but adds no additional meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an AU state/territory fiscal snapshot with specific metrics (revenue, expenses, net operating balance, net debt). It provides example questions ('what's the fiscal position of <state>?') that distinguish it from broader tools like macro_snapshot_state. The verb 'Returns' and specific resource make the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage scenarios: single-call answers about fiscal position or largest deficit, and explains how to use the state parameter (pass one state or omit for all). It does not explicitly mention alternatives or when-not-to-use, but the context is clear enough for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the data source (APRA), aggregation level (by parent group), frequency (Monthly), and output contents (deposit totals, market-share percentages, Big Four share). This adds meaningful context beyond a simple 'returns data' statement, though it could mention data freshness or caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the primary purpose. The phrase 'Sources APRA' is redundant with the first sentence's mention of APRA, introducing minor waste, but overall it is concise and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema tool, the description is largely complete: it explains what data is returned, the source, and use cases. It omits details like the exact time period of the snapshot or the calculation of top-N concentration, but these are minor for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so the baseline is 4. The description reinforces the no-parameter nature with 'Single call' and explains the output, but there is no parameter-specific detail to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Returns') and identifies the exact resource: the AU bank-deposit market-share snapshot from APRA Monthly ADI statistics aggregated by parent group. It distinguishes itself from sibling tools by focusing on a specific domain (bank deposits) and answering a specific question ('who holds the deposits in Australia right now?').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage, stating it is 'useful for banking-competition and concentration-risk analysis.' However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a 5 but is still well above minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 source (ABS CPI), what is returned (top contributors ranked by contribution, YoY growth per group), and the metric (percentage points). It does not mention data freshness or output format, but for a read-only data retrieval tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, front-loading the core purpose and then adding usage context, source, and output details. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description covers the essential context: what it returns, the source, and its use. It leaves some ambiguity about exact output shape (e.g., whether all groups or only top N), but the description is strong enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. The description adds no parameter details because none are needed; it focuses on output semantics instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and clearly identifies the resource ('AU CPI inflation decomposition') with detailed scope: headline CPI broken down by ABS expenditure group plus contribution-to-total-inflation in percentage points. This distinguishes it from sibling tools like cost_of_living by focusing on decomposition and ranked contributors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the exact question the tool answers ('what is actually driving inflation right now?') and names use cases (monetary-policy commentary, household-impact analysis). However, it does not explicitly state when not to use it or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden. It explains the data source ('Sources AEMO live dispatch'), scope ('for a region (or all regions)'), and cadence (5-minute intervals). However, it does not mention potential latency, default result limits, or any operational caveats beyond what the schema already states, leaving a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, then use cases, then differentiation. Every sentence contributes value—no fluff or repetition. The structure is logical and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists key data fields (spot price, demand, generation by fuel type) which gives a sense of return content. It also provides use-case context and sibling comparison. It doesn't describe the exact response format (e.g., time series rows), but for a 2-param data retrieval tool, the context is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both 'limit' and 'region' are well-described in the input schema). The description adds no new parameter-specific details beyond confirming region can be omitted for all regions, which aligns with the schema. Baseline 3 is appropriate since the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns the AEMO 5-minute NEM dispatch series' and specifies the data types included (spot price, scheduled demand, dispatched generation by fuel/technology). It distinguishes itself from sibling 'energy_snapshot' by noting its higher cadence, making it easy to identify the correct tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use cases are provided: 'what's been happening in the NEM over the last hour?' and 'show me the dispatch curve in QLD today'. It also names the alternative tool 'energy_snapshot' and explains the difference, giving clear when-to-use vs when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It reveals the output is a high-signal summary ranked by market-moving importance and grouped by week. It does not detail response format or potential side effects, but read-only nature is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first defines, second gives usage triggers, third contrasts with sibling. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one optional param and no output schema. Description fully explains purpose, usage, and differentiation. Could mention return format, but 'high-signal summary' reasonably implies a structured digest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the single optional parameter with description, range, examples, and default behavior. Description adds no additional parameter semantics, so baseline 3 applies due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Returns' and resource 'AU data-release pulse' with clear scope (economic release calendar across ABS, RBA, APRA, AEMO). It explicitly distinguishes from sibling `releases` by noting it ranks by impact and groups by week, making it unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly names use cases: when asked 'what data drops this week?' or 'when's the next big print?'. It also provides differentiation from `releases` (raw calendar), serving as an alternative guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full transparency burden. It fully discloses what the tool returns (schema details, accepted filter keys/values) and implies read-only behavior. It does not mention potential errors or limits, but for a metadata lookup the behavioral disclosure is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose and followed by a precise usage cue. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single parameter, no output schema, and a clear sibling context, the description covers what the tool does, when to use it, and what the response contains. It is fully self-contained for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents dataset_id with examples and cross-reference to search_datasets. The description adds no parameter-specific semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Returns the schema') and resource ('curated Australian government dataset'), enumerating the content (dimensions, valid values, units, frequency, source URL). It also distinguishes itself from siblings by referencing get_data error handling, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-to-use condition: 'Use this when get_data returns an Unknown filter or Unknown value error'. This is clear, actionable guidance that ties the tool to a concrete scenario and differentiates it from other data tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explains the action (checking reachability and API key), the return payload, and the typical use case. While it doesn't explicitly mention network calls or side effects, the read-only nature is strongly implied and the description is transparent enough for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every clause provides value. It avoids unnecessary detail while covering purpose, use case, and return values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description fully explains what it does and what the agent will receive. It also contextualizes when it's appropriate to invoke. There are no missing elements for an agent to correctly select and call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which sets a baseline of 4 per the rubric. The description adds no parameter details, but none are needed; the schema is already fully covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' with a specific resource ('ausdata.io API'), and specifies exactly what is checked (reachability, API key validity). It also indicates the return values (server status, API version, remaining quota). This distinguishes it from sibling data-retrieval tools, as it's a system health check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful for debugging MCP connection issues' explicitly tells the agent when to use this tool. It provides clear context without naming alternatives, which is appropriate given that no sibling tool serves a similar purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 clearly conveys the tool's scope and examples, but does not explicitly state the return format or pagination behavior. However, for a straightforward list operation the behavior is largely self-evident, so this is a minor gap rather than a critical omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core action, and every phrase serves a purpose. It is concise yet packed with useful guidance and sibling references.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single parameter, no output schema), the description fully covers what a user needs to know: what it does, when to use it, and how it fits with other tools. The absence of an output schema is mitigated by the clear implication that the tool returns a list of datasets for further action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter is fully described with an enum and examples. The tool description adds only marginal context (e.g., 'all ABS datasets') without introducing new parameter semantics, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('enumerate') and resource ('every curated dataset a source exposes'), making the tool's function unmistakable. It also distinguishes itself from siblings by explicitly naming search_datasets, describe_dataset, and get_data as alternatives for different tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('for surveying what's available before picking one to describe or fetch') and contrasts it with sibling tools ('Pairs with search_datasets (free-text discovery), describe_dataset (schema), and get_data (fetch)'). This gives clear guidance on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses data sources (RBA + ABS), the calculation logic, and the output fields (nominal rate, CPI change, real rate, stance flag). It does not mention limitations like data update frequency or error handling, but for a simple retrieval tool 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a distinct purpose: what it returns, the use case, and the return fields. Front-loaded with the main function, no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 and no annotations, the description is complete. It explains what it computes, the data sources, the return values, and when to use it. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so a baseline of 4 applies. The description correctly implies no inputs are needed, and there is no parameter information required beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Returns') and resource ('real (inflation-adjusted) cash rate'), and distinguishes from siblings by stating the formula (RBA cash rate minus ABS CPI annual change) and the policy question it answers. This is clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context with 'Single call answers 'is monetary policy restrictive?'', which tells an agent when to use it. However, it does not explicitly name alternatives or exclusion criteria, such as suggesting real_mortgage_rate for mortgage-specific rates. This is a clear context but with no exclusions, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of transparency. It discloses cross-sourcing from RBA F-tables and ABS, explains the computation, and details the output fields including the borrower-stance flag. While it doesn't address rate limits or error behaviors, the read-only nature is evident from the 'returns' framing. This adds meaningful context beyond the bare schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each densely informative: purpose, use case, data sources, and output fields. There is no fluff or redundancy. It is front-loaded with the primary action, making it easy to parse. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is complete. It thoroughly covers what the tool does, why to use it, the underlying data sources, and the return values. An agent can confidently invoke it without additional clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. The description doesn't need to explain parameter semantics since there are none, but it does add context about the output structure, which is ancillary. It fully compensates for the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Returns the current real (inflation-adjusted) standard variable mortgage rate' with a specific verb and resource. It distinguishes from siblings like real_cash_rate by explicitly targeting mortgage rates. The methodology (RBA minus ABS CPI) is also specified, leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Single call answers 'are mortgage holders paying a real cost above inflation?''. It effectively conveys when to use this tool, though it doesn't explicitly mention alternatives or when not to use it. This places it above 'implied usage' but below the explicit alternative naming seen in top-tier examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently discloses the data sources (RBA + ABS), the computation (subtracting CPI), and the output fields, including the saver-stance flag. While it omits potential caveats like data frequency or revision policies, the description is substantially transparent for a zero-parameter data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the primary purpose and formula, then a use-case question, and finally output details. Every sentence adds value with no filler or redundancy, achieving high information density in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
In the absence of an output schema, the description fully explains the return values: nominal savings rate, CPI annual change, computed real rate, and flag. It also mentions the cross-sourcing of data, making the tool self-sufficient and complete for a zero-parameter function with no structured output metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4 per the rubric. The description goes beyond the schema by explaining what the tool returns and how the calculation is performed, but since there are no parameters, there is little parameter-specific meaning to add. The baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Returns the current real (inflation-adjusted) bank term-deposit / savings rate' and specifies the exact formula (RBA retail deposit rate minus ABS CPI annual change). It distinguishes itself from siblings like real_cash_rate and real_wages by explicitly focusing on the savings/deposit rate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Single call answers "are savers being compensated for inflation?"' This gives strong contextual guidance on when to use the tool. However, it does not explicitly mention alternatives or when not to use it, which would merit a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 transparently discloses the output components (per-industry deltas, share, sorted ranking), the calculation method (year-on-year change), and the data source (ABS Labour Force Detailed). It does not mention potential caveats like data revisions, but for a read-only data retrieval 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and front-loaded with the main function. Every sentence adds value: scope, use case, output details, and source. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool without an output schema, the description is complete: it explains what the tool returns (deltas, shares, ranking), why it's useful (narrative, career-pivot), and the underlying source. No further context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema is empty. The description adds no parameter-specific instructions, but with no params to explain the baseline of 4 is appropriate; it still indicates the call is self-contained ('Single call...') and describes the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies the tool's purpose with a specific verb+resource: 'Returns the AU sectoral employment shift — year-on-year change in employed persons by ANZSIC industry division.' It also provides a clarifying question it answers ('which industries are hiring and which are shedding?'), distinguishing it from sibling data tools like real_wages or health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Single call answers...' and notes it's 'Useful for labour-market narrative and career-pivot queries.' However, it does not explicitly mention alternatives or scenarios when not to use the tool, so it doesn't fully meet the 'when-not' criterion for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It explains the calculation (net of fees minus CPI), cross-sourcing from APRA and ABS, and the specific outputs (nominal return, CPI change, real return, stance flag). This is transparent for a zero-parameter tool, though it could mention caveats like data vintage or rounding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main verb and resource. Every sentence adds value: definition, typical use case, and output details. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description fully compensates by listing all return fields (nominal return, CPI annual change, real return, stance flag) and the data sources. The tool is simple (zero params) and the description is sufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The schema coverage is 100% (vacuously) and the description correctly focuses on outputs instead. It does not need to explain parameter meanings because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Returns the average AU superannuation fund real return' with a specific formula (APRA fund-level performance net of fees minus ABS CPI annual change). It distinguishes itself from sibling tools by focusing on superannuation versus other economic indicators, and it frames the answer to a specific question: 'is super outpacing inflation right now?'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('Useful for retirement-planning queries') and frames when to use it via the question 'is super outpacing inflation right now?'. However, it does not explicitly mention alternatives or scenarios when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 return fields (nominal wage growth, rent growth, gap, direction flag) and explains the meaning of negative values. Though it omits data update frequency or caveats, the behavior is well-specified for a simple comparison tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and followed by output details and use case. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema), and the description fully covers its behavior, outputs, and interpretation. The return fields are enumerated, and the narrative context is provided, making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds semantic value by explaining what the tool computes and the meaning of the outputs, fully compensating for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares ABS Wage Price Index annual growth against ABS rents-component CPI annual growth, with the explicit question 'are rents outpacing wages?'. It identifies the specific data sources and the comparative nature, distinguishing it from sibling tools like real_wages or housing_affordability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear use case ('useful for affordability narrative') and explains how to interpret the result ('when negative, real housing-cost pressure is mounting'). While it doesn't explicitly name alternatives, the 'single call' phrasing implies it replaces multiple lookups, offering context for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the responsibility for behavioral disclosure. It reveals the data source (ABS CPI by capital city) and the output structure (city-by-city annual CPI deltas and a ranked comparison), which is more than a vague 'gives cost of living'. It stops short of describing limitations like update frequency or methodology caveats, so a 4 is appropriate rather than a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a tight three-sentence structure: purpose, usage examples, and source/output. Every sentence contributes meaning, with no fluff or repetition. Front-loading the verb and object makes scanning easy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 is quite complete: it states what is returned, gives use cases, and names the data source. It does not explain the weighting methodology or list the exact eight capitals, but the core purpose is fully covered. A 4 reflects that it is nearly complete without being exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema offers no semantics. The baseline for 0 parameters is 4, and the description adds value by explaining what the returned output will be, effectively compensating for the absence of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Get') and a clearly defined resource ('AU regional cost-of-living comparison'). It elaborates with concrete content (per-capital-city CPI changes, weighted-eight-capitals average) and example questions, making it distinct from the sibling 'cost_of_living' tool which likely covers a national or less granular view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when an agent is asked...' and provides two representative queries ('is the cost of living rising faster in Brisbane than Sydney?', 'which capital city has the worst inflation?'). This gives direct, actionable guidance for when to invoke the tool over other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 clearly discloses that the tool returns the trade balance, top partners, and a trend, and cites the data source. However, it does not mention potential caveats like seasonality, data latency, or the exact response format, but for a simple read-only data retrieval, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: the first states the core purpose, the second provides usage context, and the third cites the data source. It is front-loaded with the main action and is free of unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides a complete picture: it explains the primary output (trade balance with partners and trend) and when to use it. The example queries and source citation add sufficient context for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% schema description coverage, so there is nothing to explain in the description. Per the rubric, a baseline of 4 is appropriate for a zero-parameter tool, and the description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with a clearly defined resource ('current AU trade balance') and explicitly states the components (exports minus imports, top partners, surplus/deficit trend). This makes the tool's function unambiguous and distinguishes it from sibling tools like economic_dashboard or macro_snapshot_state that cover broader economic indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance by giving concrete example questions ('is Australia running a trade surplus?', 'who are Australia's biggest trade partners?'). This helps an agent select the tool versus alternatives, and the mention of the ABS source implies it is specifically for current trade statistics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 clearly states what the tool returns (rate, gap, trend) and cites the source (ABS Labour Force), implying a read-only data retrieval. However, it doesn't specify units (e.g., percentage points) or whether the rate is seasonally adjusted, leaving minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main payload, and every word contributes. It avoids unnecessary detail while providing both what and when. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, single-value tool, the description fully covers the essential information: what the tool returns, the context for using it, and the data source. No output schema exists, but the description sufficiently conveys expectations for a simple indicator.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty. The description doesn't need to explain any parameter semantics; it's clear that no arguments are required. Baseline 4 is appropriate as there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource: the current AU youth (15-24) unemployment rate compared to the overall rate, including the gap and trend. This distinguishes it from sibling tools like real_wages or gender_pay_context, which target other indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence explicitly states when to use this tool: when asked 'how bad is youth unemployment in Australia?' or when comparing youth labour market conditions to the broader workforce. This is clear usage guidance with concrete trigger phrases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ausdata-mcp-client MCP server](https://glama.ai/mcp/servers/Bigred97/ausdata-mcp-client/badges/card.svg)](https://glama.ai/mcp/servers/Bigred97/ausdata-mcp-client)

Score Badge

Copy to your README.md:

[![ausdata-mcp-client MCP server](https://glama.ai/mcp/servers/Bigred97/ausdata-mcp-client/badges/score.svg)](https://glama.ai/mcp/servers/Bigred97/ausdata-mcp-client)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Bigred97/ausdata-mcp-client'

If you have feedback or need assistance with the MCP directory API, please join our Discord server