Skip to main content
Glama

Find datasets and prepare client downloads

ask
Read-onlyIdempotent

Find the best datasets for a question and prepare exact source requests.

Use this when the user wants actual data values -- e.g., "What is infant mortality in Kenya?" or "How has Australia's trade with China changed?" Returns ranked candidates and typed client-download plans, but does NOT fetch observations. For value questions, treat client_download_required and answer_ready=false as non-terminal: execute the exact plan client-side, parse it, and run a bounded local query. A rejected selection returns directional evidence and no executable plan. Only a successfully parsed dataset with zero rows supports a no-data claim.

Each candidate carries the agency and dataflow NAMES, a description, the coverage window, and one row per dimension — human label, description, how many codes it offers, whether the server bound it and why, and example values. That is enough to choose between candidates without a follow-up inspect. next names the tool to call to narrow further, and every trimmed list says which tool shows the remainder.

url appears only when GETting that one URL yields the WHOLE dataset. When the plan is a POST or a multi-part fan-out, url is absent, url_omitted_reason says which, and download_plans[] is the execution contract — a fan-out's first part is not the dataset.

Safety: execute each 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. Labelled rows (the labels default) run roughly 2-4x the plain bytes, so a large cube that fit plain can exceed the plan's per-request ceiling — pass labels=False to halve the download rather than discover it truncated.

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

Args: question: Natural language question about statistical data agencies: Optional agency filter (e.g., ["ESTAT", "OECD"]) language: ISO language code (default "en") keywords: Optional keyword overrides for graph search (auto-extracted if omitted) time_range: Optional time filter (e.g., "2020-2024", "since 2015", "last 5 years") geography: Optional geography slot — country/region/world names the question is about (e.g. ["Australia"], ["European Union"], ["world"]). Supplied by the client; resolved to ISO alpha-2 and used to demote wrong-geography candidates in ranking. Does NOT become a hard agency filter or a URL filter. user_country: The country the USER is in (e.g. "New Zealand"). Pass only when the user has stated where they are; never infer it from the question. This is not the geography the question is about — that is geography. When the question names no geography, it prefers data covering the user's country, whoever publishes it. topic: Optional subject/metric of the question (e.g. "child labour", "GDP"). Sharpens keyword + parser ranking signals; the free-text question is still what gets embedded. currency: Optional currency slot — the currency the question is about (e.g. ["euro"], ["USD"], ["yen"]). NOT for geographic phrases like "euro area". Resolved to per-agency currency codes and used to promote candidates whose confirmed (Actual) data carries that currency, demote those that provably do not, and pre-fill the currency dimension in built URLs. product: Optional product/commodity slot — the good the question is about (e.g. ["wheat"], ["copper"], ["crude oil"]). Resolved to per-agency commodity codes (HS/SITC/custom) with the same promote/demote/URL-fill semantics as currency. scalar: Set True when the question wants a single value (one observation) rather than a series/table. Defaults precision to "point" unless precision is given. top_n: Number of top candidates to build URLs for (default 5) cross_source: If True, find structurally analogous dataflows in other agencies (>= 50% shared dimension concepts). Adds an extra graph query per candidate. precision: URL breadth — "point" (one observation's series), "series" (default: headline defaults for unfilled dimensions), or "cube" (full constraint enumeration, the historical behaviour). strict_time: If True and time_range is set, drop candidates whose materialized coverage is provably disjoint from the requested window (candidates without a coverage record are always kept). Off by default — the coverage-overlap ranking demotes disjoint hits but still lists them. labels: Request the provider's labelled CSV (default True) — adds a human-readable name column beside every coded column on the 14 endpoints with a verified labelled spelling, and degrades silently to plain CSV elsewhere. Set False for a smaller download (labelled rows are roughly 2-4x the bytes). debug: Append a per-stage telemetry breakdown to the response (only populated when GSDMX2_MCP_TELEMETRY is enabled). Off by default.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
debugNo
top_nNo
topicNo
labelsNo
scalarNo
productNo
agenciesNo
currencyNo
keywordsNo
languageNoen
questionYes
geographyNo
precisionNoseries
time_rangeNo
strict_timeNo
cross_sourceNo
user_countryNoThe country the USER is in. Pass only when the user has stated where they are; never infer it from the question. This is not the geography the question is about — that is `geography`. Used to prefer data covering the user's country when the question names no geography of its own.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusYes
candidatesYes
answer_readyYes
download_plansYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and the description richly supplements these. It discloses what the tool does NOT do (fetch observations), the non-terminal response states (client_download_required, answer_ready=false) and how to handle them, safety constraints (HTTPS-only, no eval, keep bytes out of context), URL presence semantics, and the performance cost of labeled rows (2-4x bytes). None of this is visible in the annotations; all of it is essential behavioral context. No contradiction with annotations.

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 long (~700 words), but the complexity justifies it: 17 parameters, multi-phase execution semantics, safety requirements, and performance trade-offs. Critical information (purpose, when-to-use, response semantics, safety) is front-loaded before the Args section. There is minor redundancy — the labels parameter is described in both the prose performance note and its Args entry, and user_country is duplicated in the schema description — but these are small costs for the exceptional coverage.

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?

For a tool of this complexity (17 params, 1 required, nested response semantics, safety constraints), the description is remarkably complete. It covers when to use, what it returns, how to interpret non-terminal states, how to execute the download plan safely, performance trade-offs, and where it fits in the workflow. The output schema covers return value structure, so the description need not explain those. Nothing an agent needs to call it correctly 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?

With schema description coverage at just 6%, the description carries nearly the entire burden of parameter documentation — and it does so comprehensively for all 17 parameters. Each parameter gets a purpose and often caveats (e.g., geography 'does NOT become a hard agency filter', currency 'NOT for geographic phrases like euro area', user_country 'never infer it from the question'). The precision enum values (point/series/cube) are explained in plain terms. This far exceeds what the schema provides.

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 purpose — 'Find the best datasets for a question and prepare exact source requests' — with a clear verb, resource, and scope. It distinguishes itself from siblings by explicitly noting what it does NOT do ('does NOT fetch observations') and positioning itself in a workflow ('discover -> inspect -> ask -> direct download -> local query'). An agent can tell this apart from build_url, fetch, and query_dataset without opening schemas.

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?

Gives explicit when-to-use ('Use this when the user wants actual data values') with concrete examples. It also explains when a follow-up inspect is unnecessary and that 'next names the tool to call to narrow further'. However, it doesn't systematically contrast with all 9 siblings — it relies on the workflow diagram and the 'does NOT fetch observations' exclusion rather than explicitly naming alternatives for each scenario. This is adequate but not exhaustive for a tool in a 10-tool ecosystem.

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