eurostat-mcp-server
Server Details
Search and query 8,933 Eurostat datasets — EU economy, demography, trade, and NUTS regional data.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/eurostat-mcp-server
- GitHub Stars
- 1
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 5 of 5 tools scored.
Each tool targets a distinct step in the Eurostat data workflow: browsing, searching, metadata retrieval, dimension value listing, and querying. No overlap in purpose.
All tools follow the consistent pattern 'eurostat_verb_noun' (browse_themes, get_dataset_info, get_dimension_values, query_dataset, search_datasets).
With 5 tools covering exploration, metadata, and data retrieval, the number is well-scoped for a statistical data server. No unnecessary tools and no obvious missing ones.
The tool set provides a complete workflow for discovering and querying Eurostat data: browse/search to find datasets, get metadata and dimension values, then query. No dead ends.
Available Tools
5 toolseurostat_browse_themesBrowse Eurostat Theme HierarchyARead-onlyIdempotentInspect
Navigate the Eurostat theme tree. Without theme_code returns the 11 top-level theme folders (Economy, Population, Transport, etc.) — the practical starting points. With a theme_code returns its immediate children: subtheme folders and datasets in that branch. Use this for structured discovery when you know the domain but not the dataset code, or to drill down from a broad topic to a specific dataset. Pair with eurostat_search_datasets for keyword-based discovery.
| Name | Required | Description | Default |
|---|---|---|---|
| theme_code | No | Folder code to expand (e.g., "econ", "reg"). Omit to list the 11 top-level theme folders. |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | Immediate children of the requested theme, or the 11 root themes if theme_code was omitted. |
| itemCount | Yes | Number of items returned in this level. |
| themeCode | No | Folder code that was browsed, or omitted for root. |
| parentPath | Yes | Breadcrumb from root to the requested theme (e.g., ["Economy and finance", "National accounts"]). Empty when browsing root. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent; the description adds context about returning top-level themes vs. immediate children, providing behavioral clarity beyond annotations.
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?
Three well-structured sentences with no redundancy; front-loaded with the main action rule and practical starting points.
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 output schema, the description fully covers the tool's behavior for browsing the hierarchy, making it complete for an agent to select and invoke 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 coverage is 100%, so baseline is 3. The description adds value by explaining the effect of omitting vs. providing theme_code and giving example codes like 'econ'.
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 navigates the Eurostat theme tree, explains behavior with and without a theme code, and distinguishes from sibling tools like eurostat_search_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?
Provides explicit scenarios for use (structured discovery, drilling down) and suggests pairing with the search tool for keyword-based discovery, though it doesn't explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurostat_get_dataset_infoGet Eurostat Dataset InfoARead-onlyIdempotentInspect
Fetch metadata for a Eurostat dataset: dimensions with valid values, time range, observation count, and last-update date. Call this before eurostat_query_dataset to discover what dimension codes are valid (unit, na_item, geo, etc.). Returns up to 10 sample values per dimension for orientation; use eurostat_get_dimension_values to list the full set for large dimensions.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_code | Yes | Dataset code (e.g., "nama_10_gdp"). Use eurostat_search_datasets or eurostat_browse_themes to find codes. |
Output Schema
| Name | Required | Description |
|---|---|---|
| code | Yes | Dataset code as provided. |
| label | Yes | Human-readable dataset title. |
| obsCount | Yes | Total number of observations in the full dataset (all periods). |
| timeRange | Yes | Overall data coverage period for this dataset. |
| dimensions | Yes | All dimensions of the dataset with their valid codes and labels. |
| lastUpdated | Yes | ISO 8601 timestamp of the most recent data update. |
| metadataUrl | No | URL to the ESMS HTML metadata page for this dataset. Omitted when not provided by Eurostat. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, idempotent. The description adds that it returns up to 10 sample values per dimension and directs to eurostat_get_dimension_values for full sets, providing useful behavioral context beyond annotations.
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?
Two sentences, first covers purpose/content, second gives usage guidance and data limitation. No fluff, every sentence 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 1 parameter, presence of output schema, and annotations covering safety, the description fully addresses what the tool does, when to use it, its data limit, and how to find codes via siblings. No 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?
Input schema has 1 parameter (dataset_code) with 100% coverage via description. The description does not add new meaning beyond the schema's examples and references to find codes, so baseline 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 states the tool fetches metadata (dimensions with valid values, time range, observation count, last-update date) and distinguishes it from siblings like eurostat_query_dataset and eurostat_get_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?
Explicitly says to call this before eurostat_query_dataset to discover valid dimension codes, and suggests eurostat_search_datasets or eurostat_browse_themes to find dataset codes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurostat_get_dimension_valuesGet Eurostat Dimension ValuesARead-onlyIdempotentInspect
List all valid values for a specific dimension in a Eurostat dataset (e.g., all unit codes for nama_10_gdp, all geo codes for a regional dataset). Use this when eurostat_get_dataset_info returns more values than the 10-item sample, or to confirm exact codes before querying. For the "geo" dimension, use geo_level to filter by NUTS hierarchy (country, nuts1, nuts2, nuts3). Invalid dimension_value codes passed to eurostat_query_dataset silently return no data; use this tool to verify codes first.
| Name | Required | Description | Default |
|---|---|---|---|
| dimension | Yes | Dimension code to retrieve values for (e.g., "unit", "na_item", "geo"). Use eurostat_get_dataset_info to see available dimensions. | |
| geo_level | No | NUTS hierarchy level filter — only relevant when dimension is "geo". Options: "aggregate" (EU/EA codes), "country" (2-letter codes, default), "nuts1" (3-char), "nuts2" (4-char), "nuts3" (5-char). | |
| dataset_code | Yes | Dataset code (e.g., "nama_10_gdp"). |
Output Schema
| Name | Required | Description |
|---|---|---|
| values | Yes | All valid values for this dimension in the dataset. |
| totalCount | Yes | Total number of distinct values returned. |
| dimensionCode | Yes | The dimension code that was queried. |
| dimensionLabel | Yes | Human-readable dimension name. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint. Description adds valuable context: that invalid codes silently return no data for eurostat_query_dataset, making the verification purpose clearer.
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?
Three sentences, front-loaded with purpose, no fluff, every sentence earns its place.
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 output schema exists and schema covers all params, description covers usage scenarios, geo filtering, and silent failure warning. Complete for a list-all-values 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 coverage is 100%, so baseline 3. Description adds substantial value for geo_level by explaining NUTS hierarchy options. For dimension, it references eurostat_get_dataset_info, and for dataset_code, example given.
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?
Clear verb+resource: 'List all valid values for a specific dimension'. Distinguishes from siblings like eurostat_get_dataset_info and eurostat_query_dataset.
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?
Explicitly states when to use: when dataset info returns more than 10 items or to confirm codes. Mentions eurostat_get_dataset_info as alternative. Lacks explicit when-not-to-use but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurostat_query_datasetQuery Eurostat DatasetARead-onlyIdempotentInspect
Fetch statistical data from a Eurostat dataset with dimension filters. Returns decoded observations with dimension codes and labels, numeric values, and status flags (e.g., "p" = provisional, "e" = estimated). Call eurostat_get_dataset_info first to discover valid dimension codes and values. Apply filters to keep the result set manageable — large unfiltered queries may trigger an async response error. Use filters.geo for specific country/region codes, or geo_level for NUTS hierarchy filtering (mutually exclusive). Use last_n_periods for the N most recent periods without knowing the end date.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language for labels in the response. Default is "EN". Options: "EN", "FR", "DE". | EN |
| filters | No | Dimension filters as a map of dimension code → array of valid values. Example: {"unit": ["CP_MEUR"], "na_item": ["B1GQ"], "geo": ["DE", "FR"]}. Do not include "geo" here if using geo_level. Invalid dimension values silently return no data — verify with eurostat_get_dimension_values first. | |
| geo_level | No | Filter by NUTS hierarchy level. Mutually exclusive with a "geo" key in filters. Options: "aggregate" (EU/EA totals), "country" (41 member/candidate states), "nuts1" (127 major regions), "nuts2" (309 basic regions), "nuts3" (1,343 small regions). | |
| dataset_code | Yes | Dataset code (e.g., "nama_10_gdp"). Required. | |
| since_period | No | Start of time range (e.g., "2020", "2023-Q1", "2024-01"). Mutually exclusive with last_n_periods. | |
| until_period | No | End of time range (e.g., "2024"). Omit for data through the latest available period. Mutually exclusive with last_n_periods. | |
| last_n_periods | No | Return only the N most recent periods. Mutually exclusive with since_period and until_period. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when the result was truncated at 5,000 rows. Omitted for normal results. |
| obsCount | Yes | Total number of observations matched (before any cap). |
| timeRange | Yes | Time coverage of the returned observations. |
| truncated | Yes | True when the result exceeded 5,000 observations and was capped. Apply dimension filters to get the full result. |
| datasetCode | Yes | Dataset code as provided. |
| datasetLabel | Yes | Human-readable dataset title. |
| observations | Yes | Decoded observations, capped at 5,000 rows. When truncated is true, apply dimension filters to narrow the result. |
| appliedFilters | Yes | Effective query parameters applied to the Eurostat API. |
| dimensionsUsed | Yes | Ordered list of dimension codes present in the response (e.g., ["freq", "unit", "na_item", "geo", "time"]). |
| missingObsCount | Yes | Number of observations with null value (missing data points in the source). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it warns about async response errors for large queries, describes output structure (decoded observations with codes, labels, numeric values, status flags), and notes that invalid dimension values silently return no data. Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint, and the description does not contradict them.
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 concise, consisting of five sentences that front-load the core purpose in the first sentence. It efficiently covers essential usage guidelines, error conditions, and parameter relationships without unnecessary verbosity.
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 complexity (7 parameters, nested objects, output schema), the description covers the workflow (call info first), error handling (async error, silent failures), parameter usage (filter choices, time range options), and return format (decoded observations, status flags). The existence of an output schema reduces the burden, and the description complements it well.
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?
With 100% schema coverage, all parameters have descriptions in the schema. However, the description adds significant meaning beyond the schema: it explains the relationship between filters.geo and geo_level (mutually exclusive), clarifies that last_n_periods allows getting recent periods without knowing the end date, and warns about silent failures for invalid dimension values.
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 'Fetch statistical data from a Eurostat dataset with dimension filters', specifying verb and resource. It distinguishes from sibling tools like eurostat_get_dataset_info (metadata discovery) and eurostat_search_datasets (searching), making the tool's role 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 provides explicit guidance: call eurostat_get_dataset_info first to discover valid dimensions, apply filters to keep results manageable, explains that large unfiltered queries may trigger async errors, and clarifies mutual exclusivity of filters.geo and geo_level as well as last_n_periods vs since_period/until_period. It also mentions when not to use certain filter combinations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eurostat_search_datasetsSearch Eurostat DatasetsARead-onlyIdempotentInspect
Search the Eurostat catalogue (8,933 datasets) by keyword. Returns matching datasets with codes, descriptions, period coverage, and theme breadcrumbs. Use this to discover dataset codes before calling eurostat_get_dataset_info or eurostat_query_dataset. Results are limited to datasets and predefined tables — folders are excluded.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (1–100). Default is 20. | |
| query | Yes | Search terms — case-insensitive substring match against dataset labels. |
Output Schema
| Name | Required | Description |
|---|---|---|
| query | Yes | Search terms as submitted. |
| datasets | Yes | Matching datasets, up to the requested limit. |
| totalMatches | Yes | Total datasets matching the query before the limit. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so description doesn't need to repeat safety. It adds context about search behavior and return fields, plus the scope limitation (no folders). No contradictions.
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?
Description is four sentences, front-loaded with purpose, and contains no extraneous information. Every sentence 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 the simple parameters and existence of output schema, the description covers search behavior, scope, and relationship to sibling tools. It includes key details like exclusion of folders and return fields.
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 coverage is 100% with descriptions for both parameters. The description mentions 'keyword' which aligns with the 'query' parameter but does not add new meaning beyond the schema. Baseline 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?
Description clearly states 'Search the Eurostat catalogue' with specific verb and resource, and distinguishes from sibling tools (eurostat_get_dataset_info, eurostat_query_dataset) by focusing on dataset discovery. It mentions returning specific fields like codes, descriptions, period coverage, and theme breadcrumbs.
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?
Explicitly states 'Use this to discover dataset codes before calling eurostat_get_dataset_info or eurostat_query_dataset.' Also notes that results are limited to datasets and predefined tables, excluding folders, providing clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!