Skip to main content
Glama
Sign In

Rba

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Rba Series

rba_series
Read-onlyIdempotent

Fetch any RBA statistical series — pass a NAME or description in series (e.g. "90-day bank bill rate", "3-year government bond yield") and it resolves the table + series id for you by fuzzy-matching series titles/descriptions across the RBA catalog (the interest-rate and bond-yield tables are searched first), the same way rba_list_series does. Returns recent observations — or every observation in a window when you pass start_date/end_date (YYYY-MM-DD) — plus resolved_from/resolved_to showing what the name resolved to, or a candidates list if the name is ambiguous — never guesses a made-up id. Or pass table+series_id directly if you already know them exactly (CPI is g1, monetary aggregates d3, cash rate target is FIRMMCRT in f1.1, etc.). Use rba_cash_rate / rba_exchange_rates for those specific common series.

Input Schema

NameRequiredDescriptionDefault
tableNoRBA table id, e.g. "f1.1" (money market), "f2.1" (bond yields), "f11.1" (FX), "g1" (CPI), "d3" (monetary aggregates). Optional: narrows `series` resolution to this table; required alongside series_id for the exact legacy path.
recentNoRecent observations to return (1-120, default 12). Ignored when start_date/end_date is set, unless given explicitly.
seriesNoA series NAME/description to resolve (e.g. "90-day bank bill rate", "3-year government bond yield") OR an exact series id (e.g. "FIRMMBAB90"). Preferred over table+series_id — resolves the id for you and returns resolved_from/resolved_to (or candidates if ambiguous).
end_dateNoOptional YYYY-MM-DD: return only observations on or before this date (e.g. "2025-12-31").
series_idNoLegacy: exact RBA series id within `table`, e.g. "FIRMMCRT" (cash rate target), "FXRUSD" (A$/USD). Prefer `series`, which accepts a name and resolves this for you.
start_dateNoOptional YYYY-MM-DD: return only observations on or after this date (e.g. "2025-09-10"). With a date range, every observation in the range is returned (up to 1000), not just the latest `recent`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / examples
      Previous value: -[
-  {
-    "series": "90-day bank bill rate"
-  },
-  {
-    "series": "3-year government bond yield"
-  },
-  {
-    "recent": 36,
-    "series_id": "DMAM3N",
-    "table": "d3"
-  }
-]New value: +[
+  {
+    "series": "90-day bank bill rate"
+  },
+  {
+    "series": "3-year government bond yield"
+  },
+  {
+    "recent": 36,
+    "series_id": "DMAM3N",
+    "table": "d3"
+  },
+  {
+    "end_date": "2025-12-31",
+    "series_id": "FXRUSD",
+    "start_date": "2025-09-10",
+    "table": "f11.1"
+  }
+]
    • addedInput schema / properties / end_date
      Added value: +{
+  "description": "Optional YYYY-MM-DD: return only observations on or before this date (e.g. \"2025-12-31\").",
+  "type": "string"
+}
    • changedInput schema / properties / recent / description
      Previous value: -"Recent observations to return (1-120, default 12)."New value: +"Recent observations to return (1-120, default 12). Ignored when start_date/end_date is set, unless given explicitly."
    • addedInput schema / properties / start_date
      Added value: +{
+  "description": "Optional YYYY-MM-DD: return only observations on or after this date (e.g. \"2025-09-10\"). With a date range, every observation in the range is returned (up to 1000), not just the latest `recent`.",
+  "type": "string"
+}
  2. Changed5 schema fields changed
    • changedInput schema / examples
      Previous value: -[
-  {
-    "series_id": "ACPI",
-    "table": "g1"
-  },
-  {
-    "recent": 36,
-    "series_id": "DMNRNON",
-    "table": "d3"
-  }
-]New value: +[
+  {
+    "series": "90-day bank bill rate"
+  },
+  {
+    "series": "3-year government bond yield"
+  },
+  {
+    "recent": 36,
+    "series_id": "DMAM3N",
+    "table": "d3"
+  }
+]
    • addedInput schema / properties / series
      Added value: +{
+  "description": "A series NAME/description to resolve (e.g. \"90-day bank bill rate\", \"3-year government bond yield\") OR an exact series id (e.g. \"FIRMMBAB90\"). Preferred over table+series_id — resolves the id for you and returns resolved_from/resolved_to (or candidates if ambiguous).",
+  "type": "string"
+}
    • changedInput schema / properties / series_id / description
      Previous value: -"RBA series id within the table, e.g. \"FIRMMCRT\" (cash rate target), \"FXRUSD\" (A$/USD). Unsure? Call rba_list_series first."New value: +"Legacy: exact RBA series id within `table`, e.g. \"FIRMMCRT\" (cash rate target), \"FXRUSD\" (A$/USD). Prefer `series`, which accepts a name and resolves this for you."
    • changedInput schema / properties / table / description
      Previous value: -"RBA table id, e.g. \"f1.1\" (money market), \"f11.1\" (FX), \"g1\" (CPI), \"d3\" (monetary aggregates). Unsure? Call rba_list_series first."New value: +"RBA table id, e.g. \"f1.1\" (money market), \"f2.1\" (bond yields), \"f11.1\" (FX), \"g1\" (CPI), \"d3\" (monetary aggregates). Optional: narrows `series` resolution to this table; required alongside series_id for the exact legacy path."
    • changedInput schema / required
      Previous value: -[
-  "table",
-  "series_id"
-]New value: +[]
  3. Changed2 schema fields changed
    • changedInput schema / properties / series_id / description
      Previous value: -"RBA series id within the table, e.g. \"FIRMMCRT\" (cash rate target), \"FXRUSD\" (A$/USD)."New value: +"RBA series id within the table, e.g. \"FIRMMCRT\" (cash rate target), \"FXRUSD\" (A$/USD). Unsure? Call rba_list_series first."
    • changedInput schema / properties / table / description
      Previous value: -"RBA table id, e.g. \"f1.1\" (money market), \"f11.1\" (FX), \"g1\" (CPI), \"d3\" (monetary aggregates)."New value: +"RBA table id, e.g. \"f1.1\" (money market), \"f11.1\" (FX), \"g1\" (CPI), \"d3\" (monetary aggregates). Unsure? Call rba_list_series first."
  4. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "series_id": "ACPI",
