This server provides an MCP-based unified data analysis suite for Eurostat statistics, Italian ISPRA environmental data, and Italian BDAP public finance data, letting AI agents search, query, stage, filter, and analyze official EU and Italian datasets with SQL, CSV export, and guided workflows.
Search & discover datasets: keyword search with pagination, browse Eurostat themes, and list popular datasets.
Get metadata & dimensions: inspect dataset details, available dimensions, codes, labels, and NUTS regional levels.
Query statistical data: filter by dimensions, time periods, NUTS level, and retrieve recent or full data slices with observation flags.
Use DuckDB SQL canvas: download datasets to in-memory tables, run read-only SQL SELECT queries, list staged tables, and inspect schemas.
Export to CSV: export single or multiple Eurostat datasets to local files.
Analyze ISPRA environmental data: query LOD indicators, SPARQL, IdroGEO hazard indicators, and INSPIRE WFS geographic layers.
Analyze BDAP public finance data: search catalogue, preview dumps, background-download large datasets, and stage them as SQL tables.
Join across sources: combine Eurostat, ISPRA, and BDAP tables in one shared DuckDB canvas via SQL.
Use MCP resources & prompts: access dataset resources and guided prompts for topic exploration, country comparisons, and trade analysis.
Provides access to official European Union statistical data (Eurostat), with tools for searching, querying, and analyzing over 8,900 datasets, including SDMX 3.0 and Comext trade data.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@eurostat-mcp-suite Search for GDP datasets for Germany"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The Unified Model Context Protocol (MCP) Server for Eurostat Statistics & EU Data Analysis
Seamlessly search, query, and analyze 8,900+ official European Union statistical datasets via MCP.
Supports SDMX 3.0, SDMX 2.1 Comext (International Trade), DuckDB In-Memory SQL Canvas, NUTS Regional Levels, CSV Exports, Resources, and Prompts.
Plus Italian open data: ISPRA environment and BDAP public finance, on the same SQL canvas.
eurostat-mcp-suite is a unified, high-performance MCP server designed to provide AI Agents (Claude Desktop, Cursor, Roo Code, Antigravity CLI, Windsurf, Goose, Zed) with complete access to official Eurostat, ISPRA (Italian environmental agency) and BDAP (Italian public finance, Ragioneria Generale dello Stato) data.
It combines all capabilities into one robust, clean architecture:
Full API Coverage: Connects to both Eurostat SDMX 3.0 (economy, demography, health, energy) and SDMX 2.1 Comext (international trade with DS- prefixes).
DuckDB SQL Dataframe Canvas: Stages complete datasets into an in-memory DuckDB database so AI agents can execute read-only SELECT queries without blowing context window token limits.
NUTS Regional Filtering: Filter geographic observations by NUTS regional levels (aggregate, country, nuts1, nuts2, nuts3).
Catalogue Discovery: Tokenized search with cursor pagination and Eurostat theme tree navigation.
Local CSV Exporting: Export single or batch datasets directly to local CSV files.
Native Resources & Prompts: Standardized eurostat:// URI resources and guided analytical workflows.
ISPRA Environmental Data: Italian environmental statistics via three distinct ISPRA surfaces โ Linked Open Data (SPARQL), the IdroGEO REST API, and INSPIRE OGC WFS โ exposed as ispra_* tools that share the same DuckDB canvas, so Eurostat and ISPRA tables can be joined in one query.
BDAP Public Finance Data: Italian state budget, SIOPE cash flows, public bodies' balance sheets, debt and public works from the Ragioneria Generale dello Stato (~3,850 datasets), exposed as bdap_* tools on the same DuckDB canvas.
Related MCP server: eurostat-mcp
You can copy and paste the prompt below directly to your AI Assistant (Cursor, Roo Code, Antigravity CLI, Windsurf, Claude) to let it automatically configure and verify eurostat-mcp-suite:
Please read the instructions from https://github.com/ManoloZocco/eurostat-mcp-suite and automatically install the Eurostat MCP Suite server for my environment:
1. Detect my OS (macOS/Windows/Linux) and current client editor (Claude Desktop, Cursor, Roo Code, VS Code, Windsurf, AGY).
2. Check if Python 3.10+ and `uv` (or `pip`) are available.
3. Clone https://github.com/ManoloZocco/eurostat-mcp-suite.git to a persistent directory if not present.
4. Add `eurostat-mcp-suite` to my client's MCP configuration file (e.g. claude_desktop_config.json, mcp_config.json, settings.json).
5. Verify that the server starts successfully and test `search_datasets("GDP")`.Tool | Description |
| Search Eurostat catalogue by keyword with tokenized matching & cursor pagination |
| Drill down Eurostat top-level statistical themes (Economy, Population, Trade, Energy, etc.) |
| List pre-curated high-value Eurostat datasets by domain |
Tool | Description |
| Inspect dataset title, dimensions, observation count, and sample values |
| List valid codes for a dimension with optional NUTS regional filtering ( |
| Query decoded statistical observations with |
Tool | Description |
| Download complete dataset into an in-memory SQL table for high-speed analysis |
| Run read-only SQL |
| List currently staged SQL tables and row counts |
| Inspect table schema and sample rows |
Tool | Description |
| Save dataset observations directly to a local CSV file |
| Batch export multiple datasets to a target directory |
filtersfilters maps a dimension name to one code or to a list of codes. Both shapes are
accepted, and a JSON string encoding the same object works too (some MCP clients
serialise objects to text before they reach the server):
export_to_csv("urb_cenv", "./out.csv", filters={"indic_ur": "EN5206V"})
export_to_csv("urb_cenv", "./out.csv", filters={"indic_ur": ["EN5206V", "EN5207V"]})
query_dataset("nama_10_gdp", filters={"geo": ["IT", "FR"], "unit": "CP_MEUR"})
export_to_csv("urb_cenv", "./out.csv", filters='{"indic_ur": "EN5206V"}')The geographic dimension is not always called geo โ urban audit datasets such as
urb_cenv call it cities. Call get_dataset_info(dataset_id) first: it reports
dimension_names and geo_dimension for that specific dataset.
query_dataset, export_to_csv and download_dataset_to_sql return applied_criteria
plus a per-dimension breakdown (dimension_values_returned / dimension_values_exported
/ dimension_values_staged) of exactly which codes reached the output, along with
is_complete and a warning when the result is a subset.
query_dataset defaults to last_n_periods=5, so it returns a recent slice; pass
last_n_periods=0 for the full time range. export_to_csv and download_dataset_to_sql
default to the full time range and no row cap.
ISPRA does not publish a single API, so three separate surfaces are wrapped. All ISPRA
tools are prefixed ispra_ and never mix semantics with the Eurostat ones.
dati.isprambiente.it/sparql)Tool | Description |
| List the environmental LOD datasets and the years each covers |
| Years, administrative levels carrying data, sample parameters |
| List measurable parameters โ the ISPRA analogue of a Eurostat dimension's codes |
| Fetch indicator values |
| Export indicator values to a local CSV |
| Stage indicator values into the shared DuckDB canvas |
| Read-only SPARQL escape hatch (SELECT/ASK only) |
Datasets: soilc (consumo di suolo), urban, bathw (acque di balneazione), pest
(pesticidi), marind, ihi, ostreopsis, rmn, ron.
Tool | Description |
| Resolve a place name to the IdroGEO numeric |
| Landslide/flood hazard and risk indicators ( |
Tool | Description |
| List feature layers of the |
| Download features as tabular rows |
ISPRA has no fixed dimension grid. An indicator is identified by a parameter code
(e.g. soilc_DISECO11) measured for a place in a year, so use
ispra_get_parameters where you would use get_dimension_values.
Place names are ambiguous across administrative levels โ "Firenze" is both a comune
and a cittร metropolitana, with very different values. Every row therefore carries
place_type, and place_level narrows the query:
ispra_query_indicators("soilc", parameters="soilc_DISECO11",
places=["Firenze"], years=2021)
# -> Firenze/MetropolitanCity = 7.38 % and Firenze/Municipality = 42.53 %Both sources stage into the same DuckDB canvas, so one sql_query spans them:
download_dataset_to_sql("urb_cenv", "eu_soil", filters={"indic_ur": "EN5206V"})
ispra_download_to_sql("soilc", "ispra_soil", parameters="soilc_DISECO11",
years=2021, place_level="comune")
sql_query("""SELECT i.place_name, i.value AS ispra_consumo_pct,
CAST(e.value AS DOUBLE) AS eurostat_agri_pct
FROM ispra_soil i JOIN eu_soil e ON e.cities_label = i.place_name
WHERE e.time = '2012' ORDER BY i.value DESC""")โ ๏ธ Joining on place name is lossy. The two sources use different geographies:
Eurostat's urban audit includes "greater city" aggregates (Bergamo (greater city))
that have no ISPRA comune counterpart, and spellings can differ. Prefer a LEFT JOIN
so unmatched rows stay visible, and check the ISTAT code (ispra_soil.istat) when you
need certainty.
BDAP OpenData is the open data catalogue of the
Ragioneria Generale dello Stato (MEF): state budget, SIOPE cash flows, public bodies'
balance sheets and debt, public works, public employment, healthcare accounts โ
~3,850 datasets across 13 themes. All tools are prefixed bdap_.
Tool | Description |
| Search the catalogue by a single keyword, with |
| List the 13 thematic groups |
| Browse a theme's datasets โ the only working way to filter by subject |
| List the catalogue's keywords |
| Description, theme, licence, update frequency, resources |
| Columns and first rows โ constant cost on any dataset size |
| Whether the dump is cached, downloading (with progress), or absent |
| Stage a dataset into the shared DuckDB canvas |
| Export to a local CSV |
Dump sizes are brutally skewed โ a 2% sample of the catalogue has a median of 0.6 MB but a maximum of 262 MB. Since there is no DataStore, the whole dump is the only way in, so the tools are built around that rather than pretending it away:
Preview never downloads the file. It closes the connection as soon as it has enough rows: 0.4 s on a 262 MB dataset, same as on a small one. Use it to learn column names before filtering. It deliberately does not populate the cache โ a truncated dump must never be mistaken for a complete one.
Downloads stream to an on-disk cache and continue in the background. If the dump is
not ready within wait_seconds (default 25 s, comfortably under a client's tool
timeout), the tool returns status: "downloading" with progress instead of hanging.
The transfer is not cancelled โ call the tool again, or poll bdap_dump_status.
Once cached, staging is ~1 s and the cache is reused for a week.
Filters, column projection and limits are pushed into DuckDB's CSV reader, so rows never travel through Python. Staging all 1,088,987 rows of the 262 MB SIOPE dump takes 1.7 s from cache; with a filter and three columns, 1.5 s.
Cache location defaults to a temp directory; override with the BDAP_CACHE_DIR
environment variable.
โ ๏ธ Encoding varies per dataset. Some dumps are UTF-8, others are Windows-1252 โ the
262 MB SIOPE dump carries \xe0 for "ร " in 81k places. The encoding is detected during
the download and the cache is normalised to UTF-8, so Indennitร arrives intact rather
than as a replacement character.
bdap_preview_dataset("42f61eb2-5475-4de2-8d58-34f9a2340608") # 0.4s on 262 MB
bdap_download_to_sql("42f61eb2-...", "siope") # returns "downloading"
bdap_dump_status("42f61eb2-...") # poll until ready
bdap_download_to_sql("42f61eb2-...", "siope", # ~1.5s from cache
filters={"Provincia BDAP": "TORINO"},
columns=["Anno/Mese calendario", "Importo cumulato"])BDAP advertises a CKAN API but ships a partial, modified implementation. Verified against the live portal on 2026-08-08:
The base path is /SpodCkanApi/api/3/action, not the /api/3/action CKAN
documents โ the portal itself is Drupal, and the bare path returns a Drupal 404.
package_search reports count as the size of the returned page, not the total
number of matches. The real total is not exposed; page with start until a page comes
back empty. The tools report "total_matches": "unknown" rather than inventing one.
fq is silently ignored. A made-up field name returns the same first page as no
filter at all, so there is no faceted search. Use bdap_list_theme_datasets instead.
q is a literal substring match, not a tokenised search. "opere pubbliche" works
because those words are adjacent in the title, and so does the fragment "ere pubbl" โ
but "pubbliche opere", "Opere Pubbliche" (double space) and "SIOPE Toscana" all
return nothing. Boolean operators do not work. Prefer one distinctive term and narrow
locally.
There is no DataStore. datastore_search, resource_show and
current_package_list_with_resources return a Tomcat 404, so no server-side row
filtering exists. Data comes from the whole-dataset CSV dump at
.../api/3/datastore/dump/{id}.csv and is filtered locally โ which is exactly why
bdap_download_to_sql plus sql_query is the right way to work with it.
HEAD and Range are both useless. HEAD returns text/html with no
Content-Length; a Range: bytes=0-999 request returns the entire body with HTTP 200
and no Accept-Ranges. So a dump's size is only knowable by opening the GET and reading
the response header, a partial read means closing the connection early, and a failed
download cannot be resumed โ it restarts from zero.
Resource metadata lies. A resource declared "format": "CSV" is routinely a PDF
report ("mimetype": "application/pdf"). bdap_get_dataset_info reports both fields
and warns when they disagree.
group_show returns bare dataset ids, not package objects, so
bdap_list_theme_datasets resolves titles with one extra request per dataset. Pass
resolve_titles=False for a fast id-only listing.
The dump is semicolon-separated with a trailing separator (the phantom empty column is
dropped on load). Every column is staged as text: amounts use a dot decimal separator
and dates are dd/mm/yyyy, so cast in SQL. Filter values are always passed to DuckDB as
bound parameters, never interpolated into SQL.
bdap_search_datasets("SIOPE", limit=10)
bdap_preview_dataset("d032b3a2-2b70-4193-a0c8-cb7eb69f8710", limit=5)
bdap_download_to_sql("d032b3a2-2b70-4193-a0c8-cb7eb69f8710", "ssn_cce")
sql_query("""SELECT "Anno di Riferimento" AS anno,
ROUND(SUM(CAST("Importo Totale" AS DOUBLE))/1e9, 2) AS miliardi_eur
FROM ssn_cce GROUP BY 1 ORDER BY 1""")
# 2008 โ 977.68 | 2009 โ 1006.34 | 2010 โ 1024.95 | 2011 โ 1033.84Because BDAP shares the same DuckDB canvas, an Italian public finance table can be joined
against a Eurostat or ISPRA one in a single sql_query call.
eurostat://datasets/{query}: Live search resource matching keywords.
eurostat://dataset/{code}/dimensions: Dimension structure resource for a dataset.
eurostat://themes: Root theme tree resource.
eurostat://popular: Pre-curated popular datasets list resource.
explore_topic(topic): Guided step-by-step workflow to analyze any European statistical topic.
compare_countries(indicator_dataset, countries): Template for cross-country EU comparative analysis.
trade_analysis(trade_dataset, reporter): Template for EU international trade & Comext statistical analysis.
Python 3.10+
uv (Recommended, curl -LsSf https://astral.sh/uv/install.sh | sh) or pip
Add the following to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
With uv (recommended):
{
"mcpServers": {
"eurostat-suite": {
"command": "uv",
"args": [
"--directory",
"/path/to/eurostat-mcp-suite",
"run",
"server.py"
]
}
}
}With standard python:
{
"mcpServers": {
"eurostat-suite": {
"command": "python",
"args": [
"/path/to/eurostat-mcp-suite/server.py"
]
}
}
}Open Cursor Settings -> Features -> MCP.
Click + Add New MCP Server.
Set Name: eurostat-suite
Set Type: command
Set Command: uv --directory /path/to/eurostat-mcp-suite run server.py
Alternatively, add to your Cursor .cursor/mcp.json:
{
"mcpServers": {
"eurostat-suite": {
"command": "uv",
"args": ["--directory", "/path/to/eurostat-mcp-suite", "run", "server.py"]
}
}
}In your VS Code settings.json or Roo Code / Cline MCP settings (cline_mcp_settings.json):
{
"mcpServers": {
"eurostat-suite": {
"command": "uv",
"args": [
"--directory",
"/path/to/eurostat-mcp-suite",
"run",
"server.py"
]
}
}
}Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"eurostat-suite": {
"command": "uv",
"args": [
"--directory",
"/path/to/eurostat-mcp-suite",
"run",
"server.py"
]
}
}
}Run:
agy mcp add eurostat-suite -- command uv --directory /path/to/eurostat-mcp-suite run server.pyRun:
goose mcp add eurostat-suite -- command uv --directory /path/to/eurostat-mcp-suite run server.pyUser: "Download the annual GDP dataset nama_10_gdp and run a SQL query to show average GDP for Germany, France, and Italy over the last 5 years."
Agent steps:
1. download_dataset_to_sql(dataset_id="nama_10_gdp", table_name="gdp_table")
2. sql_query("SELECT geo, geo_label, AVG(value) as avg_gdp FROM gdp_table WHERE geo IN ('DE', 'FR', 'IT') GROUP BY geo, geo_label ORDER BY avg_gdp DESC")User: "Query EU extra-trade statistics for dataset DS-045409."
Agent steps:
1. get_dataset_info("DS-045409")
2. query_dataset(dataset_id="DS-045409", filters={"reporter": ["EU27_2020"]}, limit=50)User: "Check soil consumption in Tuscany municipalities for 2021 and retrieve landslide hazard indicators for Florence."
Agent steps:
1. ispra_query_indicators("soilc", parameters="soilc_DISECO11", years=2021, place_level="comune")
2. ispra_idrogeo_search_places(level="comune", name="Firenze")
3. ispra_idrogeo_indicators(level="comune", place_id=48017, dataset="pir")User: "Compare ISPRA soil consumption data against Eurostat urban agricultural indicators in DuckDB."
Agent steps:
1. download_dataset_to_sql("urb_cenv", "eu_soil", filters={"indic_ur": "EN5206V"})
2. ispra_download_to_sql("soilc", "ispra_soil", parameters="soilc_DISECO11", years=2021, place_level="comune")
3. sql_query("""
SELECT i.place_name, i.value AS ispra_consumo_pct, CAST(e.value AS DOUBLE) AS eurostat_agri_pct
FROM ispra_soil i
LEFT JOIN eu_soil e ON e.cities_label = i.place_name
WHERE e.time = '2012'
ORDER BY i.value DESC
LIMIT 10
""")This project is licensed under the MIT License - see the LICENSE file for details.
Browse top-level Eurostat themes (Economy, Population, Trade, Environment, Industry, etc.).
Returns: Categorized themes with key domain topics and dataset codes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It explicitly states the output (categorized themes with key domain topics and dataset codes) and the scope ('top-level'), and the verb 'browse' implies a read-only operation. This is adequate for a simple, non-destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, purposeful sentences with a clear 'Returns:' label. It includes concrete examples and avoids any fluff or repetition. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (per signal), the description does not need to detail return values exhaustively. It provides a high-level overview and examples that are sufficient for a simple browsing tool. The main gap is the lack of explicit guidance on when not to use it, but that is not critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description confirms that no input is required and provides context about what the output contains, which complements the empty input schema perfectly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'browse' with the resource 'top-level Eurostat themes' and provides concrete examples (Economy, Population, Trade, Environment, Industry). This clearly distinguishes it from sibling tools like search_datasets (searching) and get_dataset_info (specific dataset details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool when you need to explore the top-level theme hierarchy of Eurostat data. It does not explicitly mention alternatives or exclusions, but the context is sufficiently clear for an agent to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect the schema and first 5 sample rows of a staged SQL table.
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes | Name of the staged table |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It clearly states the tool performs a read-only inspection and limits output to the first 5 rows, which is useful. However, it doesn't address potential errors or permission requirements, leaving some uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the verb and object, with no filler. Every word contributes to the understanding of the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description covers the essential behavior and the table context. It could add edge cases like missing table behavior, but given the simplicity and the presence of an output schema, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single parameter (table_name) with 100% coverage. The description adds the qualifier 'staged SQL table', reinforcing the parameter's domain, but no further semantic detail is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Inspect') and names the resource ('schema and first 5 sample rows of a staged SQL table'), making the tool's function clear. It does not explicitly differentiate among siblings like query_dataset, but the focus on staged tables is distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus sibling tools. The description implies it's for preliminary inspection but doesn't name alternatives or exclusions, so agents lack direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a complete Eurostat dataset and stage it as a SQL table in the in-memory DuckDB canvas.
| Name | Required | Description | Default |
|---|---|---|---|
| filters | No | Optional dimension filters | |
| dataset_id | Yes | Eurostat dataset ID (e.g. "nama_10_gdp", "DS-059341") | |
| table_name | Yes | Desired SQL table name (e.g. "gdp_table", "comext_trade") |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the primary side effect (staging into an in-memory DuckDB table) but leaves out important behavioral details such as whether existing tables are overwritten, the effect of the optional filters on the 'complete dataset' claim, or potential download size/time implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the core action and destination with no redundant wording or filler. It is appropriately sized for the tool's straightforward purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema and output schema cover structural details, but for a tool with optional filters and possible overwrite behavior, the description omits critical operational caveats. It is complete enough for basic use but not fully robust for an agent needing to avoid surprising side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds only high-level context ('complete', 'SQL table') without providing deeper parameter semantics like filter syntax or table naming rules beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description names a specific action ('Download'), a resource ('Eurostat dataset'), and a clear outcome ('stage it as a SQL table in the in-memory DuckDB canvas'). This clearly distinguishes it from sibling tools like search_datasets, query_dataset, or export_to_csv.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need a full Eurostat dataset staged for SQL querying, but it does not explicitly state when to use this versus query_dataset or get_dataset_info, nor does it mention exclusions or alternatives. Guidance is only implicit via the tool name and wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Batch export multiple Eurostat datasets to CSV files in a target directory.
| Name | Required | Description | Default |
|---|---|---|---|
| output_dir | No | Target directory path | ./eurostat_exports |
| dataset_ids | Yes | List of dataset IDs (e.g. ["nama_10_gdp", "une_rt_m"]) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions only the high-level action and outcome, without detailing side effects like directory creation, file overwriting, error handling, rate limits, or permissions. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the action, scope, and output format. It is concise with no redundant information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple batch export tool, and the presence of an output schema reduces the need to explain return values. However, it lacks details on operational behaviors (e.g., whether the output directory is created automatically) and does not differentiate from sibling tools, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions already cover 100% of parameters (dataset_ids list, output_dir directory path). The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('export') and resource ('multiple Eurostat datasets'), and clearly states the output format (CSV files) and destination (target directory). This distinguishes it from sibling tools like export_to_csv, which likely handles single datasets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool instead of alternatives such as export_to_csv or query_dataset. It does not mention scenarios like handling batches, differences from single-export tools, or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a Eurostat dataset directly to a local CSV file on disk.
| Name | Required | Description | Default |
|---|---|---|---|
| filters | No | Optional dimension filters | |
| filepath | Yes | Target CSV absolute or relative path (e.g. "./output_gdp.csv") | |
| dataset_id | Yes | Eurostat dataset ID (e.g. "nama_10_gdp", "DS-059341") |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It mentions writing to a local CSV file, but does not disclose side effects like overwriting behavior, directory creation, or execution time. The word 'directly' adds some context but minimal detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words, front-loading the verb 'Export' and the resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple export tool, the description covers the core purpose, but lacks details on file handling behavior and relationship to similar tools. Annotations are absent and output schema exists but doesn't compensate for missing usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete descriptions for all three parameters with 100% coverage. The tool description does not elaborate on parameters beyond what the schema already states, so it adds no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports a Eurostat dataset to a local CSV file, using a specific verb and resource. It distinguishes from siblings like export_multiple_datasets and download_dataset_to_sql by specifying a single dataset to CSV.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (exporting a single dataset to a local CSV) but does not explicitly mention alternatives or when not to use. Sibling tools like download_dataset_to_sql and export_multiple_datasets exist, but the description offers no guidance on choosing among them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch metadata, dimension structures, time ranges, and sample values for a Eurostat dataset.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | Eurostat dataset code (e.g. "nama_10_gdp", "une_rt_m", "DS-059341") |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It explicitly lists what the tool returns ('metadata, dimension structures, time ranges, sample values') and the word 'Fetch' implies a read-only operation. It does not detail response format or pagination, but the output schema covers return structure, making this adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the exact purpose without waste. Every word adds value and no extraneous details are included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one param) and has a full output schema, so the description need not explain return values. The description provides sufficient context for an agent to understand the tool's scope, though it could benefit from a hint about when to use it relative to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter with a clear description and examples (e.g., 'nama_10_gdp'). The description adds no parameter-specific information, so the baseline of 3 applies per the schema_description_coverage of 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and clearly identifies the resource ('metadata, dimension structures, time ranges, and sample values for a Eurostat dataset'). This distinguishes it from siblings like query_dataset (actual data) and get_dimension_values (specific dimension values).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool to get metadata and structure for a Eurostat dataset before querying data. However, there is no explicit guidance on when to prefer this over siblings like get_dimension_values or describe_table, nor any exclusions or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all valid codes and labels for a specific dataset dimension, with optional NUTS regional filtering for 'geo'.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | Eurostat dataset ID (e.g. "nama_10_gdp") | |
| nuts_level | No | Optional NUTS filter for 'geo' dimension: 'aggregate', 'country', 'nuts1', 'nuts2', 'nuts3' | |
| dimension_code | Yes | Dimension name (e.g. "geo", "unit", "na_item", "sex", "age") |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists all valid codes and labels and supports optional NUTS filtering. However, it does not mention edge cases such as behavior when nuts_level is supplied for a non-'geo' dimension, ordering, pagination, or error conditions. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the core action ('List all valid codes and labels'), followed by a concise optional modifier. Every word earns its place; there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with three parameters, full schema coverage, and an output schema present, the description is complete. It states the purpose, the resource targeted, and the optional filtering behavior. No additional context seems necessary for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds little beyond what the schema providesโthe mention of NUTS filtering for 'geo' mirrors the schema's own parameter description. It gets the baseline score of 3 because it does not harm understanding but also does not add meaningful extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('List') and names the exact resource ('valid codes and labels for a specific dataset dimension'). It also mentions the optional NUTS regional filtering, which clearly distinguishes this tool from siblings like query_dataset or get_dataset_info. The function and scope are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for retrieving dimension code-label pairs and specifies when NUTS filtering can be applied (for 'geo'). It does not explicitly name alternatives or state exclusions, but the context is clear enough that an agent can infer when to use it. A slightly more explicit 'use this instead of get_dataset_info for dimension values' would push it to 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pre-curated high-value Eurostat datasets by category.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional category filter (e.g. "Economy & GDP", "Employment & Labour", "International Trade", "Demography & Health", "Energy & Environment") |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It mentions the curated nature and category filtering but does not explain behavior when category is omitted (e.g., returns all popular datasets), the meaning of 'high-value', ordering, pagination, or how categories are matched. This is a significant gap for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and resource. Every word contributes to the meaning without repetition or fluff, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity with one optional parameter and an existing output schema, so the description needs less detail about return values. However, it lacks usage guidance and behavioral nuances (e.g., default listing when category is null), which an agent would need for confident invocation. It is minimally complete but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional parameter, so the baseline is 3. The description adds the phrase 'by category' but does not provide additional meaning beyond what the schema already specifies with example values. It does not compensate for any gaps because there are none in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('pre-curated high-value Eurostat datasets'), with the modifier 'by category' specifying the filtering dimension. This distinguishes it from sibling tools like search_datasets (which likely searches all datasets) and browse_themes (which browses by theme), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving curated high-value datasets, but does not explicitly state when to prefer this over alternatives or when not to use it. No alternatives are named, nor are exclusions given. The context is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all staged SQL tables currently available in the DuckDB canvas.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only listing operation but does not disclose return format, pagination, or other behavioral details. Since no annotations are provided, it carries some burden, but the behavior is straightforward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise, front-loaded, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter list tool with an output schema, the description is mostly sufficient, though it could mention the intended use case or read-only nature to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description need not elaborate. The schema is complete and vacuously covers all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), the object (staged SQL tables), and the scope (DuckDB canvas), distinguishing it from sibling query and dataset tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage for discovering available staged tables before querying, but does not explicitly state when to use this vs alternatives like sql_query or describe_table.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query and decode statistical observations from a Eurostat dataset with dimension filters and NUTS controls.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max inline rows to return (default 500) | |
| filters | No | Dimension filter dict, e.g. {"geo": ["FR", "DE", "IT"], "unit": ["CP_MEUR"]} | |
| dataset_id | Yes | Eurostat dataset code (e.g. "nama_10_gdp", "DS-059341") | |
| nuts_level | No | Optional NUTS geo filter: 'aggregate', 'country', 'nuts1', 'nuts2', 'nuts3' | |
| since_period | No | Start period (e.g. "2020", "2020M01") | |
| until_period | No | End period (e.g. "2023") | |
| last_n_periods | No | Number of most recent periods to retrieve (default 5) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure burden. It mentions 'decode' but does not explain what that entails (e.g., converting codes to labels), nor does it mention read-only nature, return limits, pagination, or error behavior. This is insufficient for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose and key features (dimension filters, NUTS controls). It contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters and an output schema, so the description needn't explain return values; however, it is terse about what 'decode' means and how this tool differs from similar siblings like download_dataset_to_sql. It provides basic context but lacks enough detail for a complex 7-param tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level detail beyond what the schema already provides, though it hints at filters and NUTS controls which map to specific parameters. It does not elevate the meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries and decodes statistical observations from a Eurostat dataset, with specific mention of dimension filters and NUTS controls. This distinguishes it from sibling tools like search_datasets (searching for datasets) and get_dataset_info (metadata retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving observations with filtering, but does not explicitly state when to use this tool over siblings or mention alternatives. There is clear context but no exclusions or comparisons, so it earns a 4 per rubric.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Eurostat catalogue by keyword with cursor pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max items per page (1-100, default 20) | |
| query | Yes | Keyword or phrase to search (e.g. "GDP", "unemployment", "inflation", "trade") | |
| cursor | No | Starting offset for pagination (default 0) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses cursor pagination as a behavioral trait, but does not explicitly state read-only behavior, rate limits, or other side effects. 'Search' implies read-only, but more detail would improve clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently captures the tool's purpose and pagination mechanism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of an output schema, and high schema coverage, the description is adequate. It could mention the return type or typical use cases, but the current level is sufficient for a straightforward search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. The description adds minimal extra meaning beyond the schema, only contextualizing the cursor as part of pagination. Baseline 3 is appropriate when schema handles all parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('search') and resource ('Eurostat catalogue') with a clear scope ('by keyword with cursor pagination'). It distinguishes from siblings like browse_themes and list_popular_datasets by focusing on keyword search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies using this tool when you need to search the catalogue by keyword, which provides clear context. However, it does not explicitly mention alternatives or when-not-to-use scenarios, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a read-only SQL SELECT query against staged in-memory DuckDB tables.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | SQL SELECT query string (e.g. "SELECT geo, AVG(value) FROM gdp_table GROUP BY geo ORDER BY AVG(value) DESC") |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It explicitly states 'read-only' and 'SELECT', which implies mutation is not allowed, and notes that tables are 'staged in-memory', indicating data persistence/availability constraints. It does not cover error handling or SQL dialect limitations, but these are partially covered by the schema and output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the verb and scope. It contains no fluff and every word contributes to understanding the tool's purpose and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers the essential context: read-only SQL execution against staged in-memory DuckDB tables. An output schema exists, so return values are handled separately. It could be more complete by explicitly listing prerequisites (e.g., tables must be staged) or limitations, but the phrase 'staged in-memory' implies this effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single 'query' parameter, including a concrete example. The description itself adds no extra parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Execute'), the specific operation ('read-only SQL SELECT query'), and the target resource ('staged in-memory DuckDB tables'). It distinguishes itself from sibling tools like query_dataset or get_dimension_values by specifying raw SQL execution against staged tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it is for running SQL SELECT queries against staged DuckDB tables. However, it does not explicitly mention when to use it versus alternatives like query_dataset, nor does it state exclusions (e.g., non-SELECT queries or tables that are not staged). The context is clear but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0browse_themesdescribe_tabledownload_dataset_to_sqlexport_multiple_datasetsexport_to_csvget_dataset_infoget_dimension_valueslist_popular_datasetslist_staged_tablesquery_datasetsearch_datasetssql_queryScored across 12 tools
Each tool targets a distinct phase of the Eurostat workflow: discovery, metadata inspection, data querying, SQL staging, and export. Even query_dataset and sql_query are clearly separatedโone queries the Eurostat API, the other queries staged DuckDB tables.
Most tools follow a verb-first snake_case pattern (get_, search_, browse_, list_, download_, export_), but sql_query breaks the pattern (noun-led) and export_to_csv vs export_multiple_datasets have inconsistent phrasing. Overall still readable and predictable.
With 12 tools, the server is well-scoped for Eurostat data access, covering discovery, metadata, querying, DL staging, SQL analysis, and export without ballooning in size. Each tool serves a clear purpose in the pipeline.
The tool surface covers the full Eurostat data lifecycle: find datasets, inspect dimensions, query data, stage to SQL, run SQL, and export. Minor gaps include no way to drop staged tables or list all datasets within a theme, but these are not critical for typical use.
Eurostat MCP โ wraps Eurostat Statistical Data API (no auth required)
Search and query the Eurostat catalogue โ EU economy, demography, trade, and NUTS regional data.
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
MCP server for Statistics Sweden (SCB) - 1200+ tables with population, economy, environment data