This server gives LLMs live access to Reserve Bank of Australia statistical data via 6 MCP tools.
search_tables(query, limit) — fuzzy-search RBA F-tables by name/topic to discover relevant tables.
describe_table(table_id) — list a table's series, plain-English keys, units, frequency, and source URL.
get_data(table_id, series, start_period, end_period, format) — query time series as records, series groups, or CSV; supports curated plain-English keys like cash_rate_target/aud_usd or raw RBA IDs, multi-series queries, and date ranges from year to day.
latest(table_id, series) — get the most recent observation for the cash rate, FX rates, mortgage rates, and other indicators.
list_curated() — enumerate the 5 hand-curated F-tables (F1.1, F4, F6, F11, F11.1).
release_calendar(days_ahead) — see upcoming RBA data releases, statements, and policy-adjacent publications with dates and source links.
Every response includes units, period, source attribution (CC BY 4.0), and click-through RBA URLs for verifiable answers.
mcp-name: io.ausdata/rba-mcp
Ask Claude about Australian interest rates, exchange rates, and lending rates 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 Reserve Bank of Australia's statistical tables, with curated mappings for the most-asked 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).
Companion to abs-mcp (ABS macro stats), ato-mcp (ATO tax + ACNC charity data), and au-weather-mcp (Australian weather via Open-Meteo + BOM) — together the four cover the most-asked Australian official data.
Once installed, your LLM can answer questions like:
Question | Real response (verified) |
What's the current RBA cash rate? | 4.10% (Apr 2026) |
What's the 3-month bank bill yield? | 4.34% (Apr 2026) |
AUD/USD today? | 0.7231 (11 May 2026) |
Trade-weighted index? | 66.9 (11 May 2026) |
Average mortgage rate (owner-occupier variable)? | 6.00% (Mar 2026) |
12-month term deposit rate? | 5.00% (Apr 2026) |
Show me AUD vs USD/EUR/GBP since 2024 | Daily series, all three currencies, one call |
TWI trend since 1983? | Monthly observations going back 40+ years |
Every answer comes with the period, units (Per cent per annum, USD per AUD, etc.), the publication date, and a link back to the RBA source. The MCP wraps RBA's CSV statistical tables and exposes them through 5 plain-English tools.
Related MCP server: Australian Bureau of Statistics
# After publish:
uvx --upgrade rba-mcp
# Local dev:
uv pip install -e .Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"rba": {
"command": "uvx",
"args": ["--upgrade", "rba-mcp"]
}
}
}Why
--upgrade?uvx rba-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.--upgrademakes uvx check PyPI on each launch and pull a newer release if one exists. Recommended for everyone except offline-first / pinned-version workflows. To verify which version is currently serving you, look at theserver_versionfield on anyDataResponse(added in 0.1.5).
If you also have abs-mcp installed, both servers run side-by-side. Claude disambiguates with the server prefix (rba:get_data vs abs:get_data).
For local dev (pre-PyPI):
{
"mcpServers": {
"rba": {
"command": "uv",
"args": ["run", "--directory", "/absolute/path/to/rba-mcp", "rba-mcp"]
}
}
}Add to ~/.cursor/mcp.json (or workspace .cursor/mcp.json):
{
"mcpServers": {
"rba": {
"command": "uvx",
"args": ["--upgrade", "rba-mcp"]
}
}
}Tool | What it does |
| Fuzzy-search RBA F-tables by name or topic. |
| Plain-English series listing for one F-table. |
| Query data. |
| Most-recent observation for the requested series. |
| The 5 F-table IDs with hand-curated plain-English support. |
For these five, series accepts plain-English keys (e.g. "aud_usd" instead of "FXRUSD"):
F1.1 — Money Market — Monthly: cash rate target, cash rate, bank bills, OIS rates, treasury notes
F4 — Retail Deposit & Investment Rates: transaction accounts, savings, term deposits, cash management trusts
F6 — Housing Lending Rates: owner-occupier vs investor, variable vs fixed, outstanding vs new loans
F11 — Exchange Rates — Monthly History (1983+): AUD/USD, AUD/EUR, AUD/GBP, AUD/JPY, AUD/CNY, AUD/NZD, TWI
F11.1 — Exchange Rates — Daily (2023+): same series, daily resolution
Any other F-table works too — pass raw RBA series IDs (e.g. "FXRUSD") instead of curated keys.
"What's the current RBA cash rate?"
latest(table_id="F1.1", series="cash_rate_target")"AUD to USD over the last year"
get_data(table_id="F11.1", series="aud_usd", start_period="2024")"Compare AUD against USD, EUR and GBP since 2020"
get_data(
table_id="F11",
series=["aud_usd", "aud_eur", "aud_gbp"],
start_period="2020"
)RBA series use ISO-style date formats. Pass start_period / end_period (or
the legacy start_date / end_date aliases) as:
Format | Example | Use for |
|
| Calendar year (int year also accepted, 0.1.8+) |
|
| Calendar month ( |
|
| Specific day (daily tables only) |
start_period snaps to the first instant of its period; end_period snaps to the last. So start_period="2024", end_period="2024" returns "all of 2024", not just 1 January. The legacy start_date / end_date parameter names continue to work as aliases (rba-mcp <= 0.2.x); prefer the new names for cross-sister consistency with the rest of the portfolio.
The running MCP server reports its version on every DataResponse:
{ ..., "server_version": "0.1.8", ... }If you see a value below the latest on PyPI, your uvx cache is stale. Either switch to ["--upgrade", "rba-mcp"] in your config (recommended), or refresh manually:
uvx --refresh rba-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.
git clone https://github.com/Bigred97/rba-mcp.git
cd rba-mcp
uv sync --extra dev
uv pip install -e .
# Unit tests (no network)
uv run pytest
# Live integration tests (hits RBA CDN)
uv run pytest -m liveThe SQLite cache lives at ~/.rba-mcp/cache.db. Data refreshes every 6h, latest 15min. Delete to force a refresh.
Claude picks the right tool, fills in the curated series keys, calls the live RBA CDN, and synthesises the answer. When the curated table is stale relative to a rate decision (RBA's monthly F1.1 publishes around the 5th business day, but Board meetings can hike between publications), Claude fluidly composes web-search results with this server's data:
You don't have to know what FIRMMCRT or FXRUSD mean — and neither does Claude. The server's curated YAMLs map plain-English keys (cash_rate_target, aud_usd) to RBA series IDs and surface unit attribution + the CC-BY 4.0 attribution string in every response.
The portfolio runs side-by-side in any MCP client; Claude disambiguates via the server prefix (rba:latest vs abs:latest vs ato:get_data vs weather:latest).
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 — Australian Bureau of Statistics (CPI, unemployment, ERP, building approvals)
rba-mcp — this one. 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
See examples/claude_desktop_config_both.json for an example multi-server config.
RBA data is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). Every DataResponse from this server includes an attribution field with the required notice. If you redistribute responses, credit the RBA.
See CHANGELOG.md for release history.
MIT — Harry Vass, 2026.
Describe an RBA F-table's series, units, and frequency.
For curated F-tables (F1.1, F4, F6, F11, F11.1), returns plain-English series keys (like 'cash_rate_target', 'aud_usd') with descriptions and units. For other F-tables, fetches the CSV and returns the raw RBA series IDs from the header along with start dates.
Examples: # Curated table — plain-English keys detail = await describe_table("F1.1") # detail.series[0]: key='cash_rate_target', series_id='FIRMMCRT', # unit='Per cent per annum', frequency='Daily'
# Curated FX table
detail = await describe_table("F11.1")
# detail.series has 'aud_usd', 'aud_eur', 'aud_jpy', 'aud_cny', etc.When to use: - Before calling get_data on a new table — to discover valid series keys - To get the canonical RBA source URL for citation - To distinguish curated (plain-English) tables from raw F-tables
Returns: TableDetail with id, name, description, is_curated flag, frequency, list of SeriesDetail (key, series_id, description, unit), and rba_url.
| Name | Required | Description | Default |
|---|---|---|---|
| table_id | Yes | RBA F-table ID like 'F1.1', 'F11', 'F6'. Use search_tables() to discover or list_curated() to enumerate the 15 plain-English tables. Case-insensitive ('f11' resolves to 'F11'). |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| series | Yes | |
| rba_url | Yes | |
| frequency | No | |
| is_curated | Yes | |
| source_url | Yes | |
| description | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavior: it returns different outputs for curated vs raw tables, mentions fetching CSV for raw tables, explains case-insensitivity, and provides example outputs. Since no annotations are present, the description carries the full burden and meets it completely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headers ('Examples:', 'When to use:', 'Returns:') and front-loaded purpose. It is slightly lengthy but every sentence adds value, including examples and usage guidance. A minor reduction for not being more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for an agent: it explains the two modes, when to use, parameter details, and return structure (summarized even though an output schema exists). Examples illustrate expected output. No gaps are apparent for this moderately complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the parameter with examples and case-insensitivity info (100% coverage). The description adds context beyond the schema by explaining how the parameter affects behavior (curated vs raw), but does not introduce new technical details. Given high schema coverage, the additional value is modest, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Describe an RBA F-table's series, units, and frequency.' It distinguishes between curated tables (plain-English keys) and raw tables (RBA series IDs) using specific examples. This directly addresses what the tool does and differentiates it from siblings like get_data or list_curated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use:' section explicitly lists three scenarios: before calling get_data, to discover valid series keys, and to distinguish curated vs raw tables. It also implies when not to use it (e.g., to get actual data) by naming get_data and search_tables as alternatives. This provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query an RBA F-table and return observations.
Curated tables accept plain-English series keys that map to canonical
RBA series IDs server-side. Omit `series` to get the table's headline
series (e.g. F1.1 → cash rate target, F11/F11.1 → AUD/USD, F6 → owner-
occupier outstanding variable rate). Pass an explicit list for a multi-
series query.
Examples:
# Cash rate target since 2020 (portfolio-standard name)
resp = await get_data("F1.1", series="cash_rate_target", start_period="2020")
# → resp.records[0]: period='2020-01-01', value=0.25, series='cash_rate_target'
# Headline default — no series arg returns the table's canonical series
resp = await get_data("F11.1", start_period="2024-01-01", end_period="2024-12-31")
# → resp.records: AUD/USD daily (the headline) for the period
# Multiple FX rates — pass an explicit list
resp = await get_data(
"F11.1",
series=["aud_usd", "aud_eur", "aud_jpy"],
start_period="2024-01-01",
end_period="2024-12-31",
)
# Mortgage rates as CSV
resp = await get_data("F6", format="csv", start_period="2023")
# → resp.csv = "date,series,value
2023-01-01,..."
# Raw (non-curated) F-table — pass raw RBA series IDs
resp = await get_data("F1", series=["FIRMMCRTD", "FIRMMBAB30"])
# Legacy alias still works (start_date / end_date)
resp = await get_data("F11", series="aud_usd", start_date="2024")
Parameter notes:
- Prefer `start_period` / `end_period` (portfolio-standard names; 7
of 9 sister MCPs use them).
- `start_date` / `end_date` are retained as legacy aliases.
Supplying both `start_period` and `start_date` (or `end_period`
and `end_date`) raises ValueError — pick one per pair.
When to use:
- You want a time series of an RBA indicator (use latest() for current-only)
- You want a multi-series comparison (e.g. all FX rates)
- You want CSV for downstream charting
Returns:
DataResponse with records, unit, period bounds, RBA source URL,
and CC-BY 4.0 attribution.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Response shape. 'records' (default): flat list of observations. 'series': observations grouped by series_id. 'csv': returns the table as a CSV string in the `csv` field. | records |
| series | No | Which series to return. For curated tables: plain-English keys (e.g. 'aud_usd', 'cash_rate_target') or a list for multi-series. For raw F-tables: raw RBA series IDs (e.g. 'FXRUSD'). Pass None (default) to use the table's headline series — e.g. F1.1 defaults to the cash rate target, F11/F11.1 to AUD/USD, F6 to the owner-occupier outstanding variable rate. Pass an explicit list to fetch multiple series. | |
| end_date | No | Legacy alias for `end_period` — retained for backward compatibility. Prefer `end_period` for cross-sister consistency. Supplying both raises ValueError. | |
| table_id | Yes | RBA F-table ID like 'F1.1', 'F11'. Use search_tables() to discover. | |
| end_period | No | Inclusive end period (portfolio-standard name). Same format as start_period. Mutually exclusive with the legacy `end_date` alias. | |
| start_date | No | Legacy alias for `start_period` — retained for backward compatibility (rba-mcp <= 0.2.x). Prefer `start_period` for cross-sister consistency. Same format and semantics as `start_period`. Supplying both raises ValueError. | |
| start_period | No | Inclusive start period (portfolio-standard name). Accepts 'YYYY', 'YYYY-MM', or 'YYYY-MM-DD'. An int year (e.g. 2024) is also accepted and treated as 'YYYY'. Semantic-checked: '2024-13' or '----' rejected at the boundary. Mutually exclusive with the legacy `start_date` alias. |
| Name | Required | Description |
|---|---|---|
| csv | No | |
| unit | No | |
| query | No | |
| stale | No | |
| period | No | |
| source | No | |
| rba_url | Yes | Click-through URL for this table's source page. rba-mcp legacy name — prefer source_url (canonical) for new code. Both fields are populated identically. |
| records | No | |
| table_id | Yes | |
| row_count | No | Number of observation rows in records. |
| source_url | Yes | Canonical click-through URL. Same value as rba_url; both populated for backward compat. |
| table_name | Yes | |
| attribution | No | |
| retrieved_at | Yes | |
| stale_reason | No | |
| truncated_at | No | |
| server_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes return format (DataResponse with records, unit, period bounds, RBA source URL, attribution) and error handling (mutual exclusion of start_period/start_date). Does not explicitly state read-only nature, but context implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections and examples. Front-loaded with main action. Slightly verbose but every section earns its place. Could be trimmed without loss of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, missing annotations, and existence of output schema, description covers all necessary context: use cases, error conditions, output format, sibling tool relationships, and parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% so baseline 3. Description adds significant value: examples for each parameter, explanation of curated vs raw series, default headline series per table, mutual exclusion constraints. Enhances understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query an RBA F-table and return observations,' with specific verb+resource. It distinguishes from siblings like `latest` (current-only) and `search_tables` (discovery) through examples and usage guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' section outlines scenarios (time series, multi-series, CSV) and implies when not to use (use `latest()` for current-only). References sibling tools like `search_tables` for discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the most recent observation for each series in an RBA F-table.
Wraps get_data with last_n=1 (and a shorter cache TTL). Use this for "what's the current X?" questions — it's a cheap, fast call.
Examples: # Current cash rate target (explicit) resp = await latest("F1.1", series="cash_rate_target") # → resp.records[0]: period='2026-05-06', value=3.85, unit='Per cent per annum'
# Headline default — no series arg returns the table's canonical series.
# F1.1 → cash rate target; F11/F11.1 → AUD/USD; F6 → average mortgage rate.
resp = await latest("F1.1")
# → resp.records[0]: cash_rate_target only (the table's headline)
# Snapshot multiple FX rates in one call
resp = await latest("F11.1", series=["aud_usd", "aud_eur", "aud_jpy"])
# Latest owner-occupier variable mortgage rate
resp = await latest("F6", series="owner_occupier_variable_existing")When to use: - You want the current value of an RBA indicator - You want a current-snapshot of multiple series in one call (pass an explicit list — e.g. all FX rates) - You want sub-50ms warm-cache latency for chat integration
Returns: DataResponse with one most-recent observation per requested series.
| Name | Required | Description | Default |
|---|---|---|---|
| series | No | Which series to return. For curated tables: plain-English keys. Pass None (default) to get the table's headline series — e.g. F1.1 returns the cash rate target, F11/F11.1 returns AUD/USD. Pass an explicit list to get multiple series in one snapshot. | |
| table_id | Yes | RBA F-table ID. Use search_tables() to discover. |
| Name | Required | Description |
|---|---|---|
| csv | No | |
| unit | No | |
| query | No | |
| stale | No | |
| period | No | |
| source | No | |
| rba_url | Yes | Click-through URL for this table's source page. rba-mcp legacy name — prefer source_url (canonical) for new code. Both fields are populated identically. |
| records | No | |
| table_id | Yes | |
| row_count | No | Number of observation rows in records. |
| source_url | Yes | Canonical click-through URL. Same value as rba_url; both populated for backward compat. |
| table_name | Yes | |
| attribution | No | |
| retrieved_at | Yes | |
| stale_reason | No | |
| truncated_at | No | |
| server_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains behavior well: it wraps get_data with last_n=1, uses shorter cache TTL, is cheap and fast, and returns one observation per series. It could explicitly state 'read-only' but the context is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear definition, examples, usage guidance, and return info. Every sentence adds value, though a few could be tightened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers purpose, parameters, examples, usage scenarios, performance characteristics, and return format. Given the tool's simplicity and the presence of output schema, nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds meaning by explaining the 'series' parameter's default behavior (headline series) and plain-English keys, and notes that 'table_id' can be discovered via search_tables(). Examples further clarify usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the most recent observation per series, using the verb 'Return' and specific resource 'RBA F-table'. It distinguishes itself from sibling 'get_data' by explicitly describing it as a wrapper with last_n=1 and shorter cache TTL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'When to use:' section listing appropriate scenarios like current values and multiple series snapshots. It implies not for historical analysis, but lacks explicit 'when not to use' or direct alternatives like 'for historical data, use get_data instead'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the 5 RBA F-table IDs with hand-curated plain-English support.
These are the tables where get_data and latest accept plain-English series keys (like 'cash_rate_target', 'aud_usd'). Other F-tables are still queryable via raw RBA series IDs.
The 5 curated F-tables: - F1.1 — Interest Rates and Yields: Money Market (incl. cash rate target) - F4 — Money Market Operations - F6 — Housing Lending Rates (standard variable, fixed, etc.) - F11 — Exchange Rates (AUD vs major currencies, daily) - F11.1 — Exchange Rate Indices (TWI, real TWI)
Example: ids = list_curated() # → ['F1.1', 'F11', 'F11.1', 'F4', 'F6']
When to use: - You want to know which tables have plain-English support - You're building a UI / agent that needs the supported set up front - You want to plan which F-tables to call without inspecting each
Returns: Sorted list of F-table IDs. Always 5 entries today.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, yet the description fully covers behavior: returns a sorted list of exactly 5 IDs, non-destructive, no hidden side effects. Discloses that other F-tables are queryable via raw IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with clear sections: purpose, when to use, example, returns. Every sentence adds value. No fluff, yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema, the description is fully complete. It explains the tool's role in the ecosystem, the exact output, and even lists the tables. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no parameters; baseline is 4. Description adds value by explaining that no input is needed and clarifying that the output is a sorted list of specific F-table IDs. Schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists 5 RBA F-table IDs with plain-English support. Distinguishes from siblings like search_tables (list all tables) and get_data/latest (query data). Verb+resource is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides 'When to use' section with three distinct scenarios (knowing supported tables, building UI/agent, planning calls). Implicitly suggests alternatives (e.g., search_tables for all tables, get_data for data) but lacks explicit 'when not to use' or alternative names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upcoming RBA publication schedule (data + statements + events).
Scrapes https://www.rba.gov.au/schedules-events/ and merges the two
schedule tables into a single chronological feed. Each entry reports
release_at (Sydney local with UTC offset), title, event_type,
dataset_id (curated F-table key when the release refreshes one,
else null), publication_id, and source_url.
Event types:
- data_release — regular statistical publication (Financial
Aggregates, Retail Payments, Index of Commodity Prices, etc.)
- statement — narrative release (Statement on Monetary Policy,
Minutes of Monetary Policy Meeting, Financial Stability Review,
Bulletin, Chart Pack)
- policy_decision — cash-rate decisions are NOT exposed here;
they appear on a separate RBA page. The Statement on Monetary
Policy and Minutes that follow ~24h and ~2 weeks later DO
appear, tagged as statement.
Returns the same envelope shape as abs-mcp.release_calendar so a
gateway poller can dispatch both feeds through the same code path.
Cached at 24h TTL with stale-fallback on 5xx (per portfolio graceful-degradation policy). The gateway should poll on its own schedule rather than hitting the live HTML.
Examples: cal = await release_calendar(7) for r in cal.releases: print(r.release_at, r.event_type, r.title, r.publication_id)
cal = await release_calendar(60)
statements = [r for r in cal.releases if r.event_type == "statement"]| Name | Required | Description | Default |
|---|---|---|---|
| days_ahead | No | Horizon in days. Returns RBA publications + events scheduled to release between now and `now + days_ahead`. Default 30 covers the typical monthly cadence. |
| Name | Required | Description |
|---|---|---|
| stale | No | |
| source | No | |
| releases | No | |
| row_count | Yes | |
| source_url | No | |
| attribution | No | |
| horizon_days | Yes | |
| retrieved_at | Yes | |
| stale_reason | No | |
| server_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden. It discloses scraping behavior, caching policy, event types, limitations (cash-rate not included), and the output shape. This is comprehensive and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, source, event types, caching, examples). Every sentence adds value, and it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (scraping, caching, multiple event types) and the presence of an output schema, the description covers all necessary aspects: behavior, limitations, caching, and usage. It is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value through usage examples and context (e.g., default covers monthly cadence).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as fetching the upcoming RBA publication schedule, specifying the verb 'scrapes' and the resource 'RBA publication schedule'. It distinguishes from sibling tools (data retrieval tools) by focusing on a live calendar scrape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context: it is cached with 24h TTL, should not be hit live, and cash-rate decisions are not included. However, it does not explicitly name alternative tools or provide a when-not-to-use beyond the cash-rate exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fuzzy-search RBA F-tables by name and topic.
Use this when you don't know the exact table ID. The 5 curated F-tables (F1.1, F4, F6, F11, F11.1) cover the most-asked indicators: cash rate, money-market rates, household lending rates, FX rates.
Examples: # Find the F-table that publishes the cash rate results = await search_tables("cash rate") # → [{id: 'F1.1', name: 'Interest Rates and Yields - Money Market', ...}]
# Discover what's available on FX
results = await search_tables("aud usd", limit=5)
# → top 5 FX-related tables, curated F11/F11.1 firstWhen to use: - You have a natural-language question and need to identify the table - You want to discover what RBA publishes on a topic - You're enumerating the F-table catalog programmatically
Returns: List of TableSummary (id, name, frequency, description), ranked by relevance. Curated tables surface above the rest.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return, ranked by relevance. | |
| query | Yes | Free-text search query. Matches against F-table IDs, names, and topic keywords. Case-insensitive. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses fuzzy matching, ranking by relevance, curated tables surfaced first, and return structure (List of TableSummary). Behavior is clearly read-only and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with distinct sections: one-liner summary, context, examples, when-to-use, returns. Every sentence adds value. Appropriate length for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of output schema (TableSummary) and comprehensive input schema, the description fully covers purpose, parameters, and behavior. No gaps identified; it addresses common usage scenarios and tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers both parameters with descriptions and examples (100% coverage). Description adds value by explaining matching logic (case-insensitive, against IDs/names/topics) and providing usage examples, but does not drastically improve the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs fuzzy-search on RBA F-tables by name and topic. It uses specific verb and resource, and distinguishes from sibling tools like list_curated (catalog listing) and describe_table (specific ID). Examples reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when you don't know the exact table ID', 'natural-language question', 'discover what RBA publishes'. Implies alternatives when ID is known. Also notes curated tables for common indicators, aiding tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.8.7describe_tableget_datalatestlist_curatedrelease_calendarsearch_tablesv0.8.5describe_tableget_datalatestlist_curatedsearch_tablesv0.1.9describe_table3 fields changedInput schema / properties / table_id / descriptionAdded value: +"RBA F-table ID like 'F1.1', 'F11', 'F6'. Use search_tables() to discover or list_curated() to enumerate the 5 plain-English tables. Case-insensitive ('f11' resolves to 'F11')."Input schema / properties / table_id / examplesAdded value: +[
+ "F1.1",
+ "F4",
+ "F6",
+ "F11",
+ "F11.1"
+]Output schema / properties / series / items / properties / end_dateAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}get_data12 fields changedInput schema / properties / end_date / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / end_date / descriptionAdded value: +"Inclusive end date. Same format as start_date."Input schema / properties / end_date / examplesAdded value: +[
+ "2025",
+ "2025-12",
+ "2025-12-31",
+ 2025
+]Input schema / properties / format / descriptionAdded value: +"Response shape. 'records' (default): flat list of observations. 'series': observations grouped by series_id. 'csv': returns the table as a CSV string in the `csv` field."Input schema / properties / format / examplesAdded value: +[
+ "records",
+ "series",
+ "csv"
+]Input schema / properties / series / descriptionAdded value: +"Which series to return. For curated tables: plain-English keys (e.g. 'aud_usd', 'cash_rate_target') or a list for multi-series. For raw F-tables: raw RBA series IDs (e.g. 'FXRUSD'). Pass None (default) to return all curated series in the table."Input schema / properties / series / examplesAdded value: +[
+ "cash_rate_target",
+ "aud_usd",
+ [
+ "aud_usd",
+ "aud_eur",
+ "aud_jpy"
+ ],
+ "FXRUSD"
+]Input schema / properties / start_date / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / start_date / descriptionAdded value: +"Inclusive start date. Accepts 'YYYY', 'YYYY-MM', or 'YYYY-MM-DD'. An int year (e.g. 2024) is also accepted and treated as 'YYYY'. Semantic-checked: '2024-13' or '----' rejected at the boundary."Input schema / properties / start_date / examplesAdded value: +[
+ "2024",
+ "2024-03",
+ "2024-03-15",
+ 2024
+]Input schema / properties / table_id / descriptionAdded value: +"RBA F-table ID like 'F1.1', 'F11'. Use search_tables() to discover."Input schema / properties / table_id / examplesAdded value: +[
+ "F1.1",
+ "F11",
+ "F6",
+ "F4"
+]latest4 fields changedInput schema / properties / series / descriptionAdded value: +"Which series to return. For curated tables: plain-English keys. Pass None (default) to get the latest observation for every curated series in the table — useful for dashboards."Input schema / properties / series / examplesAdded value: +[
+ "cash_rate_target",
+ "aud_usd",
+ [
+ "aud_usd",
+ "aud_eur",
+ "aud_jpy"
+ ]
+]Input schema / properties / table_id / descriptionAdded value: +"RBA F-table ID. Use search_tables() to discover."Input schema / properties / table_id / examplesAdded value: +[
+ "F1.1",
+ "F11",
+ "F6",
+ "F11.1"
+]search_tables6 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum number of results to return, ranked by relevance."Input schema / properties / limit / examplesAdded value: +[
+ 5,
+ 10,
+ 20
+]Input schema / properties / limit / maximumAdded value: +100Input schema / properties / limit / minimumAdded value: +1Input schema / properties / query / descriptionAdded value: +"Free-text search query. Matches against F-table IDs, names, and topic keywords. Case-insensitive."Input schema / properties / query / examplesAdded value: +[
+ "cash rate",
+ "aud usd",
+ "mortgage rates",
+ "term deposits",
+ "yield curve"
+]v0.1.5describe_tableget_datalatestlist_curatedsearch_tablesScored across 6 tools
Each tool serves a clearly distinct purpose: describe_table provides metadata, get_data retrieves time series, latest is a specialized wrapper for current values, list_curated enumerates tables with plain-English support, release_calendar gives publication schedules, and search_tables helps discover tables. The only potential overlap (get_data vs latest) is explicitly addressed with documentation clarifying use cases.
All tool names use snake_case with a consistent verb_noun pattern (describe_table, get_data, list_curated, release_calendar, search_tables). Even 'latest' follows the pattern implied by 'get_data' as a convenience alias. No mixing of conventions or inconsistent verb styles.
Six tools is well-scoped for an RBA data server, covering metadata discovery (describe_table, list_curated, search_tables), data retrieval (get_data, latest), and schedule information (release_calendar). This is neither too sparse nor too heavy for the domain.
The tool surface covers the essential lifecycle: discover tables (search_tables, list_curated), inspect structure (describe_table), and retrieve data (get_data, latest) plus schedule awareness (release_calendar). Minor gaps exist (e.g., no direct bulk download or advanced filtering), but the core workflows are supported without dead ends.
Australian economic data from the ABS, RBA, and APRA: CPI, GDP, cash rate, labour, and more.
RBA MCP — Reserve Bank of Australia statistics (free, no auth).
Live & historical FX rates and currency conversion for AI agents. No API keys.
Live & historical FX rates and currency conversion for AI agents. No API keys.