+    "table": "g1"
+  },
+  {
+    "recent": 36,
+    "series_id": "DMNRNON",
+    "table": "d3"
+  }
+]
  5. First observed

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: fuzzy-matching order (interest-rate and bond-yield tables searched first), ambiguity yields a `candidates` list rather than a guess, resolved_from/resolved_to are returned, and date ranges return every observation up to 1000 rather than only `recent`. This is exactly the kind of resolution/limit behavior an agent needs before calling.

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?

One dense paragraph, front-loaded with the primary path and followed by the exact-id path and exclusions. It is slightly run-on with stacked parentheticals, but nearly every clause carries routing or resolution information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

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

For a 6-parameter, no-required, no-output-schema tool, the description explains both input paths and the return shape (recent observations, resolved_from/resolved_to, candidates on ambiguity, 1000-observation cap). Remaining gaps are minor: units/format of observations and error behavior for an invalid table id are not stated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter is already documented in the schema, including the `series`-preferred-over-table+series_id relationship. The description's added value is mostly repeated examples (g1, d3, FIRMMCRT) that also appear in the schema, so the baseline 3 applies.

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?

States a specific verb and resource (fetch any RBA statistical series) plus the two supported invocation paths (name resolution vs. exact table+series_id). It explicitly names the sibling tools it is not (rba_cash_rate, rba_exchange_rates, and the rba_list_series behavior it mirrors), so an agent can route without opening other schemas.

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?

Gives explicit when-to-use guidance: prefer `series` for name resolution, use table+series_id only when the id is known exactly, and use rba_cash_rate / rba_exchange_rates for those specific common series instead. Both exclusion and alternative are stated outright.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Rba toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources