Reserve Bank of Australia

Server Quality Checklist

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

Latest release: v0.8.7
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.7/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- Last stable release on May 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the 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.
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 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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
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, 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.
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 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.
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 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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
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: '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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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