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. |
| 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?
Beyond annotations (readOnlyHint, idempotentHint), the description discloses the tree navigation behavior, two operational modes, and return contents (folders and datasets). 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?
Two sentences, no redundancy. Front-loaded with verb and resource. Every sentence adds value: behavior, examples, usage guidance.
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?
With an output schema present and low complexity, the description fully covers all needed context for correct invocation, including pairing with a sibling 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%, but description adds context: modes of use, examples of theme codes, and 'practical starting points'. Provides meaning beyond the schema's parameter description.
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, with specific behavior for with/without theme_code. It distinguishes from siblings like eurostat_search_datasets by focusing on structured discovery.
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 you know the domain but not the dataset code, or to drill down. Suggests pairing with eurostat_search_datasets for keyword discovery. Lacks explicit 'when not to use' but context is clear.
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 |
|---|---|---|
| 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. |
| 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?
Adds key behavioral details beyond annotations: mentions silent failure for invalid dimension values, async response error for large queries, and clarifies the response structure with status flags. Annotations already indicate read-only and idempotent; description enriches with practical constraints.
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?
Concise single paragraph with front-loaded purpose, followed by output details, prerequisite, warnings, and parameter notes. Every sentence adds value with no redundancy.
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 complexity (7 params, nested object, output schema), the description covers purpose, output, prerequisite, error conditions, and parameter relationships. It is complete for a data retrieval tool with an existing output schema.
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 all 7 parameters with descriptions. The description adds mutual exclusivity clarifications, a warning about silent failures, and a use case for last_n_periods. This goes beyond schema basics, earning above-baseline score.
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?
Clearly states it fetches statistical data with dimension filters, and distinguishes from siblings by specifying return types (observations, codes, labels, values, status flags) and mentioning the prerequisite call to eurostat_get_dataset_info.
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 advises to call eurostat_get_dataset_info first, warns about large unfiltered queries causing async errors, and describes mutual exclusivity rules for filters.geo vs geo_level and last_n_periods vs time range. Lacks explicit 'when not to use' but provides sufficient context.
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 |
|---|---|---|
| datasets | Yes | Matching datasets, up to the requested limit. |
| totalMatches | Yes | Total number of datasets matching the query before the limit is applied. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds behavioral details (case-insensitive substring match, exclusion of folders) beyond annotations, with 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?
Three sentences front-loaded with purpose, then details and usage guidance. No redundant phrases; every sentence serves a 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?
Given the presence of an output schema (not shown but present), the description adequately covers return fields (codes, descriptions, coverage, breadcrumbs) and catalogue size, making it complete for a 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?
Schema coverage is 100% with descriptions for both parameters. The description adds value by clarifying that query is a case-insensitive substring match against labels and states the default limit.
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 it searches the Eurostat catalogue by keyword, returns specific fields, and explicitly distinguishes from sibling tools (eurostat_get_dataset_info, eurostat_query_dataset) by stating its role in discovery.
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 when-to-use guidance ('discover dataset codes before calling...'), mentions alternatives by name, and notes exclusion of folders.
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!