This server provides read-only access to public Reserve Bank of Australia (RBA) economic data via six tools:
Search RBA series (rba_search_series): Find data series by keyword or list all available series in the built-in catalogue.
Search RBA tables (rba_search_tables): Search statistical table listings (with a "readable" flag), optionally refreshing from the RBA website.
Get RBA series data (rba_get_series): Download actual values for one or more series IDs (e.g., GCPIAG) with current, historical, or both vintages and optional date filtering.
Get RBA table data (rba_get_table): Retrieve entire statistical tables (e.g., G1) by table number, with the same vintage and date-range options.
Get RBA forecasts (rba_get_forecasts): Access the latest or full historical public forecasts, filterable by series name and publication/observation dates.
Get RBA cash rate (rba_get_cash_rate): Obtain the cash rate target, interbank overnight rate, or both, with optional date range.
All tools support pagination (offset/max_rows) and return structured JSON responses with metadata (total_rows, returned_rows, has_more, truncated), ISO date formatting (YYYY-MM-DD), and null for missing values.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@readrba-mcp What is the current RBA cash rate?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
readrba-mcp is a local Matt Cowgill Protocol (MCP) server for public
Reserve Bank of Australia data. It exposes six read-only tools backed by the
R package readrba.
This repository is a prototype and has not been tested extensively!!! Use with Caution!!!
The TypeScript server handles MCP schemas, validation, timeouts, and stdio.
Each tool call starts one R process. The R worker loads the required packages,
runs one readrba request, and returns one JSON result.
R and package diagnostics go to stderr. Stdout is reserved for MCP JSON-RPC.
Related MCP server: AusEcon MCP for ABS | RBA | APRA data
Node.js 20 or later.
R with Rscript available.
R packages: pacman, readrba, jsonlite, dplyr, tibble, and purrr.
Install the R packages once:
install.packages(
c("pacman", "readrba", "jsonlite", "dplyr", "tibble", "purrr")
)Then install and build the server:
git clone https://github.com/dominic-behrens/readrba-mcp.git
cd readrba-mcp
npm install
npm run buildRun the server directly:
npm startIt will wait for an MCP client on stdin.
Every tool accepts offset, which defaults to 0, and max_rows, which
defaults to 1000. offset must be a non-negative integer. max_rows must
be a positive integer and has no configured ceiling.
Tool | Main arguments |
| Optional |
| Optional |
| Required |
| Required |
|
|
|
|
vintage accepts current, historical, or both. type accepts target,
interbank, or both.
For a both table or series request, overlapping observations are retained.
The response includes rba_vintage; the server does not deduplicate the two
sources.
Filters and deterministic sorting are applied before pagination. Successful tools return the same object as JSON text and as MCP structured content:
{
"data": [],
"total_rows": 0,
"returned_rows": 0,
"offset": 0,
"max_rows": 1000,
"has_more": false,
"truncated": false
}has_more reports whether later rows remain. truncated is true when the
response does not contain every matching row, including when offset skips
earlier rows.
Dates are serialized as YYYY-MM-DD. Missing R values are JSON null.
Validation, R, download, timeout, worker, and unknown-series failures are
returned as MCP tool errors with isError: true.
Environment variable | Default | Purpose |
|
| Rscript executable |
|
| Directory for RBA spreadsheet downloads and R temporary files |
|
| Positive worker timeout in milliseconds |
On some corporate Windows networks, readrba may also require
R_READRBA_DL_METHOD=wininet.
readrba can overwrite downloaded spreadsheets in
READRBA_DOWNLOAD_PATH. The directory is outside this repository by default,
so raw downloads are not committed. These files are package working files,
not a stable or complete response cache.
Build the server first. Replace each placeholder path below with a path that is valid in the client’s operating environment.
Use native Windows paths when the client runs on Windows:
{
"mcpServers": {
"readrba": {
"command": "node",
"args": ["C:\\path\\to\\readrba-mcp\\dist\\index.js"],
"env": {
"RSCRIPT_PATH": "\\path\\to\\rscript"
}
}
}
}Use WSL paths when Node runs in WSL. A Windows R installation can be called through its mounted path:
{
"mcpServers": {
"readrba": {
"command": "node",
"args": ["/path/to/readrba-mcp/dist/index.js"],
"env": {
"RSCRIPT_PATH": "\\path\\to\\rscript"
}
}
}
}Alternatively, install R inside WSL and omit RSCRIPT_PATH if Rscript is on
PATH.
The current Codex CLI accepts a stdio command after -- and environment
variables through repeated --env options:
codex mcp add \
--env RSCRIPT_PATH=/path/to/Rscript \
readrba -- node /path/to/readrba-mcp/dist/index.jsSee the Codex MCP documentation for configuration scope and other options.
Claude Code uses the same command separator:
claude mcp add \
--env RSCRIPT_PATH=/path/to/Rscript \
readrba -- node /path/to/readrba-mcp/dist/index.jsUse --scope user or --scope project if required. See
Claude Code MCP setup.
Configure:
command: node
arguments: /path/to/readrba-mcp/dist/index.js
environment: set RSCRIPT_PATH if Rscript is not on PATH
The process must receive MCP JSON-RPC on stdin and have exclusive use of stdout.
npm testThis builds strict TypeScript and exercises the built server through the MCP v2 client over stdio. It checks all six schemas, validation, pagination, structured content, ISO dates, JSON nulls, clean errors, and stderr isolation.
Run the offline R catalogue checks:
TEST_RSCRIPT_PATH=/path/to/Rscript npm run test:r:offlineRun live RBA smoke tests:
READRBA_LIVE_TEST=1 \
TEST_RSCRIPT_PATH=/path/to/Rscript \
npm run test:liveThe live tests cover CPI series GCPIAG, both vintages of table A1, latest
forecasts, and target, interbank, and combined cash rates.
The server architecture is adapted from
jonobri/readabs-mcp. RBA data
access is provided by
MattCowgill/readrba.
This project is not affiliated with the Reserve Bank of Australia.
MIT. See LICENSE.
Get the cash-rate target, interbank overnight cash rate, or both.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | target | |
| offset | No | Number of filtered and sorted rows to skip. | |
| end_date | No | Inclusive observation end date. | |
| max_rows | No | Maximum rows to return. There is no server-side ceiling. | |
| start_date | No | Inclusive observation start date. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| offset | Yes | |
| has_more | Yes | |
| max_rows | Yes | |
| truncated | Yes | |
| total_rows | Yes | |
| returned_rows | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds no behavioral detail beyond what annotations provide, such as potential limits or historical scope.
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?
Single sentence, no redundancy. Efficiently conveys purpose. Could slightly expand without harming conciseness.
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?
With output schema and comprehensive annotations, the description is minimally adequate. It lacks explanation of date filtering or pagination behavior but is acceptable for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so most parameters are documented in schema. The description adds meaning to the 'type' enum by naming the two options. Other parameters (offset, dates) are left to schema descriptions, which is acceptable given high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves cash-rate target, interbank overnight cash rate, or both. The verb 'Get' and resource 'cash rate' are specific and distinct from sibling tools like rba_search_series or rba_get_series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for RBA cash rate data but provides no explicit when-to-use or when-not-to-use guidance compared to siblings. It's clear in context but lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest or all public RBA forecasts, with optional series and date filters.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | latest | |
| offset | No | Number of filtered and sorted rows to skip. | |
| series | No | Forecast series names to retain, such as gdp_change. | |
| refresh | No | Download the current RBA forecast archive. | |
| max_rows | No | Maximum rows to return. There is no server-side ceiling. | |
| remove_old | No | Remove observations more than 180 days before their forecast date. | |
| forecast_end_date | No | Inclusive forecast publication end date. | |
| forecast_start_date | No | Inclusive forecast publication start date. | |
| observation_end_date | No | Inclusive forecast observation end date. | |
| observation_start_date | No | Inclusive forecast observation start date. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| offset | Yes | |
| has_more | Yes | |
| max_rows | Yes | |
| truncated | Yes | |
| total_rows | Yes | |
| returned_rows | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds no behavioral details beyond what annotations convey, so minimal added value.
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?
Single sentence efficiently conveys purpose and key parameters (scope, series, date filters), with no superfluous text.
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 10 parameters and no required ones, description is minimal. Output schema exists but description lacks details on pagination, ordering, or return format, which are helpful for complex queries.
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 90%; description does not add parameter-specific semantics. Baseline 3 is appropriate since description only restates filters without enhancing understanding.
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?
Description clearly states verb 'Get', resource 'public RBA forecasts', and mentions optional filters, distinguishing it from siblings like rba_get_series which retrieve specific series data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or avoid this tool vs alternatives (e.g., rba_get_series). Usage is implied but lacks exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download exact RBA series IDs for current, historical, or both table vintages.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Number of filtered and sorted rows to skip. | |
| vintage | No | current | |
| end_date | No | Inclusive observation end date. | |
| max_rows | No | Maximum rows to return. There is no server-side ceiling. | |
| series_ids | Yes | One or more exact RBA series identifiers, such as GCPIAG. | |
| start_date | No | Inclusive observation start date. | |
| update_urls | No | Refresh the RBA table URL list before downloading. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| offset | Yes | |
| has_more | Yes | |
| max_rows | Yes | |
| truncated | Yes | |
| total_rows | Yes | |
| returned_rows | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds the vintage options (current, historical, both), which are also in the schema. No additional behavioral traits like pagination or rate limits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the key action and scope. No extraneous words; it is concise yet informative.
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 output schema exists, the description does not need to explain return values. However, it does not mention date filtering, offset, or max_rows, which are significant for using the tool. For a 7-parameter tool with multiple filters, the description is minimally adequate but could be more 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 high (86%), so parameters are mostly documented. The description adds minimal extra meaning beyond mentioning vintage options. The baseline of 3 applies as the description does not significantly enrich parameter understanding.
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 downloads exact RBA series IDs for specified vintages. It uses a specific verb 'download' and resource 'exact RBA series IDs', and differentiates from sibling tools like rba_search_series by emphasizing exact IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when exact series IDs are known by saying 'exact RBA series IDs', but does not explicitly mention when to use alternatives like rba_search_series for searching. No when-not or exclusions given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download one or more RBA statistical tables for current, historical, or both vintages.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Number of filtered and sorted rows to skip. | |
| vintage | No | current | |
| end_date | No | Inclusive observation end date. | |
| max_rows | No | Maximum rows to return. There is no server-side ceiling. | |
| start_date | No | Inclusive observation start date. | |
| update_urls | No | Refresh the RBA table URL list before downloading. | |
| table_numbers | Yes | One or more exact RBA table numbers, such as G1. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| offset | Yes | |
| has_more | Yes | |
| max_rows | Yes | |
| truncated | Yes | |
| total_rows | Yes | |
| returned_rows | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond 'download' (e.g., auth needs, rate limits, or side effects). Given the high annotation coverage, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. Every word adds value, making it concise and efficient.
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?
With an output schema present and high schema coverage, the description is largely complete. However, it could mention the format of returned data or pagination behavior, but these are minor 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?
Schema coverage is 86%, meaning most parameters have descriptions in the schema. The tool description does not add additional semantics beyond what the schema already provides, so baseline 3 is correct.
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 verb 'download', the resource 'RBA statistical tables', and the scope 'current, historical, or both vintages'. It distinguishes from siblings like 'rba_search_tables' which search rather than download.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for downloading tables but does not provide explicit guidance on when to use this tool versus alternatives like 'rba_search_tables' or 'rba_get_series'. No when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search readrba's built-in RBA series catalogue. An omitted query returns all series.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Word or phrase to search for. Omit to return all series. | |
| offset | No | Number of filtered and sorted rows to skip. | |
| max_rows | No | Maximum rows to return. There is no server-side ceiling. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| offset | Yes | |
| has_more | Yes | |
| max_rows | Yes | |
| truncated | Yes | |
| total_rows | Yes | |
| returned_rows | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the key behavioral detail that omitting the query returns all series, which goes beyond annotations and is valuable for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The main purpose and a key default behavior are front-loaded, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core operation and a default behavior, which is adequate for a simple search tool with an output schema. However, it lacks details about search mechanics (e.g., exact match, case sensitivity, boolean operators) that could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description only restates the query parameter's default behavior (already in schema) and adds no new semantics for offset or max_rows.
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 action (search) and the resource (RBA series catalogue). The sibling tool list (e.g., rba_search_tables) helps distinguish this tool from others, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching series but does not explicitly provide guidance on when to use this tool versus alternatives (e.g., rba_search_tables) or when to omit the query. No when-not or conditional advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the RBA table catalogue, including readrba's readable flag. Refresh is off by default.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Word or phrase to search for. Omit to return all tables. | |
| offset | No | Number of filtered and sorted rows to skip. | |
| refresh | No | Scrape the RBA website instead of using readrba's internal list. | |
| max_rows | No | Maximum rows to return. There is no server-side ceiling. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| offset | Yes | |
| has_more | Yes | |
| max_rows | Yes | |
| truncated | Yes | |
| total_rows | Yes | |
| returned_rows | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about the 'readable flag' and that 'refresh is off by default', which provides behavioral detail beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey the tool's purpose and key behavior (readable flag, refresh default) without unnecessary words. The description is front-loaded and efficiently scoped.
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?
With 4 parameters and an output schema, the description is brief but adequate for a simple search tool. However, it does not explain what the 'readable flag' means or how search results are ordered, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mentions the 'readable flag' and that refresh is off by default, but the latter is already in the schema (default: false). No additional semantics are added for parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the RBA table catalogue with a specific verb 'search' and resource 'tables'. It distinguishes from sibling tools like rba_search_series by focusing on tables rather than series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies searching tables but provides no explicit guidance on when to use this tool versus alternatives like rba_search_series. It lacks when-not-to-use instructions or scenarios for alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0rba_get_cash_raterba_get_forecastsrba_get_seriesrba_get_tablerba_search_seriesrba_search_tablesEach tool targets a distinct resource or operation: series vs tables, search vs get, forecasts, cash rate. No overlapping purposes.
All tools follow the consistent pattern rba_<verb>_<noun> (e.g., rba_search_series, rba_get_forecasts), with no deviations.
6 tools is well-scoped for an RBA data retrieval server, covering search, download, and specific data points without excess or deficiency.
The tool set provides comprehensive read access: searching and fetching series and tables, forecasts, and cash rate, with no obvious gaps for the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
RBA MCP — Reserve Bank of Australia statistics (free, no auth).
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Australian Bureau of Statistics (ABS) Data API MCP.
MCP server with quote and live cryptocurrency price tools, local and cloud-deployed transports.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Dominic-Behrens/readrba-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
