sdmx-data-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_servicesA | List the SDMX services this server can query. Any SDMX-REST v2 base URL also works: pass it as the service argument to any other tool. The service must return structural metadata as SDMX-JSON 2.0.0 and data as SDMX-CSV. Returns: The known services, with capability notes for each. |
| search_dataflowsA | Find dataflows (datasets) matching a topic. Issues exactly one request to the service and matches the terms locally, so searching for synonyms costs nothing extra: put them all in one query rather than calling this repeatedly. Returns: Matching dataflows, each with a ref to pass to the next tool. Raises: ToolError: If the service is unknown or the request fails. The message carries a [kind] discriminator and a retry hint. |
| inspect_dataflowA | Inspect a dataflow's components, available codes and size. Call this before get_data. It answers three questions: what can I filter on, which codes actually have data, and is this small enough to retrieve? If you only need to know whether data exist for some subset, pass filters and stop here rather than going on to get_data. Returns: Components grouped by role, availability-backed codes, and size signals with a warning when retrieval would truncate. Raises: ToolError: If the dataflow is not found or the request fails. |
| get_dataA | Retrieve observations as records. This returns the actual numbers. Call inspect_dataflow first to confirm component and code IDs and to check the size of what you are about to pull. If a TIME_PERIOD clause is rejected by the service, it is retried without that clause and the cutoff is applied locally; the response says so in filter_fallback. Returns: The observations, the filter actually sent, and a truncated flag. When truncated, the rows are the first N in service order and are NOT a representative sample. Raises: ToolError: If retrieval fails. The message carries a [kind] discriminator and a retry hint. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool maps to a distinct stage of an SDMX query workflow: discovering services, finding dataflows, inspecting a dataflow, and fetching data. There is no overlap in purpose, and the descriptions explicitly position each tool relative to the next.
All tool names follow a consistent verb_noun snake_case pattern: list_services, search_dataflows, inspect_dataflow, get_data. The minor singular/plural variation between dataflows and dataflow is natural and does not create confusion.
Four tools is a well-scoped size for a focused SDMX data retrieval server. Each tool is necessary and corresponds to a meaningful step in the pipeline without redundancy or bloat.
The tool surface covers the full read-only workflow: discovering available services, locating relevant dataflows, understanding their structure and constraints, and retrieving actual observations. No critical operations are missing for the stated purpose.