Skip to main content
Glama

eurostat-mcp-server

by io.github.cyanheads

Query Eurostat Dataframes

eurostat_dataframe_query
Read-onlyIdempotent

Run a read-only SQL SELECT against tables staged on a Eurostat dataframe canvas — the way to reach observations past the 5,000-row inline cap of eurostat_query_dataset and past the inline preview of a eurostat_download_dataset bulk download, and to aggregate, group, or join across staged tables without re-fetching from Eurostat. Call eurostat_dataframe_describe first for the table and column names, which differ between the two stagers. Only a single SELECT statement runs: statement chaining, non-SELECT verbs, and functions that read files or external data are rejected. Columns are flat — every dimension is a code column named after the dimension, the measure is obs_value, the observation flag is obs_flag / obs_flag_label and the confidentiality marker is conf_status / conf_status_label; a "_label" companion per dimension exists only on tables eurostat_query_dataset staged. Both stagers write the same five measure columns with the same codes, so join their tables on dimension codes and time and compare obs_flag or conf_status across them directly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sqlYesA single read-only SELECT statement. Reference tables by the names eurostat_dataframe_describe reports. Example: SELECT geo, geo_label, AVG(obs_value) AS mean FROM df_a1b2c3d4 WHERE time >= '2020' GROUP BY geo, geo_label ORDER BY mean DESC.
canvas_idYesCanvas identifier returned as canvasId by eurostat_query_dataset or eurostat_download_dataset. Identifies the workspace holding the staged tables.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsNoResult rows, each keyed by column name. Bounded by the canvas row limit. 64-bit integer results — COUNT(*) among them — arrive as strings so values outside the JSON number range survive intact; cast to DOUBLE in the SQL if a number is wanted.
errorNoPresent when the call failed. Absent on success.
columnsNoColumn names in projection order.
canvasIdNoCanvas identifier the query ran against.
rowCountNoRows materialized into this response. Equals the full result size unless truncated is true.
truncatedNoTrue when the result exceeded the canvas row limit and was cut short. Add a LIMIT, an aggregate, or a narrower WHERE clause to see the rest.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds substantial behavioral context beyond that: rejected SQL forms, flat column structure, measure/flag/confidentiality naming conventions, and differences between stagers regarding '_label' companions. This meaningfully informs invocation expectations without contradicting 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 but densely informative; every sentence adds necessary constraints or context for a complex tool. The first sentence is front-loaded with the core purpose, and subsequent sentences expand on restrictions and schema details without being redundant.

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 the tool's complexity, the description covers purpose, when to use it, prerequisites, query restrictions, column naming conventions, stager differences, and join compatibility. An output schema exists, so not explaining return values is acceptable. The description is effectively complete for an agent to select and use this tool correctly.

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%, so the baseline is 3, but the description adds value by providing a concrete SQL example, explaining that table names come from eurostat_dataframe_describe, and clarifying that canvas_id comes from the stager tools. This reinforces and extends the schema definitions.

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 opens with a specific verb and resource: 'Run a read-only SQL SELECT against tables staged on a Eurostat dataframe canvas.' It clearly distinguishes itself from siblings by explaining it reaches past the 5,000-row cap of eurostat_query_dataset and past inline previews, and enables aggregation, grouping, and joins without re-fetching.

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?

Explicit when-to-use guidance is provided: for data beyond inline caps, for aggregating/grouping/joining staged tables, and for avoiding re-fetching. It also tells the agent to call eurostat_dataframe_describe first for table and column names, and states the hard constraint that only a single SELECT statement is allowed.

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

All eurostat-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources