Skip to main content
Glama
Bigred97

Australian Bureau of Statistics

by Bigred97
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

abs-mcp

mcp-name: io.ausdata/abs-mcp

PyPI Python License Tests CodeQL Glama MCP server quality

Ask Claude about the Australian economy and get real, current numbers — not "I don't have access to that data." This MCP server gives Claude (and other MCP clients like Cursor) live access to the ABS Data API, with curated mappings for the 10 most-asked Australian economic indicators.

Hosted access? For cross-source queries, webhooks, an always-on REST API, and a uniform response envelope across all 9 sources, see ausdata.io — free tier available (500 calls/mo, no card).

abs-mcp answering "What's the unemployment rate in NSW?" in Claude Desktop

Behind the scenes it wraps SDMX 2.1, but you never see SDMX codes — just plain-English filters like region: "nsw" and measure: "unemployment_rate". Five tools, ten curated dataflows (Labour Force, CPI, Wage Price Index, Job Vacancies, Average Weekly Earnings, GDP / National Accounts, quarterly + annual Estimated Resident Population, Building Approvals, Lending Indicators), and 1,200+ other ABS dataflows accessible via raw codes.

Companion to rba-mcp (Reserve Bank of Australia — cash rate, FX, lending rates), ato-mcp (Australian Taxation Office — postcode-level personal tax, company tax by industry, corporate tax transparency, ACNC charity register), and au-weather-mcp (Australian weather — 21 curated locations + postcode/place-name lookup, current observations, 16-day forecasts, 80yr historical archive). Install all four for the full AU macro / regulator / tax / climate stack.

What you can ask

Once installed, your LLM can answer questions like:

Question

Real response (verified)

What's the unemployment rate in NSW?

4.27% (Mar 2026)

AU annual CPI inflation?

4.60% (Mar 2026)

AU annual wage growth?

3.40% (Q4 2025)

Average weekly earnings in Australia?

$1,562 (Sep–Oct 2025)

AU GDP quarterly growth?

0.80% (Q4 2025)

AU GDP per capita?

$24,900/qtr (Q4 2025)

Job vacancies in NSW?

101,200 (Q1 2026)

Dwelling approvals in NSW?

4,400/month (Mar 2026)

New NSW housing loan commitments?

$19.7B (Q4 2025)

Quarterly population of Australia?

27.7M (Q3 2025)

Every answer comes with the period, units, and a link back to the ABS source page. Comparisons and time-series queries work just as well — see Worked examples below.

Related MCP server: FRED Macroeconomic Data MCP Server

Install

# After publish:
uvx --upgrade abs-mcp

# Local dev install:
uv pip install -e .

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "abs": {
      "command": "uvx",
      "args": ["--upgrade", "abs-mcp"]
    }
  }
}

Why --upgrade? uvx abs-mcp (without the flag) uses whatever wheel is cached and never adopts new PyPI releases on its own — Claude Desktop's MCP child process keeps running the same wheel until you fully quit the app and refresh the cache by hand. --upgrade makes uvx check PyPI on each launch and pull a newer release if one exists. To verify which version is currently serving you, look at the server_version field on any DataResponse (added in 0.2.10).

For a local checkout (before PyPI publish):

{
  "mcpServers": {
    "abs": {
      "command": "uv",
      "args": ["run", "--directory", "/absolute/path/to/abs-mcp", "abs-mcp"]
    }
  }
}

Restart Claude Desktop. The abs server appears in the tools panel with five tools.

Cursor

Add to ~/.cursor/mcp.json (or workspace .cursor/mcp.json):

{
  "mcpServers": {
    "abs": {
      "command": "uvx",
      "args": ["--upgrade", "abs-mcp"]
    }
  }
}

Tools

Tool

What it does

search_datasets(query, limit=10)

Fuzzy-search ABS dataflow names. Returns the top matches.

describe_dataset(dataset_id)

Plain-English description of a dataflow's dimensions and values.

get_data(dataset_id, filters, start_period, end_period, format)

Query a dataflow with filters. Returns clean records (default), grouped series, or CSV.

latest(dataset_id, filters)

Just the most recent observation(s) — wraps get_data with lastNObservations=1.

top_n(dataset_id, measure, n=10, filters=None, direction="top")

Rank rows of a curated dataflow by a measure (e.g. unemployment_rate) at the most-recent period and return the top (or bottom) N.

list_curated()

The ten dataflow IDs that have hand-curated plain-English support.

Curated dataflows

For these curated dataflows, filters accepts plain-English values (e.g. "region": "nsw" instead of "REGION": "1"):

  • LF — Labour Force, monthly: employment, unemployment, participation by state/sex

  • CPI — Consumer Price Index, quarterly inflation (cat 6401.0 — the headline rate)

  • CPI_MONTHLY — Monthly CPI Indicator (cat 6484.0), full sub-category and per-city breakdown

  • WPI — Wage Price Index, quarterly wage growth by industry/sector/state

  • PPI_FD — Producer Price Index Final Demand, quarterly producer inflation

  • JV — Job Vacancies, quarterly labour demand by industry/sector/state

  • AWE — Average Weekly Earnings, half-yearly by industry/sector/state

  • ANA_AGG — National Accounts: GDP, GDP per capita, terms of trade, real income (Australia, quarterly)

  • ABS_ANNUAL_ERP_ASGS2021 — Estimated Resident Population, annual by state and sub-state geography

  • ERP_Q — Quarterly Estimated Resident Population, by state/sex/age

  • BUILDING_APPROVALS — Building Approvals (cat 8731.0), monthly by state/capital region, building type (houses / townhouses / apartments / total dwellings / non-residential) and measure (number / value). The property-economist "Building Index" series.

  • BA_GCCSA — Building Approvals, monthly by state/capital region and building type (raw GCCSA dimension surface; BUILDING_APPROVALS is the cleaner alias)

  • BA_LGA2024 — Building Approvals at the council (Local Government Area) level, monthly, ~570 councils — far more granular than BA_GCCSA's 8-capital geography. Pass region= an LGA code (e.g. "10050" Albury, "22750" Greater Geelong, "31000" Brisbane) for council-by-council approvals; defaults to Brisbane. Council-level only — for state / national totals use BUILDING_APPROVALS. Resolves to ABS's current BA_LGA2025 SDMX dataflow so the series stays live.

  • BUILDING_ACTIVITY — Building Activity (cat 8752.0), quarterly dwelling units completed / commenced / under construction plus value of work, by state and building type. The trailing-reality counterpart to BUILDING_APPROVALS — pair the two for approvals-vs-completions, and add NOM for the supply-vs-migration story.

  • NOM — Net Overseas Migration (cat 3412.0), financial-year arrivals/departures/net by state and age. The dominant rents-vs-migration series; publishes the headline net figure to the latest FY.

  • ABS_NOM_VISA_CY — NOM by visa subclass (calendar year, student / skilled / working holiday / permanent streams)

  • LEND_HOUSING — Lending Indicators, quarterly new housing loan commitments by purpose, lender, and state

  • HSI_M — Monthly Household Spending Indicator (ABS-blessed retail-trade replacement), COICOP category × discretionary × state

  • RT — Retail Trade (43-year historical series, ceased Jul 2025)

  • C21_G01_POA / C21_G02_POA / C21_G02_SA2 — Census 2021 selected characteristics and medians by postcode / SA2

Any other ABS dataflow still works — pass raw SDMX dimension IDs and codes.

Worked examples

Cross-source compatibility. All location filters accept canonical state codes ("NSW"), full names ("New South Wales"), case-insensitive variants ("nsw"), ISO 3166-2 ("AU-NSW"), and 4-digit postcodes ("2000" → NSW). Powered by aus-identity — the same input format works across abs-mcp, ato-mcp, apra-mcp, aihw-mcp, and asic-mcp.

"What's the current unemployment rate in NSW?"

Claude calls:

latest(dataset_id="LF", filters={"region": "nsw", "measure": "unemployment_rate"})

Returns:

{
  "dataset_id": "LF",
  "dataset_name": "Labour Force",
  "query": {"region": "nsw", "measure": "unemployment_rate"},
  "period": {"start": "2026-03", "end": "2026-03"},
  "unit": "Percent",
  "records": [
    {
      "period": "2026-03",
      "value": 4.27,
      "dimensions": {"measure": "Unemployment rate", "region": "New South Wales", "sex": "Persons"},
      "unit": "Percent"
    }
  ],
  "source": "Australian Bureau of Statistics",
  "retrieved_at": "2026-05-11T03:14:22Z",
  "abs_url": "https://www.abs.gov.au/statistics/labour/employment-and-unemployment/labour-force-australia"
}

"Show me NSW housing approvals over the last two years"

get_data(dataset_id="BA_GCCSA", filters={"region": "nsw", "measure": "dwelling_units"}, start_period="2024")

"Compare monthly CPI inflation in Sydney vs Melbourne"

get_data(dataset_id="CPI_MONTHLY", filters={"region": ["sydney", "melbourne"], "measure": "change_year"}, start_period="2023")

(CPI itself publishes only the national weighted average at quarterly cadence; the monthly indicator carries per-city series.)

Period formats

ABS uses different period formats per dataflow. Pass start_period / end_period in the matching format:

Dataflows

Frequency

Format

Example

LF, BA_GCCSA, BUILDING_APPROVALS

Monthly

YYYY-MM

"2026-03"

BUILDING_ACTIVITY

Quarterly

YYYY-Qn

"2025-Q4"

CPI, WPI, PPI_FD, JV, ANA_AGG, LEND_HOUSING, ERP_Q

Quarterly

YYYY-Q*

"2025-Q4"

CPI_MONTHLY, HSI_M

Monthly

YYYY-MM

"2025-12"

AWE

Half-yearly

YYYY-S*

"2025-S2"

NOM (financial year), ABS_ANNUAL_ERP_ASGS2021

Annual

YYYY

"2025"

Verifying your install

The running MCP server reports its version on every DataResponse:

{ ..., "server_version": "0.2.11", ... }

If you see a value below the latest on PyPI, your uvx cache is stale. Either switch to ["--upgrade", "abs-mcp"] in your config (recommended), or refresh manually:

uvx --refresh abs-mcp --help
# Then fully quit and relaunch Claude Desktop (Cmd+Q — window-close is not enough).

Claude Desktop's MCP child processes are long-lived; refreshing the wheel cache does not restart an already-running server. Cold app launch is required.

Development

git clone https://github.com/Bigred97/abs-mcp.git
cd abs-mcp
uv sync --extra dev
uv pip install -e .

# Unit tests (no network)
uv run pytest

# Live integration tests (hits real ABS API)
uv run pytest -m live

The SQLite cache lives at ~/.abs-mcp/cache.db. Catalogue refreshes every 24h, codelists every 7 days, data responses every hour, latest 15 minutes. Delete the file to force a refresh.

How it works

When you ask Claude an ABS question, it picks the right tool, fills in the curated filters, and calls the live ABS API. You see the reasoning + tool call inline:

Claude reasoning + tool call panel

Claude does the picking; this server does the SDMX translation, unit attribution, and clean response shaping. You don't have to know what M13.3.1599.20.1.M means — and neither does Claude.

How it differs from existing ABS MCP servers

The one existing community option (seansoreilly/abs) exposes a single query_dataset tool that passes raw SDMX through. This package offers semantic tools and curated mappings for the highest-value dataflows so an LLM can answer real questions without you needing to know what M13.3.1599.20.1.M means.

Sister MCPs (Australian Public Data portfolio)

Want all 9 sources behind one REST API? The hosted gateway at ausdata.io adds cross-source joins, full history, webhooks, and HMAC-signed responses on top of these MCPs — free tier (500 calls/mo, no card).

  • abs-mcp — this one. Australian Bureau of Statistics (CPI, unemployment, ERP, building approvals)

  • rba-mcp — Reserve Bank of Australia (cash rate, lending stats, exchange rates)

  • ato-mcp — Australian Taxation Office (tax stats, ACNC charities)

  • apra-mcp — Australian Prudential Regulation Authority (banking, insurance, super)

  • aihw-mcp — Australian Institute of Health and Welfare

  • asic-mcp — Australian Securities and Investments Commission (company registers)

  • aemo-mcp — Australian Energy Market Operator (NEM dispatch, spot prices, generation)

  • au-weather-mcp — Open-Meteo (Bureau of Meteorology aggregator)

  • wgea-mcp — Workplace Gender Equality Agency

  • aus-identity — Postcode / state / ABN normalisation helper used by all sisters

Changelog

See CHANGELOG.md for release history.

License

MIT — Harry Vass, 2026.

Available Tools

7 tools
describe_datasetA

Describe an ABS dataflow's filter dimensions, value codes, and source.

For curated dataflows (LF, CPI, ANA_AGG, AWE, BA_GCCSA, ERP_Q, JV, LEND_HOUSING, WPI, ABS_ANNUAL_ERP_ASGS2021), returns plain-English dimension names + curated value keys + the ABS source URL.

For other dataflows (~1,200 in total), returns raw SDMX dimensions and codelists translated to the same response shape — pass raw SDMX codes to get_data when querying these.

Examples: # Curated path — plain-English values detail = await describe_dataset("LF") # detail.dimensions = [{'name': 'region', 'values': [{'key': 'nsw', # 'sdmx_code': '1'}, {'key': 'vic', 'sdmx_code': '2'}, ...]}, ...]

# Raw path — full SDMX codelist
detail = await describe_dataset("ALC")  # Apparent Consumption of Alcohol
# detail.is_curated == False; values are raw SDMX codes

When to use: - Before calling get_data on an unfamiliar dataflow — to discover valid filter dim names and value keys - To get the canonical source URL on the ABS site - To see whether a dataflow is curated (plain-English) or raw SDMX

Returns: DatasetDetail with id, name, description, is_curated flag, the list of filter dimensions (name, sdmx_id, values), and abs_url.

ParametersJSON Schema
NameRequiredDescriptionDefault
dataset_idYesABS dataflow ID. Use search_datasets to discover, or list_curated to enumerate the 10 dataflows with plain-English support. Case-insensitive — 'lf', 'LF', and ' LF ' all resolve to 'LF'.

Output Schema

ParametersJSON Schema
NameRequiredDescription
idYes
nameYes
abs_urlYes
dimensionsYes
is_curatedYes
descriptionYes
hidden_defaultsNo

TDQS

A4.5/5.0
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/5

Is 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/5

Given 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/5

Does 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/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: 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/5

Does 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.

get_dataA

Query an ABS dataflow and return observations.

Pass filters and/or a period range — unfiltered queries on large dataflows can return tens of thousands of observations.

Curated dataflows accept plain-English filter keys and values that are translated to SDMX codes server-side. For example, on LF: {"region": "nsw", "measure": "unemployment_rate"} resolves to SDMX key M13.3.1599.20.1.M with hidden-dim defaults auto-applied.

Examples: # NSW unemployment monthly for 2024 resp = await get_data( "LF", filters={"region": "nsw", "measure": "unemployment_rate"}, start_period="2024", end_period="2024-12", ) # → resp.records[0]: period='2024-01', value=4.8, unit='Percent'

# Multi-state comparison
resp = await get_data(
    "LF",
    filters={"region": ["nsw","vic","qld"], "measure": "unemployment_rate"},
    start_period="2024",
    format="csv",
)
# → resp.csv contains 36 rows (3 states × 12 months)

# Australia quarterly CPI annual change
resp = await get_data(
    "CPI",
    filters={"region": "australia", "measure": "change_year"},
    start_period="2020",
)

When to use: - You want observations over a time range (use latest() for the most-recent only) - You want a multi-state or multi-measure comparison via list filters - You want a CSV for downstream charting / spreadsheet tools

Returns: DataResponse with records (list of {period, value, dimensions, unit}), unit (when homogeneous), period bounds, the resolved query echo, the ABS source URL, and the CC-BY 4.0 attribution string.

ParametersJSON Schema
NameRequiredDescriptionDefault
formatNoResponse shape. 'records' (default): flat list of observations. 'series': observations grouped by dimension key for chart-friendly shapes. 'csv': returns the table as a CSV string in the `csv` field with records empty.records
filtersNoDimension filters. For curated dataflows: plain-English keys and values, e.g. {'region': 'nsw', 'measure': 'unemployment_rate'}. For raw dataflows: SDMX dimension IDs and codes. Pass a list as the value to query multiple values for a dimension. Whitespace is stripped; empty list / empty value rejected with a hint.
dataset_idYesABS dataflow ID like 'LF', 'CPI'. Use search_datasets to discover.
end_periodNoInclusive end period. Same format as start_period.
start_periodNoInclusive start period. Format follows the dataflow's cadence: annual 'YYYY' (e.g. '2020'), monthly 'YYYY-MM' (e.g. '2024-03'), quarterly 'YYYY-Q1', half-yearly 'YYYY-S1', daily 'YYYY-MM-DD'. An int year (e.g. 2024) is also accepted and treated as 'YYYY'. URL-unsafe characters (?, &, /, etc.) are rejected at the boundary.

Output Schema

ParametersJSON Schema
NameRequiredDescription
csvNo
unitNo
queryNo
staleNo
periodNo
sourceNo
abs_urlYesClick-through URL for this dataset's source page. abs-mcp legacy name — prefer source_url (canonical) for new code. Both fields are populated identically.
recordsNo
row_countNoNumber of observation rows in records.
dataset_idYes
source_urlYesCanonical click-through URL. Same value as abs_url; both populated for backward compat.
attributionNo
dataset_nameYes
retrieved_atYes
stale_reasonNo
truncated_atNo
server_versionNo

TDQS

A5/5.0
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/5

Is 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/5

Given 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/5

Does 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/5

Does 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/5

Does 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.

latestA

Return the most recent observation(s) for a dataflow.

Wraps get_data with lastNObservations=1 and a 15-minute cache TTL (vs 1 hour for general data calls). Use this for "what's the current X?" questions — it's a cheap, fast call: warm-cache p50 ~22ms, cold-cache ~200ms.

Examples: # Latest NSW unemployment rate resp = await latest("LF", {"region": "nsw", "measure": "unemployment_rate"}) # → resp.records[0]: period='2026-03', value=4.61, unit='Percent'

# Latest Australia headline annual inflation
resp = await latest("CPI", {"region": "australia", "measure": "change_year"})
# → resp.records[0]: period='2026-Q1', value=4.6, unit='Percent'

# Latest Greater Sydney population
resp = await latest("ABS_ANNUAL_ERP_ASGS2021",
                    {"region": "greater_sydney", "region_type": "gccsa"})
# → resp.records[0]: period='2025', value=5640000, unit='Persons'

When to use: - You want "the current value" of an indicator (most common workflow) - You're answering a "what's the unemployment rate?" style question - You want sub-50ms warm-cache latency for chat/agent integration

Returns: DataResponse with one most-recent observation per matched dimension combination. Same envelope as get_data.

ParametersJSON Schema
NameRequiredDescriptionDefault
filtersNoDimension filters. For curated dataflows: plain-English keys and values. Without filters, expect one observation per dimension combination (often hundreds) — pass at least region + measure for a clean single number.
dataset_idYesABS dataflow ID. Use search_datasets to discover.

Output Schema

ParametersJSON Schema
NameRequiredDescription
csvNo
unitNo
queryNo
staleNo
periodNo
sourceNo
abs_urlYesClick-through URL for this dataset's source page. abs-mcp legacy name — prefer source_url (canonical) for new code. Both fields are populated identically.
recordsNo
row_countNoNumber of observation rows in records.
dataset_idYes
source_urlYesCanonical click-through URL. Same value as abs_url; both populated for backward compat.
attributionNo
dataset_nameYes
retrieved_atYes
stale_reasonNo
truncated_atNo
server_versionNo

TDQS

A4.9/5.0
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/5

Is 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/5

Given 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/5

Does 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/5

Does 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/5

Does 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.

list_curatedA

List the 10 ABS dataflow IDs with hand-curated plain-English support.

These are the dataflows where get_data accepts plain-English filter keys ({"region": "nsw"}) and describe_dataset returns rich human-readable metadata. All other ABS dataflows (~1,200) are still accessible via get_data with raw SDMX dimension IDs and codes.

The 10 curated dataflows: - LF — Labour Force (unemployment, employment, participation) - CPI — Consumer Price Index (inflation) - WPI — Wage Price Index (wage growth) - AWE — Average Weekly Earnings - JV — Job Vacancies - BA_GCCSA — Building Approvals (by Greater Capital City) - LEND_HOUSING — Lending Indicators / Housing Finance - ANA_AGG — National Accounts (GDP) - ERP_Q — Estimated Resident Population (quarterly) - ABS_ANNUAL_ERP_ASGS2021 — Population (annual; supports SA2/SA3/SA4)

Example: ids = list_curated() # → ['ABS_ANNUAL_ERP_ASGS2021', 'ANA_AGG', 'AWE', 'BA_GCCSA', 'CPI', # 'ERP_Q', 'JV', 'LEND_HOUSING', 'LF', 'WPI']

When to use: - You want to know which dataflows have plain-English support - You're enumerating capabilities programmatically (e.g. building a UI) - You're showing users a "supported topics" list

Returns: Sorted list of dataflow IDs. Always 10 entries today.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
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/5

Is 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/5

Given 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/5

Does 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/5

Does 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/5

Does 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.

release_calendarA

Upcoming ABS publication schedule (data releases).

Scrapes the official ABS release calendar (https://www.abs.gov.au/release-calendar/future-releases-calendar) and returns each scheduled publication with its release timestamp, title, reference period, and — when the title maps to a curated abs-mcp dataset — the dataset_id an agent can plug into get_data or latest. Curated mappings cover the 10 datasets in list_curated() plus a handful of commonly-watched non-curated catalogues (Retail Trade, International Trade in Goods, etc., where dataset_id stays null but publication_id carries the ABS catalogue number).

release_at is returned with Sydney's local UTC offset (+10:00 AEST or +11:00 AEDT) — what ABS publishes against. The DST switch is naive (month-based), within an hour of correct at the changeover boundary; downstream code should treat the offset as authoritative rather than re-deriving local time.

Examples: # Next 7 days cal = await release_calendar(7) for r in cal.releases: print(r.release_at, r.title, r.dataset_id)

# Filter to curated datasets only
cal = await release_calendar(30)
curated_releases = [r for r in cal.releases if r.dataset_id]

When to use: - Building a webhook / notification feed (ABS publishes at 11:30 AEST) - "What's next from the ABS?" agent answers - Pre-warming caches the morning of a known release

Returns: ReleaseCalendarResponse — same envelope shape as rba-mcp's release_calendar for portfolio interop. Sorted ascending by release_at. stale=True + stale_reason is set when the live HTML scrape failed and a cached payload was served past TTL.

ParametersJSON Schema
NameRequiredDescriptionDefault
days_aheadNoHorizon in days. Returns ABS publications scheduled to release between now and `now + days_ahead`. Default 30 covers the typical monthly + quarterly cadence.

Output Schema

ParametersJSON Schema
NameRequiredDescription
staleNo
sourceNo
releasesNo
row_countYes
source_urlNo
attributionNo
horizon_daysYes
retrieved_atYes
stale_reasonNo
server_versionNo

TDQS

A4.9/5.0
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/5

Is 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/5

Given 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/5

Does 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/5

Does 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/5

Does 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.

search_datasetsA

Fuzzy-search ABS dataflow names, descriptions, and keywords.

Use this when you don't know the exact dataset ID. The 10 curated dataflows (LF, CPI, ANA_AGG, etc.) get a relevance boost so common queries like "unemployment" or "gdp" return the right dataset at rank #1 — not one of ABS's 800+ census tables that mention these keywords incidentally.

Examples: # Discover which dataflow answers "what's NSW unemployment?" results = await search_datasets("unemployment") # → [{id: 'LF', name: 'Labour Force', is_curated: True}, ...]

# Broader topic exploration
results = await search_datasets("housing", limit=5)
# → top 5 housing-related dataflows, curated first

When to use: - You have a natural-language question and need to identify the dataset - You want to discover what ABS publishes on a topic - You're not sure if a topic has a plain-English (curated) mapping yet

Returns: List of DatasetSummary (id, name, description, is_curated), ranked by relevance. Curated dataflows surface above raw SDMX dataflows.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return, ranked by relevance. Curated dataflows get a +25 score bonus so they surface above ABS's ~800 census tables for common queries.
queryYesFree-text search query. Matches against dataflow IDs, names, descriptions, and each curated YAML's search_keywords. Case-insensitive.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
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/5

Is 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/5

Given 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/5

Does 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/5

Does 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/5

Does 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.

top_nA

Return the N rows with the largest (or smallest) value of a measure.

Ranks across the most-recent available period only (uses lastNObservations=1 under the hood) so the result is a clean "top N entities at the latest period" view — not noisy historical highs.

This is the most common agent workflow: "show me the top 10 X by Y". Without this tool, an agent would call get_data, receive the full time series, and then sort/slice locally — wasting tokens and turns. top_n does the rank server-side and returns only the requested rows.

Examples: # 5 states with the highest current unemployment rate top_n("LF", "unemployment_rate", n=5)

# 10 GCCSAs with the largest populations
top_n("ABS_ANNUAL_ERP_ASGS2021", "estimated_resident_population",
      n=10, filters={"region_type": "gccsa"})

# 3 industries with the lowest wage growth
top_n("WPI", "wage_price_index", n=3, direction="bottom")

Returns: DataResponse with at most n records, sorted by measure value in the requested direction. Other fields (period, unit, attribution) match a regular get_data call.

ParametersJSON Schema
NameRequiredDescriptionDefault
nNoHow many top (or bottom) rows to return.
filtersNoOptional additional dimension filters, same shape as get_data. Do NOT include the 'measure' key here — that is supplied via the `measure` parameter.
measureYesPlain-English measure key to rank by — one of the curated measure values for this dataflow. Use the describe endpoint or describe tool to see available measures.
directionNo'top' returns the N rows with the LARGEST measure values (highest unemployment_rate, biggest population, etc.). 'bottom' returns the SMALLEST.top
dataset_idYesABS dataflow ID. Must be a curated dataflow with a 'measure' dimension. Use the list-curated endpoint or list tool to enumerate.

Output Schema

ParametersJSON Schema
NameRequiredDescription
csvNo
unitNo
queryNo
staleNo
periodNo
sourceNo
abs_urlYesClick-through URL for this dataset's source page. abs-mcp legacy name — prefer source_url (canonical) for new code. Both fields are populated identically.
recordsNo
row_countNoNumber of observation rows in records.
dataset_idYes
source_urlYesCanonical click-through URL. Same value as abs_url; both populated for backward compat.
attributionNo
dataset_nameYes
retrieved_atYes
stale_reasonNo
truncated_atNo
server_versionNo

TDQS

A4.7/5.0
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/5

Is 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/5

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

Given the presence of an output schema, 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/5

Does 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/5

Does 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/5

Does 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 7 tool updatesv0.13.2
    • Addeddescribe_dataset
    • Addedget_data
    • Addedlatest
    • Addedlist_curated
    • Addedrelease_calendar
    • Addedsearch_datasets
    • Addedtop_n
  2. 5 tool updatesv0.11.10
    • Removeddescribe_dataset
    • Removedget_data
    • Removedlatest
    • Removedlist_curated
    • Removedsearch_datasets
  3. 2 tool updatesv0.2.12
    • Changeddescribe_dataset1 field changed
      • addedOutput schema / properties / hidden_defaults
        Added value: +{
+  "items": {
+    "properties": {
+      "description": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null
+      },
+      "name": {
+        "type": "string"
+      },
+      "sdmx_id": {
+        "type": "string"
+      },
+      "values": {
+        "items": {
+          "properties": {
+            "key": {
+              "type": "string"
+            },
+            "label": {
+              "anyOf": [
+                {
+                  "type": "string"
+                },
+                {
+                  "type": "null"
+                }
+              ],
+              "default": null
+            },
+            "sdmx_code": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "key",
+            "sdmx_code"
+          ],
+          "type": "object"
+        },
+        "type": "array"
+      }
+    },
+    "required": [
+      "name",
+      "sdmx_id",
+      "values"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
    • Changedget_data5 fields changed
      • changedInput schema / properties / end_period / anyOf
        Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
      • changedInput schema / properties / end_period / examples
        Previous value: -[
-  "2025",
-  "2025-12",
-  "2025-Q4"
-]New value: +[
+  "2025",
+  "2025-12",
+  "2025-Q4",
+  2025
+]
      • changedInput schema / properties / start_period / anyOf
        Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
      • changedInput schema / properties / start_period / description
        Previous value: -"Inclusive start period. Format follows the dataflow's cadence: annual 'YYYY' (e.g. '2020'), monthly 'YYYY-MM' (e.g. '2024-03'), quarterly 'YYYY-Q1', half-yearly 'YYYY-S1', daily 'YYYY-MM-DD'. URL-unsafe characters (?, &, /, etc.) are rejected at the boundary."New value: +"Inclusive start period. Format follows the dataflow's cadence: annual 'YYYY' (e.g. '2020'), monthly 'YYYY-MM' (e.g. '2024-03'), quarterly 'YYYY-Q1', half-yearly 'YYYY-S1', daily 'YYYY-MM-DD'. An int year (e.g. 2024) is also accepted and treated as 'YYYY'. URL-unsafe characters (?, &, /, etc.) are rejected at the boundary."
      • changedInput schema / properties / start_period / examples
        Previous value: -[
-  "2020",
-  "2024-03",
-  "2024-Q1",
-  "2024-S1"
-]New value: +[
+  "2020",
+  "2024-03",
+  "2024-Q1",
+  "2024-S1",
+  2020
+]
  4. 4 tool updatesv0.2.11
    • Changeddescribe_dataset2 fields changed
      • addedInput schema / properties / dataset_id / description
        Added value: +"ABS dataflow ID. Use search_datasets to discover, or list_curated to enumerate the 10 dataflows with plain-English support. Case-insensitive — 'lf', 'LF', and ' LF ' all resolve to 'LF'."
      • addedInput schema / properties / dataset_id / examples
        Added value: +[
+  "LF",
+  "CPI",
+  "LEND_HOUSING",
+  "ANA_AGG",
+  "ABS_ANNUAL_ERP_ASGS2021"
+]
    • Changedget_data12 fields changed
      • addedInput schema / properties / dataset_id / description
        Added value: +"ABS dataflow ID like 'LF', 'CPI'. Use search_datasets to discover."
      • addedInput schema / properties / dataset_id / examples
        Added value: +[
+  "LF",
+  "CPI",
+  "LEND_HOUSING",
+  "ANA_AGG"
+]
      • addedInput schema / properties / end_period / description
        Added value: +"Inclusive end period. Same format as start_period."
      • addedInput schema / properties / end_period / examples
        Added value: +[
+  "2025",
+  "2025-12",
+  "2025-Q4"
+]
      • addedInput schema / properties / filters / description
        Added value: +"Dimension filters. For curated dataflows: plain-English keys and values, e.g. {'region': 'nsw', 'measure': 'unemployment_rate'}. For raw dataflows: SDMX dimension IDs and codes. Pass a list as the value to query multiple values for a dimension. Whitespace is stripped; empty list / empty value rejected with a hint."
      • addedInput schema / properties / filters / examples
        Added value: +[
+  {
+    "measure": "unemployment_rate",
+    "region": "nsw"
+  },
+  {
+    "measure": "employed_persons",
+    "region": [
+      "nsw",
+      "vic",
+      "qld"
+    ]
+  },
+  {
+    "measure": "change_year",
+    "region": "australia"
+  }
+]
      • addedInput schema / properties / format / description
        Added value: +"Response shape. 'records' (default): flat list of observations. 'series': observations grouped by dimension key for chart-friendly shapes. 'csv': returns the table as a CSV string in the `csv` field with records empty."
      • addedInput schema / properties / format / examples
        Added value: +[
+  "records",
+  "series",
+  "csv"
+]
      • addedInput schema / properties / start_period / description
        Added value: +"Inclusive start period. Format follows the dataflow's cadence: annual 'YYYY' (e.g. '2020'), monthly 'YYYY-MM' (e.g. '2024-03'), quarterly 'YYYY-Q1', half-yearly 'YYYY-S1', daily 'YYYY-MM-DD'. URL-unsafe characters (?, &, /, etc.) are rejected at the boundary."
      • addedInput schema / properties / start_period / examples
        Added value: +[
+  "2020",
+  "2024-03",
+  "2024-Q1",
+  "2024-S1"
+]
      • addedOutput schema / properties / attribution
        Added value: +{
+  "default": "Data sourced from the Australian Bureau of Statistics and licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). https://www.abs.gov.au/about/copyright-and-creative-commons",
+  "type": "string"
+}
      • addedOutput schema / properties / server_version
        Added value: +{
+  "type": "string"
+}
    • Changedlatest6 fields changed
      • addedInput schema / properties / dataset_id / description
        Added value: +"ABS dataflow ID. Use search_datasets to discover."
      • addedInput schema / properties / dataset_id / examples
        Added value: +[
+  "LF",
+  "CPI",
+  "ANA_AGG",
+  "LEND_HOUSING"
+]
      • addedInput schema / properties / filters / description
        Added value: +"Dimension filters. For curated dataflows: plain-English keys and values. Without filters, expect one observation per dimension combination (often hundreds) — pass at least region + measure for a clean single number."
      • addedInput schema / properties / filters / examples
        Added value: +[
+  {
+    "measure": "unemployment_rate",
+    "region": "nsw"
+  },
+  {
+    "measure": "change_year",
+    "region": "australia"
+  },
+  {
+    "region": "1GSYD",
+    "region_type": "gccsa"
+  }
+]
      • addedOutput schema / properties / attribution
        Added value: +{
+  "default": "Data sourced from the Australian Bureau of Statistics and licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). https://www.abs.gov.au/about/copyright-and-creative-commons",
+  "type": "string"
+}
      • addedOutput schema / properties / server_version
        Added value: +{
+  "type": "string"
+}
    • Changedsearch_datasets6 fields changed
      • addedInput schema / properties / limit / description
        Added value: +"Maximum number of results to return, ranked by relevance. Curated dataflows get a +25 score bonus so they surface above ABS's ~800 census tables for common queries."
      • addedInput schema / properties / limit / examples
        Added value: +[
+  5,
+  10,
+  20
+]
      • addedInput schema / properties / limit / maximum
        Added value: +100
      • addedInput schema / properties / limit / minimum
        Added value: +1
      • addedInput schema / properties / query / description
        Added value: +"Free-text search query. Matches against dataflow IDs, names, descriptions, and each curated YAML's search_keywords. Case-insensitive."
      • addedInput schema / properties / query / examples
        Added value: +[
+  "unemployment",
+  "inflation",
+  "gdp",
+  "housing finance",
+  "wage growth"
+]
  5. 5 tool updatesv0.2.9
    • First observeddescribe_dataset
    • First observedget_data
    • First observedlatest
    • First observedlist_curated
    • First observedsearch_datasets
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.7/5.0

Scored across 7 tools

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/5

Most 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/5

Seven 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/5

The 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.

Maintenance

ActivityNo data
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • FRED Macroeconomic Data MCP

    hungson175
    F
    license
    Not graded
    quality
    D
    maintenance
    Provides access to Federal Reserve Economic Data (FRED) through Claude and other LLM clients, enabling users to search for, retrieve, and visualize economic indicators like GDP, employment, and inflation data.
    8
    -

  • econdata

    pipeworx-io
    A
    license
    Not graded
    quality
    C
    maintenance
    Wraps the Bureau of Labor Statistics public API v2 to provide economic data through natural language queries or direct tool calls.
    1 npm
    MIT