Skip to main content
Glama
nescoffee-create

SDMX MCP Gateway

build_data_url

Construct SDMX REST API data URLs for CSV, JSON, or XML downloads, using dataflow, filters, and time period parameters.

Instructions

Generate final SDMX REST API URLs for data retrieval.

Creates URLs that can be used directly to download data in various formats.
This is the final step in the SDMX query construction process.

Args:
    dataflow_id: The dataflow to query
    key: The data key (use build_key() to construct), or use filters instead
    filters: Dictionary of dimension_id -> code (alternative to key)
    start_period: Start of time range (optional)
    end_period: End of time range (optional)
    format_type: Output format (csv, json, xml)
    agency_id: The agency (uses session endpoint if not specified)
    endpoint: Optional endpoint key (e.g. "FBOS", "ECB") to target a
        specific provider for this call only. Defaults to the session's
        current endpoint.

Returns:
    Structured result with the complete data URL and usage information

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyNo
filtersNo
endpointNo
agency_idNo
end_periodNo
dataflow_idYes
format_typeNocsv
start_periodNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYesSDMX key used
urlYesComplete data retrieval URL
noteNoAdditional notes (e.g., version resolution)
usageYesInstructions for using the URL
formatYesOutput format (csv, json, xml)
versionYesResolved dataflow version
time_rangeNoTime period filter if specified
dataflow_idYesDataflow identifier
formats_availableNoAvailable output formats
dimension_at_observationYesObservation dimension setting
Behavior3/5

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

No annotations are provided, so the description carries full burden. It explains the tool produces URLs and returns a structured result, but does not explicitly disclose whether any network request is made, whether validation occurs, or any permission requirements. This is acceptable for a URL-building tool but lacks deeper behavioral detail.

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 structured with an Args/Returns format appropriate for an 8-parameter tool. The first two sentences are slightly redundant ('Generate final SDMX REST API URLs...' and 'Creates URLs...'), but they add useful detail about formats and direct download use.

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?

Given the tool's moderate complexity, the description covers all parameters, indicates the return type, and situates the tool as the final step in a pipeline. The output schema exists, so detailed return values are less critical. It does not explain every sibling relationship, but enough context is provided.

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

Parameters4/5

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

The schema provides only parameter titles with no descriptions (0% coverage), so the description's Args section is essential. It explains each parameter, including the distinction between key and filters, format options, and the endpoint override concept. Some descriptions are brief (e.g., 'Start of time range') but generally sufficient.

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?

Description states a specific verb ('Generate'), resource ('SDMX REST API URLs'), and purpose ('for data retrieval'). It also positions itself as 'the final step in the SDMX query construction process,' which clearly distinguishes it from siblings like build_key and probe_data_url.

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

Usage Guidelines4/5

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

The description explicitly frames when to use the tool ('final step in the SDMX query construction process') and mentions using build_key() to construct the key, providing a clear alternative. However, it does not explicitly state when NOT to use it or contrast all sibling tools.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nescoffee-create/sdmx-mcp-gateway'

If you have feedback or need assistance with the MCP directory API, please join our Discord server