Skip to main content
Glama

Download Eurostat Dataset

eurostat_download_dataset
Read-onlyIdempotent

Download a Eurostat dataset in bulk through the SDMX 2.1 TSV endpoint and stage every observation as a SQL table on the dataframe canvas — the route to a whole dataset, where eurostat_query_dataset is the route to a slice of one. The TSV wire format is roughly half the bytes of the JSON-stat body eurostat_query_dataset reads, so it reaches datasets that would otherwise time out, and it is expanded here into one row per observation. Filters take the same dimension-code map eurostat_query_dataset uses and are applied server-side by Eurostat; call eurostat_get_dataset_info first for the dimension codes and eurostat_get_dimension_values for their values. Narrow with since_period/until_period rather than asking for the most recent N periods — the TSV layout keeps a column for every period whichever is requested, so a period range is what actually shrinks the response. Transfers are bounded by a byte budget enforced while streaming: when it is spent the download stops and budgetExceeded is set, leaving a prefix of the dataset rather than an error. Only preview_limit rows come back inline. When a table is staged, call eurostat_dataframe_describe first to confirm its columns, then eurostat_dataframe_query; without a canvas, rows past the preview are not retained.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filtersNoDimension filters as a map of dimension code → array of accepted values, applied by Eurostat before the body is sent. Example: {"unit": ["CP_MEUR"], "na_item": ["B1G"], "geo": ["DE", "FR"]}. Omit a dimension or pass an empty array to accept every value for it. Do not put "time" here — use since_period/until_period. Naming a dimension the dataset does not have is rejected with the dataset's dimension list rather than silently ignored.
canvas_idNoReuse an existing dataframe canvas so this download lands beside earlier results and can be joined against them. Pass a canvasId from a previous response; omit to start a fresh canvas. Ignored on deployments without a dataframe canvas.
dataset_codeYesDataset code (e.g., "nama_10_gdp"). Required.
since_periodNoStart of the period range (e.g., "2020", "2023-Q1", "2024-01"), sent as startPeriod. The most effective way to shrink a bulk response: it removes period columns from the TSV rather than blanking their cells.
until_periodNoEnd of the period range (e.g., "2024"), sent as endPeriod. Omit for data through the latest available period.
preview_limitNoHow many observations to echo inline, from the start of the download. Caps at 500. The full download is on the canvas table when one was staged; this is orientation, not the result set.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe preview_limit applied to inline observations.
errorNoPresent when the call failed. Absent on success.
shownNoObservations returned in the inline preview.
noticeNoGuidance for every staged result, including the required eurostat_dataframe_describe then eurostat_dataframe_query sequence, composed with byte-budget, no-canvas, or empty-result disclosure when applicable.
canvasIdNoDataframe canvas holding the staged download. Pass to eurostat_dataframe_describe, eurostat_dataframe_query, or a later staging call. Omitted when nothing was staged.
rowCountNoObservations expanded from the download — one per populated cell, counting those Eurostat reports as unavailable.
bytesReadNoDecoded TSV bytes read from Eurostat — after gzip decompression when the body arrived compressed, so it measures the payload rather than the wire.
tableNameNoCanvas table holding every downloaded observation. Call eurostat_dataframe_describe with canvasId first to confirm the table and columns, then eurostat_dataframe_query. Omitted when this deployment runs without a dataframe canvas, in which case only the inline preview survives the call.
truncatedNoTrue when the inline observation preview omits rows.
compressedNoTrue when Eurostat sent the body gzip-compressed. It does so without a Content-Encoding header on large responses, so this reports what the stream actually carried.
datasetCodeNoDataset code as provided.
periodRangeNoPeriod coverage of the rows actually downloaded. Narrower than the dataset when budgetExceeded is true or a period range was applied.
appliedQueryNoThe bulk request as the server built it.
missingCountNoDownloaded observations carrying no numeric value (obs_value is null).
observationsNoThe first preview_limit observations of the download, in the order Eurostat streamed them. A prefix of the staged table, not a sample.
budgetExceededNoTrue when the byte budget stopped the transfer before the dataset ended, making the rows a prefix rather than the whole thing. Narrow with filters or a period range, or raise EUROSTAT_BULK_MAX_BYTES.
dimensionsUsedNoDimension codes carried by the downloaded rows, in the order Eurostat keys them (e.g., ["freq", "unit", "na_item", "geo"]). Read from the TSV header, so it reflects the response rather than metadata. The period lives in the separate "time" column.
stagedRowCountNoRows written to the canvas table. Matches rowCount. Omitted alongside tableName.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover safety (readOnlyHint, idempotentHint), and the description goes well beyond them with non-obvious traits: transfers are bounded by a streaming byte budget where the download stops and budgetExceeded is set, leaving a prefix rather than erroring; the TSV layout expands to one row per observation; only preview_limit rows come back inline. No contradiction with the annotations exists.

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 but front-loaded with purpose and flows logically: purpose → byte-efficiency rationale → filter workflow → period guidance → budget behavior → preview/retention workflow. Two clauses partially repeat the already-detailed schema ('applied server-side by Eurostat' and the per-period TSV column layout), which is minor redundancy, but every sentence otherwise contributes distinct operational value.

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 with 6 parameters, a nested object, 7 siblings, and an output schema, the description covers everything an agent needs: selection criteria vs the slice sibling, prerequisite tool calls, server-side filtering semantics, response-shrinking strategy, partial-download failure mode, preview vs staged-table distinction, and the post-download query workflow. The output schema exists, so explaining return values is unnecessary.

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?

Schema coverage is 100% and the schema itself is unusually rich (filter examples, period-column removal, preview as orientation), so the baseline is 3. The description adds genuine cross-tool meaning on top: filters use the same dimension-code map as eurostat_query_dataset, and the directive to narrow by period range rather than by an N-period request is operational guidance not present in the schema.

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?

States a specific verb (download in bulk), a precise resource (Eurostat dataset via the SDMX 2.1 TSV endpoint), and a distinctive outcome (staged as a SQL table on the dataframe canvas). It explicitly differentiates itself from the sibling eurostat_query_dataset ('the route to a whole dataset' vs 'the route to a slice of one'), so an agent can select between them from the description alone.

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?

Provides explicit when-to-use and orchestration guidance: call eurostat_get_dataset_info first for dimension codes and eurostat_get_dimension_values for values; use since_period/until_period 'rather than asking for the most recent N periods'; follow up with eurostat_dataframe_describe then eurostat_dataframe_query once a table is staged. It also names the slice alternative (eurostat_query_dataset) and warns that without a canvas rows past the preview are not retained.

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.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly distinct role: discovery, metadata lookup, dimension value lookup, inline query, bulk download, dataframe staging, and dataframe SQL. The two data-fetching tools are explicitly differentiated as slice vs. whole-dataset routes, and the dataframe tools are clearly separate from direct Eurostat queries.

Naming Consistency4/5

Six of eight tools follow a consistent eurostat_verb_noun pattern, e.g., search_datasets, get_dataset_info, query_dataset. The two dataframe tools invert this to eurostat_dataframe_describe and eurostat_dataframe_query, which is a minor deviation but still readable and predictable.

Tool Count5/5

Eight tools is a well-scoped count for the Eurostat data-access domain. Each tool covers a distinct stage in the workflow from discovery, metadata inspection, targeted querying, bulk download, and post-query analysis.

Completeness5/5

The toolset covers the full expected lifecycle: browse and search to find datasets, get metadata and dimension values to construct queries, query or download data, and stage/query results for further analysis. No significant dead ends or missing operations are evident for the stated purpose.