Skip to main content
Glama

eurostat-mcp-server

by io.github.cyanheads

Describe Eurostat Dataframes

eurostat_dataframe_describe
Read-onlyIdempotent

List the tables staged on a Eurostat dataframe canvas, with their row counts and column names and types. Call this before eurostat_dataframe_query to learn the table and column names to write SQL against. The canvas_id comes from a eurostat_query_dataset or eurostat_download_dataset response that reported a staged table. Every observation column is flat, but the two stagers write different dimension columns, so read the columns reported here rather than assuming: eurostat_query_dataset gives each dimension a code column named after the dimension (e.g. "geo") plus a label companion (e.g. "geo_label"); eurostat_download_dataset gives code columns only — the bulk endpoint carries no labels — plus a "time" column. Both write the same five measure columns — obs_value, obs_flag, obs_flag_label, conf_status, conf_status_label — carrying the same codes for the same observation, so tables from the two stagers join on dimension codes and time and compare like with like.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance when the canvas holds no tables. Omitted when it holds at least one.
tablesNoTables staged on this canvas. Empty when nothing has been staged yet, or when every staged table has expired.
canvasIdNoCanvas identifier the tables were read from.
expiresAtNoISO 8601 timestamp when the canvas expires. Every call on it slides this forward.

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so safety is covered. The description adds valuable behavioral details: it explains the structural differences between stagers (code vs. label columns) and the consistent measure columns, which is beyond annotation scope. No contradiction.

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 fairly long but well-structured: it opens with the tool's purpose, then usage, then detailed behavioral distinctions. Every sentence serves a purpose, though some could be condensed. It is not overly verbose given the complexity of Eurostat data structures.

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 complexity of the Eurostat domain, the description thoroughly covers the differences between stagers, the measure columns, and join compatibility. It provides all necessary context for an agent to understand what to expect, and the output schema existence means return values don't need additional explanation.

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 description for canvas_id is already 100% covered, meeting the baseline of 3. The description adds context about where the canvas_id originates (from specific stager responses) and clarifies it identifies the workspace, enhancing the parameter's meaning beyond 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?

The description clearly states the tool lists staged tables on a Eurostat dataframe canvas with row counts and column names/types. It explicitly references the sibling tool eurostat_dataframe_query, distinguishing its role as a preparatory step, and differentiates from other siblings by its specific function.

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 explicitly instructs to call this before eurostat_dataframe_query to learn table and column names, and clarifies that canvas_id comes from eurostat_query_dataset or eurostat_download_dataset responses. It also explains when not to assume column names, providing strong contextual guidance.

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