Loading ToolBench
SDMX (Statistical Data and Metadata eXchange) MCP server for querying statistical data from SDMX REST APIs
The server provides 10 well-named, action-oriented tools for SDMX data queries. All tools have clear, actionable descriptions (100-150 chars avg). Input schemas are present with type definitions and per-parameter descriptions. However, output schemas are not documented in the source code, parameter constraints lack formal enum/pattern declarations, and error handling guidance is absent. Tool naming follows verb_noun convention consistently (get_*, list_, describe_, search_, expand_*, resolve_*). Parameters are generally well-described but lack explicit constraint documentation (e.g., maxObservations lacks min/max bounds; filters object type is generic). No security concerns detected (READ_ONLY tools, no credential parameters). Composition is excellent, tools chain naturally (e.g., list_dataflows → describe_flow_structure → query tools). Main gaps: no output schema documentation visible, no error recovery guidance in descriptions, no per-parameter type/constraint metadata beyond description text.
Retrieve the structure of a dataflow including dimensions, indicators, and available codes
Expand a hierarchical codelist member to get all descendants
Get the description and metadata for a specific code from a codelist
Query multiple indicators across geographic locations as a table
Query a single observation value from an SDMX dataflow
Query time series data from an SDMX dataflow
List available SDMX dataflows, optionally filtered by search terms
Output schemas not documented. The source code shows tool definitions but does not expose structured documentation of what fields each tool returns. LLMs cannot plan downstream tool calls or extract specific fields without knowing the response structure.
Parameter constraints lack formal definitions. maxObservations accepts integers but no min/max bounds are specified. filters is typed as 'object' with only a description, no enum, pattern, or constraint metadata. time accepts free-form strings ('2020:2024', 'last_n_observations:10') without formal constraint documentation.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 26 | - | v1 |
List common SDMX dataflow ID prefixes organized by theme/domain
Resolve dimension member codes from natural language descriptions
Search within a hierarchical codelist for codes matching search terms
No error handling or recovery guidance in tool descriptions. Descriptions do not explain what happens on invalid flowRef, missing dimensions, rate limits, or timeout scenarios. No guidance like 'Call list_dataflows() first to verify flow exists' or error categories (retryable vs user-fixable).
Pagination not explicitly documented. list_dataflows and list_theme_prefixes accept 'limit' but no offset/cursor or total_count structure is described. searchTerms filtering is free-form without documented ranking or case-sensitivity rules.
Generic 'filters' parameter (object type). Does not document which dimension keys are valid, whether they're required, or how to discover valid dimension codes. Forces the LLM to call describe_flow_structure or resolve_dimension_values as a prerequisite discovery step on every data query.