Australian economic data from the ABS, RBA, and APRA: CPI, GDP, cash rate, labour, and more.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 14 of 14 tools scored. Lowest: 3.2/5.
Most tools have clear source or function boundaries (ABS, RBA, APRA, derived series, curated concepts, discovery). However, get_derived_series and get_economic_series both retrieve time-series data and could be confused; list_catalogue and search_datasets also overlap in discovery. The descriptions help, but these pairs require careful reading.
All tools follow a consistent lowercase verb_noun pattern with underscores (describe_, get_, list_, search_). Verbs are used predictably: get for retrieval, list for enumeration, search for discovery. No mixed conventions or camelCase.
14 tools is on the higher end but appropriate for a multi-source economic data API covering ABS, RBA, and APRA. The inclusion of a deprecated alias (list_rba_tables) adds slight redundancy, but the overall count is justified by distinct operations.
The surface covers discovery (search_datasets, list_catalogue), metadata (describe_dataset, structure), retrieval (source-specific and curated), and convenience wrappers (latest/top observations). Minor gaps include lack of a unified structure tool for RBA/APRA and no bulk download option, but core read-only workflows are well covered.
describe_datasetDescribe DatasetADescribe a source-native ABS, RBA, or APRA dataset without hiding native IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | Source selector. Use abs for Australian Bureau of Statistics, rba for Reserve Bank of Australia, or apra for Australian Prudential Regulation Authority. | |
| table_id | No | Non-empty dataset or table id. | |
| identifier | Yes | Non-empty dataset or table id. | |
| include_structure | No | Whether ABS descriptions should include source-native structure details. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the behavioral trait 'without hiding native IDs', clarifying that raw identifiers are preserved in the output, which is valuable beyond the schema. It does not mention other behaviors like error handling, but with strong annotations this is acceptable.
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 sentence of 12 words, directly front-loaded with the verb and resource. Every word earns its place; no fluff or redundant information.
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 rich schema (100% parameter coverage), comprehensive annotations, and an output schema, the description is adequate for selecting and invoking the tool. The 'without hiding native IDs' clause is a key differentiator that aids selection among siblings, though it doesn't explicitly explain return structure—covered by the output schema.
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%, with each parameter already described in the input schema. The description itself adds no parameter-specific information beyond referencing the source categories, so it neither compensates nor hinders.
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 uses the specific verb 'Describe' with a clear resource ('source-native ABS, RBA, or APRA dataset') and adds the distinctive clause 'without hiding native IDs', which differentiates it from sibling tools like get_abs_data or get_abs_dataset_structure. This gives a precise 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?
The description implies the tool is used for describing datasets but does not explicitly state when to prefer it over alternatives or any exclusions. Sibling tools like search_datasets or get_abs_dataset_structure are not referenced, leaving usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_abs_dataGet ABS DataBExpert/source-native ABS SDMX retrieval in a normalised response shape.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | ABS SDMX key, or "all" for all series. | all |
| last_n | No | Optional limit returning only the most recent N observations per series; metadata.truncated is true when older observations were dropped. | |
| end_period | No | Optional ABS period bound in YYYY, YYYY-QN, YYYY-MM, or YYYY-SN format. | |
| dataflow_id | Yes | Non-empty dataset or table id. | |
| start_period | No | Optional ABS period bound in YYYY, YYYY-QN, YYYY-MM, or YYYY-SN format. | |
| updated_after | No | Optional ISO date or datetime accepted by the ABS updatedAfter API. | |
| include_observation_dimensions | No | Whether to repeat the full dimension dict on every observation. Off by default because the same dimensions already appear on each series descriptor and are encoded in series_id. |
| Name | Required | Description |
|---|---|---|
| series | Yes | Series descriptors keyed by series_id. |
| metadata | Yes | Source, provenance, cache, and retrieval metadata for this response. |
| observations | Yes | Long-form observations keyed by date and series_id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safe, non-destructive nature is clear. The description adds that the response is 'normalised' and that the tool is 'source-native', which hints at output formatting and integration with ABS specifics, but it does not disclose potential rate limits, error behavior, or interactions between parameters beyond what the schema already notes.
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, concise sentence with no wasted words, making it easy to parse. However, the phrase 'Expert/source-native' is vague and arguably unnecessary, and the extreme brevity leaves out crucial usage context, meaning it sacrifices informativeness for compactness.
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 a rich schema, output schema, and good annotations, the description does not need to restate those details. Yet it fails to provide the 'when to use this' context essential for a tool with many siblings, making the overall package merely adequate rather than 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?
Input schema has 100% coverage, with every parameter offering a meaningful description, so the baseline is 3. The description itself adds no parameter-specific semantics; it does not clarify how 'key', 'last_n', or 'period' interact, but the schema already handles this adequately.
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 uses a specific verb ('retrieval') and resource ('ABS SDMX'), clearly indicating it fetches Australian Bureau of Statistics data via SDMX. However, it does not explicitly differentiate among the many sibling data-retrieval tools, relying on the 'ABS' qualifier to set it apart from APRA/RBA tools but not from other ABS-specific tools like get_latest_observations.
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 no guidance on when to use this tool versus alternatives such as get_apra_data, get_latest_observations, or get_derived_series. There is no mention of prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage solely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_abs_dataset_structureGet ABS Dataset StructureAGet ABS SDMX dataset dimensions and codelists.
| Name | Required | Description | Default |
|---|---|---|---|
| dataflow_id | Yes | Non-empty dataset or table id. |
| Name | Required | Description |
|---|---|---|
| id | No | Resolved ABS data structure identifier. |
| dimensions | No | Dataset dimensions with positions and allowed values. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no additional behavioral context such as return size, error conditions, or dependencies, but with the annotations present, the bar is lower and a neutral score 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 concise sentence that front-loads the core action and resource. Every word adds value, with no redundant or filler content.
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 simplicity (one parameter, output schema present, clear annotations), the description is largely sufficient. It could be more complete by noting that the structure is returned in SDMX format, but the output schema and purpose cover most needs. Minor gap in not hinting at the tool's relationship to other ABS-specific tools.
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%, with dataflow_id described as 'Non-empty dataset or table id.' The description adds no extra meaning beyond the schema's own parameter description, so the baseline score of 3 applies.
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 uses a specific verb 'Get' and clearly identifies the resource 'ABS SDMX dataset dimensions and codelists'. This distinguishes it from sibling tools like get_abs_data (which presumably returns data) and describe_dataset (which may describe datasets generically).
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 the tool is for obtaining structural metadata for an ABS dataset, but it does not explicitly state when to use this versus alternatives or provide exclusions. No comparison to sibling tools or guidance on prerequisites beyond the required dataflow_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_apra_dataGet APRA DataAExpert/source-native APRA public XLSX publication retrieval.
Only curated official APRA publication IDs are accepted; arbitrary URLs are not.
| Name | Required | Description | Default |
|---|---|---|---|
| last_n | No | Optional limit returning only the most recent N observations per series; metadata.truncated is true when older observations were dropped. | |
| end_date | No | Optional ISO date bound in YYYY-MM-DD format. | |
| table_id | No | Non-empty dataset or table id. | |
| series_ids | No | Optional list of non-empty source-native series IDs to keep after download. | |
| start_date | No | Optional ISO date bound in YYYY-MM-DD format. | |
| publication_id | Yes | Non-empty dataset or table id. | |
| include_observation_dimensions | No | Whether to repeat the full dimension dict on every observation. Off by default because the same dimensions already appear on each series descriptor and are encoded in series_id. |
| Name | Required | Description |
|---|---|---|
| series | Yes | Series descriptors keyed by series_id. |
| metadata | Yes | Source, provenance, cache, and retrieval metadata for this response. |
| observations | Yes | Long-form observations keyed by date and series_id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds context about source-native XLSX retrieval and the curated-ID restriction, but it does not disclose behaviors like pagination, error handling, or data format beyond what the schema already implies. This is adequate but not rich.
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 short (two sentences) and front-loaded with the core purpose. The phrase 'Expert/source-native' is somewhat vague and could be clearer, but overall it is concise with no redundant filler. It earns a high score for efficiency, though not perfect due to slightly ambiguous jargon.
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 rich input schema, output schema presence, and strong annotations, the description is sufficient for a high-level understanding. It communicates the essential purpose and the key input restriction. It lacks explicit guidance on when to prefer this tool over siblings, but the overall context makes it usable.
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 input schema fully documents each parameter. The description adds one relevant semantic constraint: only curated official APRA publication IDs are accepted, reinforcing the 'publication_id' parameter and excluding arbitrary URLs. However, it does not clarify any other parameters, so it stays at the baseline for full schema 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's purpose as 'APRA public XLSX publication retrieval,' specifying the resource (APRA publications) and the action (retrieval). This distinguishes it from sibling tools focused on ABS or RBA data, making its scope 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 does not explicitly state when to use this tool versus alternatives. It only imposes an input restriction ('Only curated official APRA publication IDs are accepted; arbitrary URLs are not'), which is a constraint rather than usage guidance. Sibling tools are not mentioned, so an agent receives no comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_derived_seriesGet Derived SeriesARead-only retrieval for the narrow transparent derived series layer.
Date bounds accept YYYY, YYYY-QN, YYYY-SN, YYYY-MM, or YYYY-MM-DD and are normalised to the derived series frequency.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Optional analyst-friendly bound for a derived series: YYYY, YYYY-QN, YYYY-SN, YYYY-MM, or YYYY-MM-DD. Bounds are normalised to the derived series frequency. | |
| start | No | Optional analyst-friendly bound for a derived series: YYYY, YYYY-QN, YYYY-SN, YYYY-MM, or YYYY-MM-DD. Bounds are normalised to the derived series frequency. | |
| last_n | No | Optional limit returning only the most recent N observations per series; metadata.truncated is true when older observations were dropped. | |
| concept | Yes | Derived concept name. |
| Name | Required | Description |
|---|---|---|
| series | Yes | Series descriptors keyed by series_id. |
| metadata | Yes | Source, provenance, cache, and retrieval metadata for this response. |
| observations | Yes | Long-form observations keyed by date and series_id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by explaining that date bounds accept specific formats and are 'normalised to the derived series frequency,' which is useful beyond the schema. It does not contradict 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?
The description is extremely concise: two sentences that immediately state the tool's purpose and then provide the key date-bound behavior. Every sentence serves a purpose, with no filler or redundancy.
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 an output schema and rich annotations, the description is sufficient for a simple read-only retrieval tool. It covers the notable normalization behavior, but does not define what 'derived series' means or when to choose it over economic series; however, sibling context and schema partially compensate.
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%, with the schema already describing start, end, last_n, and concept. The description's note about date format normalization partially matches the schema's parameter descriptions but adds no new semantic detail beyond what is already structured. It is adequate but does not elevate above the baseline.
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 states 'Read-only retrieval for the narrow transparent derived series layer,' which identifies a specific verb (retrieval) and resource (derived series), and the phrase 'derived series' distinguishes it from siblings like get_economic_series. It is not a tautology, though the terms 'narrow' and 'transparent' are somewhat vague and do not fully clarify the exact scope.
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 by calling it 'read-only retrieval' and mentions the 'derived series layer,' suggesting it is for derived-series data. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_economic_seriesGet Economic SeriesAPreferred analyst-facing retrieval tool for curated ABS/RBA economic concepts.
Use list_economic_concepts for discovery. Date bounds accept YYYY, YYYY-QN, YYYY-SN, YYYY-MM, or YYYY-MM-DD and are normalised to the resolved source.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Optional analyst-friendly date bound: YYYY, YYYY-QN, YYYY-SN, YYYY-MM, or YYYY-MM-DD. Semantic retrieval normalises this to the resolved source frequency. | |
| start | No | Optional analyst-friendly date bound: YYYY, YYYY-QN, YYYY-SN, YYYY-MM, or YYYY-MM-DD. Semantic retrieval normalises this to the resolved source frequency. | |
| last_n | No | Optional limit returning only the most recent N observations per series; metadata.truncated is true when older observations were dropped. | |
| concept | Yes | Curated semantic concept name. | |
| variant | No | Optional curated concept variant, such as headline, underlying, or target. | |
| frequency | No | Optional requested frequency for a curated concept, such as monthly, quarterly, or annual. | |
| geography | No | Optional geography selector for a curated concept, usually aus for Australia. | |
| include_observation_dimensions | No | Whether to repeat the full dimension dict on every observation. Off by default because the same dimensions already appear on each series descriptor and are encoded in series_id. |
| Name | Required | Description |
|---|---|---|
| series | Yes | Series descriptors keyed by series_id. |
| metadata | Yes | Source, provenance, cache, and retrieval metadata for this response. |
| observations | Yes | Long-form observations keyed by date and series_id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context about date normalization ('normalised to the resolved source') and emphasizes it is analyst-facing, which helps set expectations beyond annotation hints.
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 two short paragraphs, front-loaded with purpose, then a discovery pointer, then the key date format detail. Every sentence adds value and there is no redundant filler.
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 a rich output schema, thorough parameter descriptions, and comprehensive annotations, the description is complete. It covers the primary use case, directs to discovery, and highlights the most critical behavioral nuance (date normalization). No significant gaps remain for an analyst-facing retrieval 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 100% with detailed parameter descriptions (e.g., date formats, last_n truncation semantics). The description repeats some of this information (date format) but does not add meaning beyond what the schema already provides. Baseline 3 is appropriate.
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 identifies the tool as the 'Preferred analyst-facing retrieval tool for curated ABS/RBA economic concepts', specifying both the action (retrieval) and the resource (curated concepts). It distinguishes itself from siblings by positioning it as preferred and referencing discovery via list_economic_concepts.
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?
It explicitly directs users to 'Use list_economic_concepts for discovery', providing an alternative for a related task. The phrase 'Preferred analyst-facing retrieval tool' implies when to choose this tool over others, though it doesn't detail when not to use tools like get_derived_series or get_abs_data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_latest_observationsGet Latest ObservationsASource-aware convenience wrapper for the latest observations.
For a single curated indicator prefer get_economic_series(concept=...), which resolves one series; pass series_ids=[...] to narrow a broad dataset instead of returning every series it contains.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | ABS SDMX key, or "all" for all series. | all |
| count | No | Number of most recent observations to return per series; metadata.truncated is true when older observations were dropped. | |
| source | Yes | Source selector. Use abs for Australian Bureau of Statistics, rba for Reserve Bank of Australia, or apra for Australian Prudential Regulation Authority. | |
| table_id | No | Non-empty dataset or table id. | |
| identifier | Yes | Non-empty dataset or table id. | |
| series_ids | No | Optional list of non-empty source-native series IDs to keep after download. |
| Name | Required | Description |
|---|---|---|
| series | Yes | Series descriptors keyed by series_id. |
| metadata | Yes | Source, provenance, cache, and retrieval metadata for this response. |
| observations | Yes | Long-form observations keyed by date and series_id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds behavioral context by noting it is a 'convenience wrapper' and that without series_ids it returns every series in the dataset, which is useful beyond the annotations. No contradictions with 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?
The description is two sentences long, front-loaded with the core purpose and followed by targeted usage guidance. Every sentence earns its place, and there is no repetition of schema or annotation content.
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 and rich annotations, the description need not explain return values or safety. It covers the key alternative (get_economic_series) and the series_ids narrowing behavior, which are the most important decisions for an agent. It is slightly sparse on distinctions from other siblings like get_top_observations, but adequate given the schema coverage.
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 input schema provides 100% parameter description coverage, so the baseline is 3. The description goes further by explaining the semantic role of series_ids—narrowing a broad dataset instead of returning every series—and by advising get_economic_series for single-indicator concepts. This adds value beyond the structured 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 identifies this as a 'source-aware convenience wrapper' for retrieving the latest observations, with the name and title reinforcing the purpose. It also distinguishes itself by recommending get_economic_series for single curated indicators. However, it relies on the metaphorical 'wrapper' phrasing rather than a direct verb+resource statement.
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 explicitly tells the agent to prefer get_economic_series(concept=...) for a single curated indicator and advises passing series_ids=[...] to narrow a broad dataset instead of returning every series. This provides a clear when-not and alternative while implying the tool's own use case for broad, source-aware latest observations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_rba_tableGet RBA TableBExpert/source-native RBA statistical table retrieval in a normalised response shape.
| Name | Required | Description | Default |
|---|---|---|---|
| last_n | No | Optional limit returning only the most recent N observations per series; metadata.truncated is true when older observations were dropped. | |
| end_date | No | Optional ISO date bound in YYYY-MM-DD format. | |
| table_id | Yes | Non-empty dataset or table id. | |
| series_ids | No | Optional list of non-empty source-native series IDs to keep after download. | |
| start_date | No | Optional ISO date bound in YYYY-MM-DD format. | |
| include_observation_dimensions | No | Whether to repeat the full dimension dict on every observation. Off by default because the same dimensions already appear on each series descriptor and are encoded in series_id. |
| Name | Required | Description |
|---|---|---|
| series | Yes | Series descriptors keyed by series_id. |
| metadata | Yes | Source, provenance, cache, and retrieval metadata for this response. |
| observations | Yes | Long-form observations keyed by date and series_id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds that the response shape is 'normalised', which is a useful behavioral trait, but it does not disclose other behaviors like truncation or pagination beyond what the schema already documents.
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 concise sentence with no wasted words. It front-loads the purpose and does not pad with irrelevant details.
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 rich input schema (100% parameter descriptions), output schema, and comprehensive annotations, the description is sufficient for a read-only retrieval tool. It lacks some usage context, but the missing guidance is not critical for basic invocation correctness.
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 adds no parameter-specific meaning; all parameter semantics are already carried by the input 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 the tool retrieves RBA statistical tables, with the verb 'retrieval' and resource 'RBA statistical table'. The RBA prefix distinguishes it from sibling tools like get_abs_data and get_apra_data, though the phrase 'Expert/source-native' adds a bit of ambiguity.
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 guidance is given on when to use this tool versus alternatives such as get_abs_data or get_apra_data. It does not mention any exclusions, prerequisites, or explicit selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_top_observationsGet Top ObservationsASource-aware convenience wrapper for highest or lowest numeric observations.
For a single curated indicator prefer get_economic_series(concept=...), which resolves one series; pass series_ids=[...] to narrow a broad dataset instead of returning every series it contains.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | Positive observation count. | |
| key | No | ABS SDMX key, or "all" for all series. | all |
| source | Yes | Source selector. Use abs for Australian Bureau of Statistics, rba for Reserve Bank of Australia, or apra for Australian Prudential Regulation Authority. | |
| end_date | No | Optional ISO date bound in YYYY-MM-DD format. | |
| table_id | No | Non-empty dataset or table id. | |
| direction | No | Whether to return the highest or lowest numeric observations. | highest |
| end_period | No | Optional ABS period bound in YYYY, YYYY-QN, YYYY-MM, or YYYY-SN format. | |
| identifier | Yes | Non-empty dataset or table id. | |
| series_ids | No | Optional list of non-empty source-native series IDs to keep after download. | |
| start_date | No | Optional ISO date bound in YYYY-MM-DD format. | |
| start_period | No | Optional ABS period bound in YYYY, YYYY-QN, YYYY-MM, or YYYY-SN format. |
| Name | Required | Description |
|---|---|---|
| series | Yes | Series descriptors keyed by series_id. |
| metadata | Yes | Source, provenance, cache, and retrieval metadata for this response. |
| observations | Yes | Long-form observations keyed by date and series_id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, open-world, and non-destructive. The description adds useful behavioral context by warning that omitting series_ids on a broad dataset returns every series it contains, which is valuable for managing response size. It does not describe output format or pagination, but the annotation coverage lowers the burden.
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 compact, front-loaded with the tool's purpose, and uses a short second paragraph for guidance. Every sentence contributes meaningful information without repetition or filler.
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 rich input schema, presence of an output schema, and strong annotations, the description provides the necessary orientation and key caveat. It is sufficient for an agent to understand when to invoke this tool and how to avoid an overly broad result.
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?
All 11 parameters are described in the schema, so the baseline is 3. The description adds extra semantic value by explaining the practical effect of series_ids—narrowing a broad dataset instead of returning all series—which goes beyond the schema's 'keep after download' phrasing.
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 identifies the tool as a source-aware convenience wrapper for returning the highest or lowest numeric observations. It also distinguishes itself from get_economic_series by noting when to prefer the alternative, satisfying the differentiation criterion.
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?
It explicitly instructs users to prefer get_economic_series for a single curated indicator and advises passing series_ids=[...] to avoid returning every series in a broad dataset. This provides clear when-to-use and when-not-to-use guidance beyond just stating purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_catalogueList CatalogueAList curated ABS, RBA, and APRA catalogue entries, optionally filtered by source,
category, or tag. Unranked complement to search_datasets.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Optional curated catalogue tag filter. | |
| source | No | Optional source filter. Use abs for Australian Bureau of Statistics, rba for Reserve Bank of Australia, or apra for Australian Prudential Regulation Authority. | |
| category | No | Optional curated catalogue or semantic concept category filter. | |
| include_ceased | No | Whether to include ceased ABS catalogue entries. | |
| include_discontinued | No | Whether to include discontinued RBA catalogue entries. |
| Name | Required | Description |
|---|---|---|
| result | Yes | Curated ABS, RBA, and APRA catalogue entries. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, and the description adds useful behavioral context: the results are 'curated', limited to ABS/RBA/APRA sources, and 'unranked' compared to search. This goes beyond the structured annotations without contradicting them, though it does not detail pagination or response shape.
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 concise sentences deliver the core purpose, scope, filters, and the key differentiator from a sibling tool. Every word earns its place, and the most important information is front-loaded.
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 an output schema and rich annotations, the description sufficiently covers purpose, scope, filter options, and relationship to the alternative search tool. It is complete for a simple filtered-list operation, and no critical behavioral gaps remain.
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?
All five parameters are fully documented in the schema (100% coverage), so the baseline applies. The description mentions source/category/tag filters but adds no additional meaning beyond the schema; the include_ceased and include_discontinued parameters are covered entirely by schema descriptions.
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 uses a specific verb ('List') and a clear resource ('curated ABS, RBA, and APRA catalogue entries'), and it explicitly distinguishes itself from the sibling tool 'search_datasets' by calling itself an 'Unranked complement'. This makes the tool's purpose immediately clear and resolves ambiguity among related list/search tools.
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 states the supported filter dimensions ('source, category, or tag') and frames the tool as the unranked counterpart to 'search_datasets', which implies when to choose this tool versus a ranked search. This is clear usage guidance even though it does not enumerate formal exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_economic_conceptsList Economic ConceptsAList analyst-friendly semantic economic concepts accepted by get_economic_series.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional query for filtering semantic economic concepts. | |
| source | No | Optional source filter. Use abs for Australian Bureau of Statistics, rba for Reserve Bank of Australia, or apra for Australian Prudential Regulation Authority. | |
| category | No | Optional curated catalogue or semantic concept category filter. |
| Name | Required | Description |
|---|---|---|
| result | Yes | Curated semantic economic concepts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the relationship to get_economic_series but does not elaborate on filtering behavior or response format, which is acceptable given 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?
The description is a single, focused sentence that delivers the essential information without any filler. Every word contributes to understanding the tool's purpose.
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?
For a read-only listing tool with three optional parameters and an output schema, the description provides sufficient context by linking to get_economic_series. It could mention the openWorldHint dynamic nature or filter usage, but these are already covered by annotations and schema.
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% with meaningful descriptions for all three parameters (query, source, category). The description adds no additional parameter-specific meaning beyond what the schema provides, so the baseline 3 applies.
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 lists analyst-friendly semantic economic concepts accepted by get_economic_series. This specific verb-resource pairing distinguishes it from sibling tools that fetch data (e.g., get_economic_series) or list catalogue tables.
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 the tool is a reference for valid concepts to use with get_economic_series, providing clear context on when to use it. However, it does not explicitly contrast it with sibling tools like list_catalogue or search_datasets, nor mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_rba_tablesList RBA TablesADeprecated compatibility alias. Prefer list_catalogue(source="rba").
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional RBA catalogue category filter. | |
| include_discontinued | No | Whether to include discontinued RBA catalogue entries. |
| Name | Required | Description |
|---|---|---|
| result | Yes | Curated RBA table catalogue entries. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds the important behavioral facts that the tool is deprecated and a compatibility alias, which are not present in the annotations. It does not add details about return formats or parameter behavior, but the existing annotation coverage is strong, making this additional context valuable.
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 that immediately communicates deprecation and the preferred replacement. Every word earns its place, with no redundant filler.
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 comprehensive annotations and an output schema, the description only needs to signal deprecation and provide the migration path, which it does succinctly. The alias relationship means the tool's behavior is fully defined by list_catalogue, so the context is complete for a deprecated 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 input schema provides descriptions for 100% of parameters (category and include_discontinued), so the baseline is 3. The description itself adds no new parameter-level details; the alias note only hints that the parameters correspond to list_catalogue, but this is not explicit. Therefore, it does not enhance semantic understanding beyond the 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 explicitly labels the tool as a 'Deprecated compatibility alias' for list_catalogue with source='rba', which clearly indicates it lists RBA tables. The title 'List RBA Tables' reinforces the resource and scope. This also distinguishes it from siblings by naming the preferred alternative.
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 directly instructs to 'Prefer list_catalogue(source="rba")', which is explicit guidance on which tool to use instead. This is a clear when-to-use/alternative directive, leaving no ambiguity about optimal usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_release_eventsList Release EventsBList source-aware release calendar or release-pulse events.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Positive observation count. | |
| query | No | Optional query for filtering semantic economic concepts. | |
| source | No | Optional source filter. Use abs for Australian Bureau of Statistics, rba for Reserve Bank of Australia, or apra for Australian Prudential Regulation Authority. | |
| end_date | No | Optional ISO date bound in YYYY-MM-DD format. | |
| start_date | No | Optional ISO date bound in YYYY-MM-DD format. |
| Name | Required | Description |
|---|---|---|
| result | Yes | ABS, RBA, and APRA release calendar events. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds the 'source-aware' behavior, but it does not provide additional context such as default date ranges, pagination, or how events are ordered. Given strong annotation coverage, this is adequate but not rich.
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 filler words. It efficiently conveys the core function, meeting the standard for optimal 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?
Given the simple list operation with all parameters optional and an output schema available, the description is sufficiently complete. It lacks an explanation of 'release-pulse' jargon, but the core functionality is clear. This is adequate for a straightforward list 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?
All five parameters have descriptions in the schema (100% coverage), so the schema carries the burden. The description only mentions 'source-aware' in passing, adding no new meaning beyond what the source parameter already states. Baseline 3 is appropriate.
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 uses the specific verb 'List' and identifies the resource as 'source-aware release calendar or release-pulse events,' which clearly distinguishes this tool from sibling listing tools like list_catalogue. However, it does not explicitly name or contrast with siblings, and 'release-pulse' is somewhat cryptic.
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 no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria. The phrase 'source-aware' suggests filtering by source, but there is no stated context or comparison with sibling tools like search_datasets or get_latest_observations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_datasetsSearch DatasetsASearch curated ABS, RBA, and APRA economic datasets.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Discovery query text. | |
| source | No | Optional source filter. Use abs for Australian Bureau of Statistics, rba for Reserve Bank of Australia, or apra for Australian Prudential Regulation Authority. |
| Name | Required | Description |
|---|---|---|
| result | Yes | Ranked ABS, RBA, and APRA catalogue search results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds minimal context like 'curated' suggesting a limited dataset set, but doesn't describe result behavior, pagination, or matching semantics. No contradiction with 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?
The description is a single sentence that front-loads the action ('Search') and scope ('curated ABS, RBA, and APRA economic datasets'). Every word earns its place with no redundancy.
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?
For a simple search tool, the description is largely sufficient given that annotations cover safety and the output schema covers return values. However, it omits details about search behavior (e.g., exact vs. fuzzy matching) and could briefly indicate when to prefer this over list_catalogue, which would 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?
The input schema has 100% description coverage for both parameters, with query described as 'Discovery query text' and source explaining each enum value. The description adds no additional parameter semantics beyond what the schema already 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 the tool searches curated economic datasets from ABS, RBA, and APRA, using a specific verb and resource scope. While it doesn't explicitly contrast with sibling tools, the 'Search' verb and the named sources distinguish it sufficiently from retrieval tools like get_abs_data or list_catalogue.
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?
There is no explicit guidance on when to use this tool versus alternatives. The description implies it is for searching datasets by query, but does not mention when to use list_catalogue or how it differs from specific data retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.