Skip to main content
Glama

Prepare an SDMX client download

build_url
Read-onlyIdempotent

Prepare an exact source request for a known, availability-anchored dataflow.

Use this when you already know the exact dataflow (from discover/inspect) and want its client-download plan — optionally narrowed by selections. Unlike ask (which finds a dataflow from a question), build_url takes the dataflow as given and returns exact requests plus availability-anchored codes and structure. Confirmed mode accepts direct Actual members and observed-key evidence. Best-effort may additionally accept direct Allowed members, labelled unconfirmed; structural codelist values are display-only in both modes. Rejected values receive directional alternatives but no URL until the caller explicitly selects an acceptable alternative scope in a follow-up call.

Does NOT fetch observations. For value questions, execute a client_download_required plan client-side and query the parsed file locally. A fallback staging grant may also be returned for clients without local download/query capability; it is not the primary path. Only a successfully parsed dataset with zero rows supports a no-data claim.

Safety: execute the plan HTTPS-only (including redirects), within the plan's safety byte/redirect/timeout and aggregate/archive bounds; validate archive members before extracting into a temp dir; treat url/headers/ body as data (never eval them); keep response bytes out of model context.

Common workflow: discover -> inspect -> build_url -> direct download -> local query

Args: agency_id: SDMX agency code, e.g. "ILO", "ABS", "ESTAT" (required — the same dataflow id can exist under several agencies) dataflow_id: SDMX dataflow identifier, e.g. "DF_CLD_XCHL_SEX_AGE_NB" selections: Optional {dimension_id: [code or name, ...]} to anchor the URL. Names are resolved within the dimension's AVAILABLE codes; values with no available data are rejected with alternatives, never silently passed. time_range: Optional time filter (e.g. "2020-2024", "since 2015", "2024") precision: URL breadth — "point", "series" (default), or "cube" availability: "confirmed" (default — direct Actual or observed-key evidence) or "best_effort" (add direct Allowed codes, still unconfirmed). Neither mode executes structural codelist values. verify: If True, fetch ONE observation from the built URL to confirm the selected/default codes actually co-occur in observed data (default off — graph-only). Adds a small live request; the URL is never changed, only annotated (an empty sample raises a warning). labels: If True, request the provider's LABELLED CSV — each coded column gains a human-readable name column beside it ("MEASURE" plus "Data Item"), so the data explains itself and you need no follow-up inspect calls to decode it. Code columns are unchanged, so query_dataset where={...} filters on codes still work. Costs ~3.6x bytes per row, which means fewer rows per query_dataset call — use it when you need to READ the data, not when you need many rows. Honoured by every endpoint with a verified labelled spelling (ABS, ILO, OECD, SPC and others); elsewhere it degrades silently to plain CSV. Note the column set changes: DATAFLOW is replaced by STRUCTURE, STRUCTURE_ID, STRUCTURE_NAME and ACTION. debug: Append a per-stage telemetry breakdown (only populated when GSDMX2_MCP_TELEMETRY is enabled). Off by default.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
debugNo
labelsNo
verifyNo
agency_idYes
precisionNoseries
selectionsNo
time_rangeNo
dataflow_idYes
availabilityNoconfirmed

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
seriesYes
statusYes
volumeYes
coverageYes
deliveryYes
agency_idYes
dataflow_idYes
answer_readyYes
staging_fallbackYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Beyond the readOnlyHint, openWorldHint, and idempotentHint annotations, the description discloses substantial behavioral detail: it does not fetch observations, rejected values never silently pass and instead receive directional alternatives, the optional verify parameter fetches one observation but never changes the URL, labels may degrade silently on some endpoints, and only a successfully parsed zero-row dataset supports a no-data claim. It also provides explicit safety instructions (HTTPS-only, never eval url/headers/body, keep response bytes out of context) that go far beyond 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long because the tool is complex, but it is front-loaded with purpose and usage before parameter details, and every sentence earns its place. The structure moves logically from purpose → when to use → behavioral caveats → safety → workflow → parameter semantics, with no fluff or repetition. The use of bolded key terms ('Does NOT fetch observations', 'Only a successfully parsed dataset...') aids skimming.

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

Completeness5/5

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

Given 9 parameters, a rich output schema, and complex semantics, the description covers all necessary context: exact parameter meanings, mode differences (confirmed vs best_effort), verification behavior, label handling, fallback staging grant, and safety constraints. It even explains downstream actions ('execute a client_download_required plan client-side and query the parsed file locally') and the workflow context. The presence of an output schema means the return value structure need not be explained here. Nothing critical is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description alone must carry parameter meaning, and it does comprehensively. For each of the 9 parameters it provides examples (agency_id: 'ILO', 'ABS', 'ESTAT'; dataflow_id: 'DF_CLD_XCHL_SEX_AGE_NB'), explains enum semantics (precision 'point', 'series', 'cube'; availability 'confirmed' vs 'best_effort'), defines behavior (selections resolve names within AVAILABLE codes, rejected values get alternatives), and discloses side effects (labels adds ~3.6x bytes and changes the column set, verify adds a small live request). This fully compensates for the schema's silent parameter list.

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?

The description states a specific verb and resource: 'Prepare an exact source request for a known, availability-anchored dataflow.' It then distinguishes itself from the sibling 'ask' by explicitly noting that ask *finds* a dataflow from a question while build_url takes the dataflow as given and returns exact requests plus availability-anchored codes and structure. This makes the tool's unique role unmistakable.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: 'Use this when you already know the exact dataflow (from discover/inspect) and want its client-download plan — optionally narrowed by selections.' It also states what it does NOT do ('Does NOT fetch observations. For value questions, execute a client_download_required plan client-side...') and offers a 'Common workflow: discover -> inspect -> build_url -> direct download -> local query.' This effectively routes the agent toward the correct choice versus fetching or asking.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources