Skip to main content
Glama
enesjakozh
seansoreilly

Australian Bureau of Statistics (ABS)

by seansoreilly
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

ABS MCP サーバー

オーストラリア統計局（ABS）データAPIへのアクセスを提供するMCP（モデルコンテキストプロトコル）サーバー。このサーバーにより、AIアシスタントはSDMX-ML APIを介してABS統計データを照会および分析できます。

特徴

  • SDMX-ML API を介して利用可能なすべての ABS データセットを動的に検出します。

  • オプションのフィルターを使用して ABS データセットをクエリする

  • 複数のデータ形式（JSON、CSV、XML）のサポート

  • AIアシスタントとのシームレスな統合を実現するMCPプロトコルを基盤に構築

  • パフォーマンス向上のためのキャッシュシステム

  • 包括的なログ記録とエラー処理

Related MCP server: Australian Bureau of Statistics

インストール

npm install

発達

前提条件

  • Node.js 18以上

  • npm 8以上

建物

npm run build

ランニング

npm start

開発ツール

  • npm run build : TypeScriptコードをビルドする

  • npm start : サーバーを実行する

  • npm run inspector : テスト用にMCPインスペクタを実行する

プロジェクト構造

src/
├── index.ts                # Main server implementation
├── services/
│   └── abs/
│       ├── ABSApiClient.ts # ABS API communication
│       └── DataFlowService.ts # Data flow management and caching
├── types/
│   └── abs.ts             # TypeScript type definitions
└── utils/
    └── logger.ts          # Logging configuration

実装の詳細

ABS APIクライアント

ABSApiClientクラスは、ABS データ API との通信を処理します。

  • データ交換にはSDMX-ML形式を使用します

  • 複数の応答形式（JSON、CSV、XML）をサポート

  • 適切なエラー処理とログ記録を実装する

  • 設定可能なタイムアウトと再試行

データフローサービス

DataFlowServiceクラスは ABS データ フローを管理します。

  • ABS APIから利用可能なデータセットを動的に取得します

  • 設定可能な更新間隔でキャッシュを実装します

  • 特定のデータセットをクエリするためのメソッドを提供する

  • データの変換とフォーマットを処理する

ログ記録

Winston を使用した包括的なログ記録システム:

  • 開発のためのデバッグレベルのログ

  • 構造化されたJSONログ形式

  • コンソールとファイル転送オプション

  • 設定可能なログレベルとフォーマット

Claude Desktopとの統合

  1. Claude Desktop が実行中の場合は閉じます

  2. ABS MCPサーバーを起動します: npm start

  3. Claudeデスクトップを起動

  4. ABSツールは「利用可能なMCPツール」ウィンドウに表示されます。

APIドキュメント

ABS データ API の詳細については、以下をご覧ください。

貢献

  1. リポジトリをフォークする

  2. 機能ブランチを作成する

  3. 変更を加える

  4. プルリクエストを送信する

ライセンス

MITライセンス

Available Tools

1 tool
query_datasetC

Query a specific ABS dataset with optional filters

ParametersJSON Schema
NameRequiredDescriptionDefault
datasetIdYesID of the dataset to query (e.g., C21_G01_LGA)

TDQS

C2.6/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'query' but doesn't clarify if this is a read-only operation, what permissions are needed, potential rate limits, or the response format. The mention of 'optional filters' adds some context, but critical behavioral traits like safety, performance, or output characteristics are missing, leaving significant gaps.

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 a single, clear sentence that efficiently conveys the core action and key feature (optional filters). It's front-loaded with the main purpose and avoids unnecessary words. However, it could be slightly more informative without losing conciseness, such as hinting at the query's output or data scope.

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

Completeness2/5

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

Given the tool's complexity (a query operation with potential filters), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what the query returns (e.g., raw data, aggregated results), how filters are applied, or any constraints. For a tool that likely involves data retrieval and processing, more context is needed to ensure proper usage.

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?

The description adds minimal value beyond the input schema, which has 100% coverage for the single parameter 'datasetId'. It implies filtering is possible but doesn't detail how filters work or their syntax. With high schema coverage, the baseline is 3, as the schema already documents the parameter adequately, and the description doesn't significantly enhance understanding of parameter usage or semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action ('query') and target ('ABS dataset'), which provides a basic understanding of purpose. However, it's vague about what 'query' entails (e.g., retrieving data, statistics, or metadata) and doesn't specify resource scope beyond 'dataset'. With no siblings, differentiation isn't needed, but the purpose lacks specificity beyond general terms.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions 'optional filters' as a usage hint, implying it can be used with or without filtering. However, it provides no guidance on when to use this tool (e.g., for data analysis vs. other operations) or any prerequisites. With no sibling tools, alternatives aren't relevant, but the lack of contextual guidance results in minimal assistance for decision-making.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.0.0
    • First observedquery_dataset
Deploy Server
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

TDQS

C2.9/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is clearly defined as querying ABS datasets with filters, making it distinct by default.

Naming Consistency5/5

Since there is only one tool, naming consistency is inherently perfect. The tool name 'query_dataset' follows a clear verb_noun pattern, which would be consistent if more tools were added.

Tool Count2/5

A single tool is too few for a server representing a national statistics bureau, which likely has multiple datasets, metadata operations, or data retrieval methods. This minimal scope feels thin and inadequate for the apparent domain.

Completeness2/5

The tool surface is severely incomplete for accessing ABS data. There are obvious gaps such as listing available datasets, retrieving metadata, or supporting other common statistical operations, which will limit agent functionality.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • ausdata-mcp

    Bigred97
    A
    license
    A
    quality
    F
    maintenance
    Cited Australian stats via the ausdata.io gateway — stable AU.* series IDs, source_url + retrieved_at on every response. Free tier. Not a data broker; upgrade for Embed / signed / webhooks.
    28
    46 npm
    2
    MIT

  • abs

    RonanLION
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables an MCP client to discover ABS datasets, inspect SDMX dimension order and codelists, and run bounded statistical-data queries against the Australian Bureau of Statistics Data API.
    MIT

Appeared in Searches