Australian Bureau of Statistics
Server Quality Checklist
Latest release: v0.13.2
- Disambiguation5/5
Each tool has a clearly distinct purpose: describe for metadata, get_data for historical data, latest for current, list_curated for curated IDs, release_calendar for schedule, search for discovery, top_n for ranking. No overlap in functionality.
Naming Consistency4/5Most tool names follow a verb_noun pattern (describe_dataset, search_datasets, list_curated), but get_data, top_n, and release_calendar use different forms. However, all are snake_case and descriptive, making them predictable.
Tool Count5/5Seven tools cover the essential operations for a statistics bureau server: metadata discovery, data retrieval, listing curated sources, release schedule, and search. The scope is neither too broad nor too narrow.
Completeness5/5The tool set covers querying, latest values, ranking, metadata description, search, and release calendar. For a read-only statistical data portal, this is comprehensive; no obvious gaps for common workflows.
Average 4.7/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
This server has been verified by its author.
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
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains behavior: fuzzy matching, boosted curated dataflows, relevance ranking, and return type. Minor omission: does not clarify if authentication or side effects exist, but that's acceptable for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose first, then usage, examples, when-to-use, returns. It is front-loaded and each sentence adds value. A minor redundancy exists between the first 'Use this when...' and the 'When to use' list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool simplicity (2 params) and the presence of an output schema, the description covers all needed aspects: functionality, usage context, behavioral details, examples, and return type. It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the +25 score bonus for curated dataflows and providing examples, exceeding what the schema alone offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fuzzy-search ABS dataflow names, descriptions, and keywords.' It specifies the verb (fuzzy-search) and resources (dataflow names, descriptions, keywords), and differentiates from sibling tools like describe_dataset and get_data by noting it's for when you don't know the exact ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when you don't know the exact dataset ID' and provides a list of when-to-use scenarios. However, it does not explicitly say when not to use it or contrast with specific sibling tools like list_curated.
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 covers key behaviors: curated vs. raw paths, case-insensitivity, and whitespace trimming. It lacks discussion of side effects or authorization, but as a metadata-read operation, these are implicitly safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, examples, and bullet points, making it easy to scan. While slightly verbose, it remains clear and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's single parameter and the presence of an output schema, the description comprehensively covers behavior, return shape, and usage scenarios. It is complete for an effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, yet the description adds significant value: it explains case-insensitivity, trimming, and how to discover valid IDs via search_datasets or list_curated. Examples reinforce correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: describing an ABS dataflow's filter dimensions, value codes, and source. It distinguishes between curated and raw dataflows, providing specific examples (LF, CPI, etc.) and contrasting with sibling tools like get_data and search_datasets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool, e.g., before calling get_data on an unfamiliar dataflow or to get the source URL. It does not provide explicit 'when not to use' guidance or direct comparisons to alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior. It states the output is a sorted list of exactly 10 dataflow IDs, and provides the specific IDs. It also notes this is consistent ('Always 10 entries today'). This is sufficient transparency for a read-only list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, bulleted list of dataflows, example, usage scenarios, and return description. Every sentence adds value, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (list with no parameters) and no annotations, the description fully covers what an agent needs: purpose, which dataflows, example output, and when to use. No gaps were identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (empty schema). The description does not need to add parameter details. It provides relevant context about the fixed list without wasting space. This exceeds the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool lists the 10 curated ABS dataflow IDs with plain-English support. It distinguishes itself from siblings like get_data (raw SDMX) and describe_dataset (metadata). Specific verb 'list' and resource 'curated dataflows' clearly define purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'When to use' section with three clear scenarios (e.g., knowing which dataflows have plain-English support, enumerating capabilities). While it does not explicitly state when not to use, the context of sibling tools and the description implying other dataflows use get_data with raw codes provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully covers behavioral aspects: it uses lastNObservations=1, ranks only the most-recent period, performs server-side ranking, and returns a DataResponse. This provides complete transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with sections for purpose, usage rationale, examples, and return format. Every sentence adds value, and it is appropriately concise without omitting necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately explains the return shape (DataResponse with at most n records, sorted) and mentions other fields. It covers all relevant aspects for a ranking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description enhances understanding with examples, clarifies the 'direction' parameter, and warns not to include 'measure' in filters, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's function: returning top or bottom N rows by a measure. It distinguishes from siblings like get_data by highlighting server-side ranking and efficiency, and provides concrete examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use ('most common agent workflow') and contrasts with get_data to avoid wasteful local sorting. While it lacks explicit 'when not to use' statements, the context and alternatives are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description details cache TTL (15 min vs 1 hour for get_data), performance metrics (p50 ~22ms warm), and warns about many observations without filters. Full disclosure of behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for description, technical details, examples, usage guidance, and returns. Front-loaded with purpose. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema present (not shown), so return explanation not needed. Covers limitations, performance, and use cases. Examples cover multiple domains. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds context beyond schema: explains that filters must narrow results (e.g., 'pass at least region + measure') and provides rich examples. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Return the most recent observation(s) for a dataflow' and distinguishes it from siblings like get_data (wraps with lastNObservations=1) and top_n. Examples further clarify its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a dedicated 'When to use' section listing scenarios (current value, performance) and implies alternatives (get_data for more observations). Clear guidance on when to apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral disclosure. It details timezone handling with Sydney offset and DST naivety, caching behavior with stale flag, mapping to dataset_id for curated datasets, and output shape. No hidden traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose first, then details, examples, when-to-use, and return format. Every sentence adds value; no fluff. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (scraping, timezone, caching, mappings) and the presence of an output schema, the description covers all necessary context: source, fields, behavior edge cases, and integration with sibling tools. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter `days_ahead` has full schema coverage (100%) with description, default, range, and examples. The description adds context about the horizon covering 'typical monthly + quarterly cadence', which enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the upcoming ABS publication schedule, names the source URL, and describes the returned fields. It distinguishes itself from sibling tools by focusing on the release calendar, not data retrieval or searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The dedicated 'When to use' section explicitly lists scenarios: building webhooks, agent answers for 'What's next?', and cache pre-warming. It also notes portfolio interop with rba-mcp, providing clear context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description comprehensively covers behavioral traits: plain-English filter translation, response format options, large data warning, return structure details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with sections, examples, and a concise returns list. No wasted words despite being thorough.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description covers all necessary context: parameters, usage, return fields, and boundary conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds substantial value: explains filter semantics, period format, dataset_id discovery, and format differences.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Cleary states it queries ABS dataflows and returns observations, with detailed examples and distinction from sibling tool 'latest'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (time range, multi-state/measure, CSV) and when not (use latest() for single record). Warns about unfiltered queries returning large data.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/abs-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server