The nl-opendata-mcp server provides an MCP interface to discover, explore, query, and export Dutch government open data from CBS (Statistics Netherlands) and data.overheid.nl, covering 4800+ statistical datasets.
Discovery & Search
List all available CBS datasets (with pagination) or search by keyword in title, summary, or both
Check whether a dataset is queryable via CBS OData or download-only via data.overheid.nl
Inspect dataset details: title, dimensions, measures, column definitions, data types, and sample rows
Estimate dataset size (row/column counts) and get a recommended fetch strategy before downloading
Metadata Retrieval
Retrieve dataset info, column structure, available endpoints, and dimension values/filter codes (e.g., gender, time period categories)
Data Querying & Export
Query datasets with OData filter syntax, column selection, pagination, and automatic translation of coded values to human-readable text
Save datasets to CSV files (full or partial, with optional value translation)
Save datasets to a DuckDB database for efficient local SQL querying
List previously downloaded local CSV files with their sizes and row counts
Analysis (optional, disabled by default due to security implications)
Execute Python/Pandas code directly on remote CBS datasets or local CSV files for on-the-fly statistics, filtering, and aggregation
Accesses Dutch government open data from CBS (Centraal Bureau voor de Statistiek), including browsing, searching, querying, and downloading over 4800 datasets.
Saves datasets directly to DuckDB for efficient SQL-based querying and analysis.
Executes Python Pandas code on datasets for custom data analysis and manipulation.
Click on "Install 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., "@nl-opendata-mcp search for CBS datasets about population"
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.
A comprehensive Model Context Protocol (MCP) server for accessing Dutch government open data from CBS (Centraal Bureau voor de Statistiek) and data.overheid.nl.
This is a small side project to experiment with MCP and see if it can be useful for accessing Dutch government open data. It is not production ready and should not be used for production.
I have tested it with Claude Desktop and LM Studio and it works wreasonably well. It should work with the most MCP clients. The results are always dependent on the quality of the model you use. Frontier models understand data and mcp tools well and produce good results. Local models may not understand the tools calling and produce unexpected results.
For local models I got the best results using the Devstral2 small model with gpt-oss 20b close second. Context length is a very limiting factor for local models. Yo will need at least 30k tokens context length for basic analysis to work.
📊 Access 4800+ CBS Datasets - Browse and query statistical data on population, economy, health, environment, and more
🔍 Smart Search - Search datasets by title, summary, or both with local caching for fast results
📥 Flexible Data Fetching - Query, filter, and download datasets in CSV or Parquet format
🐍 Python Analysis - Execute Pandas code directly on datasets without downloading
🗂️ Dual Source Support - Check availability across CBS OData and data.overheid.nl
Related MCP server: dutch-gov-mcp
# Run directly from PyPI
uvx nl-opendata-mcp
# Or run directly from GitHub
uvx --from git+https://github.com/soulnai/nl-opendata-mcp.git nl-opendata-mcp# Install from PyPI
uv pip install nl-opendata-mcp
# Install from GitHub
uv pip install git+https://github.com/soulnai/nl-opendata-mcp.git# Clone the repository
git clone https://github.com/soulnai/nl-opendata-mcp.git
cd nl-opendata-mcp
# Install dependencies and package in editable mode
uv sync
uv pip install -e .
# Run the server
uv run nl-opendata-mcpAdd to your Claude Desktop configuration (claude_desktop_config.json):
{
"mcpServers": {
"nl-opendata-mcp": {
"command": "uvx",
"args": ["nl-opendata-mcp"]
}
}
}Add to your LM Studio configuration (mcp.json):
{
"mcpServers": {
"nl-opendata-mcp": {
"command": "uvx",
"args": ["nl-opendata-mcp"]
}
}
}The server supports different transport modes:
# Default: stdio transport
uvx nl-opendata-mcp
# HTTP transport (port 8000)
TRANSPORT=http uvx nl-opendata-mcp
# SSE transport (port 8000)
TRANSPORT=sse uvx nl-opendata-mcpTool | Description |
| List available datasets from the CBS catalog |
| Search datasets by keyword (in title, summary, or both) |
| Check if a dataset is available via CBS OData or data.overheid.nl |
| Estimate dataset size before fetching (rows, columns, recommended strategy) |
| Get comprehensive dataset summary (metadata, structure, sample data) |
Tool | Description |
| Unified metadata tool - get info, structure, dimension values, or custom endpoints |
cbs_get_metadata types:
metadata_type="info" - Dataset description (TableInfos)
metadata_type="structure" - Column definitions and data types (DataProperties)
metadata_type="endpoints" - Available metadata endpoints
metadata_type="dimensions" - Dimension values with codes for filtering (requires endpoint_name)
metadata_type="custom" - Query custom endpoint (requires endpoint_name)
Tool | Description |
| Query data with filtering and column selection |
| Save dataset to CSV (use |
Tool | Description |
| Execute Python/Pandas code on a remote dataset |
| Execute Python/Pandas code on a local CSV file |
List available datasets:
Use cbs_list_datasets with top=20 to see the first 20 datasetsSearch for population data:
Use cbs_search_datasets with query="bevolking" to find population datasetsSearch only in titles:
Use cbs_search_datasets with query="inflatie" and search_field="title"Get a comprehensive overview (recommended first step):
Use cbs_inspect_dataset_details with dataset_id="85313NED"
# Returns:
# - Source confirmation (CBS OData or data.overheid.nl)
# - Title and description
# - Column definitions with types
# - Sample data (first 5 rows)Check dataset size before fetching:
Use cbs_estimate_dataset_size with dataset_id="85313NED"
# Returns:
# - Estimated row count
# - Column count
# - Recommended fetch strategyGet detailed column structure:
Use cbs_get_metadata with dataset_id="85313NED" and metadata_type="structure"
# Returns CSV with: Key, Type, Title, Description for each columnBasic query with pagination:
Use cbs_query_dataset with:
- dataset_id="85313NED"
- top=100
- skip=0Query with OData filter:
Use cbs_query_dataset with:
- dataset_id="85313NED"
- filter="Perioden eq '2023JJ00'"
- top=50Select specific columns:
Use cbs_query_dataset with:
- dataset_id="85313NED"
- select=["Perioden", "TotaleBevolking_1", "Mannen_2", "Vrouwen_3"]
- top=100Query with multiple conditions:
Use cbs_query_dataset with:
- dataset_id="85313NED"
- filter="Perioden eq '2023JJ00' and Leeftijd eq '10000'"Save complete dataset to CSV:
Use cbs_save_dataset with:
- dataset_id="85313NED"
- file_name="population_data.csv"
- fetch_all=trueNote: Analysis tools are disabled by default. To enable them, set USE_PYTHON_ANALYSIS=true in the environment. It is security risk to let the model write and execute Python code on a client machine. Recommended for advanced users only. It's better to let the model query and save the data to a file, and let your CLI LLM coding tool to analyse it by writing and executing scripts. If you are running it in a non CLI environment (like LM Studio) and still want to give it the ability to analyse data, you can enable it by setting USE_PYTHON_ANALYSIS=true in the environment.
Analyze remote dataset with Pandas:
Use cbs_analyze_remote_dataset with:
- dataset_id="85313NED"
- analysis_code="print(df.describe())"Calculate statistics:
Use cbs_analyze_remote_dataset with:
- dataset_id="85313NED"
- analysis_code="result = df['TotaleBevolking_1'].mean()"Filter and aggregate:
Use cbs_analyze_remote_dataset with:
- dataset_id="85313NED"
- analysis_code="""
filtered = df[df['Perioden'].str.contains('2023')]
result = filtered.groupby('Leeftijd')['TotaleBevolking_1'].sum()
print(result)
"""Analyze a local CSV file:
Use cbs_analyze_local_dataset with:
- dataset_path="downloads/85313NED_full.csv"
- analysis_code="print(df.info())"Get classification codes (e.g., gender categories):
Use cbs_get_metadata with:
- dataset_id="85313NED"
- metadata_type="dimensions"
- endpoint_name="Geslacht"Get time period definitions:
Use cbs_get_metadata with:
- dataset_id="85313NED"
- metadata_type="dimensions"
- endpoint_name="Perioden"1. cbs_search_datasets(query="unemployment") # Find relevant datasets
2. cbs_inspect_dataset_details(dataset_id="82809NED") # Get overview
3. cbs_query_dataset(dataset_id="82809NED", top=10) # Preview data1. cbs_estimate_dataset_size(dataset_id="85313NED") # Check size
2. cbs_save_dataset(dataset_id="85313NED", fetch_all=True) # Save full dataset to CSV
3. cbs_analyze_local_dataset(...) # Analyze locally with Pandas1. cbs_get_metadata(dataset_id="85313NED", metadata_type="structure") # Get column names
2. cbs_get_metadata(dataset_id="85313NED", metadata_type="dimensions", endpoint_name="Perioden") # Get period codes
3. cbs_query_dataset(dataset_id="85313NED", filter="Perioden eq '2023JJ00'", select=["..."]) # Query
4. cbs_save_dataset(dataset_id="85313NED", file_name="filtered_data.csv") # ExportFormat | Use Case |
CSV | Universal compatibility, works with Excel, Pandas, etc. |
The CBS OData API uses OData v3 syntax for filtering:
# Exact match
Perioden eq '2023JJ00'
# Substring match
substringof('Amsterdam', RegioS)
# Multiple conditions
Perioden eq '2023JJ00' and Leeftijd eq '10000'
# OR conditions
Geslacht eq '1100' or Geslacht eq '2000'
# Numeric comparisons
TotaleBevolking_1 gt 100000Checks if a dataset is available via CBS OData (queryable) or data.overheid.nl (download-only).
Args: params: DatasetIdInput containing: - dataset_id (str): Dataset ID (e.g., '83583NED')
Returns: str: Availability status and source information
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input model for operations that only need a dataset ID. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds context about the two sources and return type, but does not detail the response structure beyond a string status. It does not contradict 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?
The description is concise with two short paragraphs covering purpose, args, and returns. It is front-loaded with the main purpose and contains no unnecessary words.
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 has one parameter, high schema coverage, annotations, and an output schema, the description provides sufficient context for basic usage. It could specify the return format more precisely, but overall is adequate.
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 params and dataset_id. The description repeats the example and mentions DatasetIdInput, adding minimal value beyond the schema. It does list the sources, which is additional 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 clearly states 'Checks if a dataset is available via CBS OData (queryable) or data.overheid.nl (download-only),' which is a specific verb and resource, and distinguishes between two sources, helping differentiate from sibling 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?
The description explains when to use the tool (to check availability) and the two sources, but does not explicitly state when not to use it or compare with alternatives. It is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimates the size of a dataset before fetching.
Args: params: DatasetIdInput containing: - dataset_id (str): Dataset ID (e.g., '85313NED')
Returns: str: Size estimation with row count, column count, and recommended fetch strategy
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input model for operations that only need a dataset ID. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover readOnly, destructive, idempotent, openWorld hints fully. Description adds output details (row count, column count, fetch strategy), which is useful 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?
Short and to the point. The 'Args:' and 'Returns:' formatting is slightly verbose but still concise overall. No unnecessary words.
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 one parameter, full schema coverage, and existing output schema, the description fully covers what an agent needs. No missing details.
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%, description essentially repeats schema with minor restructuring. Adds some clarity on nested object but no novel meaning beyond schema descriptions.
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 estimates dataset size before fetching, with a specific verb and resource. This distinguishes it from siblings like cbs_check_dataset_availability or cbs_get_metadata.
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?
Implied usage from 'before fetching', but no explicit when-not-to-use or alternatives among siblings. Provides some guidance via return value mentioning 'recommended fetch strategy'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unified metadata tool for detailed info, structure, dimension values, or custom endpoints.
Args: params: GetMetadataInput containing: - dataset_id (str): Dataset ID (e.g., '85313NED') - metadata_type (str): Type of metadata: - 'info': Dataset description (TableInfos) - 'structure': Column definitions (DataProperties) - 'endpoints': Available metadata endpoints - 'dimensions': Dimension values with codes for filtering (requires endpoint_name) - 'custom': Custom endpoint query (requires endpoint_name) - endpoint_name (str, optional): Required for 'dimensions' and 'custom' types (e.g., 'Geslacht', 'Perioden', 'Luchthavens')
Returns: str: CSV for info/structure/dimensions, JSON for endpoints/custom
Examples: - Get columns: metadata_type="structure" - Get dimension codes: metadata_type="dimensions", endpoint_name="Geslacht" - Get raw endpoint: metadata_type="custom", endpoint_name="CategoryGroups"
IMPORTANT - Finding Dimension Codes: Use metadata_type="dimensions" to find codes for OData filtering. CBS uses coded values (e.g., 'A043591') that map to names (e.g., 'Eindhoven Airport').
Workflow:
1. Get dimension codes: metadata_type="dimensions", endpoint_name="Luchthavens"
2. Use code in query: filter="Luchthavens eq 'A043591'"| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input model for unified metadata retrieval. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds context about return formats (CSV for info/structure/dimensions, JSON for endpoints/custom) and constraints like endpoint_name requirement, enhancing transparency without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections and examples. It is front-loaded with the purpose. However, some repetition occurs (e.g., the 'IMPORTANT' section slightly duplicates earlier info), making it a bit longer than necessary, but still effective.
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 and that an output schema exists, the description covers all metadata types, explains return formats, and provides a complete workflow for dimension codes. It addresses the tool's role in relation to sibling tools and leaves no obvious 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 coverage is 100%, so baseline is 3. The description adds significant value by providing explanations, examples, and clarifying the interdependency between metadata_type and endpoint_name. It also includes a workflow example that enriches understanding 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 explicitly states it is a 'Unified metadata tool' and lists five specific metadata types (info, structure, dimensions, endpoints, custom), making the verb-resource pair very clear. It distinguishes itself from sibling tools like cbs_query_dataset and cbs_inspect_dataset_details which handle data queries or dataset inspection.
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 detailed guidance including a workflow for finding dimension codes for OData filtering, explicit requirements for endpoint_name, and example use cases. It effectively tells when to use each metadata_type, 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.
Compact dataset overview: title, dimensions, measures, and sample data. Use this first to understand a dataset's structure.
Args: params: DatasetIdInput containing: - dataset_id (str): Dataset ID (e.g., '85313NED')
Returns: str: Compact report with title, column list, and 3-row sample
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input model for operations that only need a dataset ID. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds behavioral details: returns a compact report with title, column list, and 3-row sample. No contradictions, and adds value 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?
The description is two sentences plus an Args/Returns block, no wasted words. Front-loaded with purpose and usage guidance. Efficient and well-organized.
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 tool with one parameter and an output schema, the description provides sufficient context: what it does, when to use, and what the output contains (sample data, column list). 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?
Schema description coverage is 100%, with both 'params' and 'dataset_id' having descriptions. The description repeats these ('Dataset ID (e.g., '85313NED')') but adds no new semantic information. 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 clearly states 'Compact dataset overview: title, dimensions, measures, and sample data. Use this first to understand a dataset's structure.' It specifies the verb 'inspect' and resource 'dataset details', and distinguishes from siblings by emphasizing it's an initial overview tool.
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 'Use this first to understand a dataset's structure,' providing clear when-to-use context. Does not explicitly mention when not to use or alternatives, but the context from siblings makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists available datasets from the CBS OData Catalog.
Args: params: ListDatasetsInput containing: - top (int): Number of records to return (default: 10, max: 1000) - skip (int): Number of records to skip (default: 0)
Returns: str: CSV string containing dataset list with columns: Identifier, Title, Summary
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input model for listing datasets. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description adds limited behavioral context. It does disclose the return format (CSV string with columns), which is helpful. No additional behaviors (e.g., pagination details beyond what schema provides) are described.
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 with no unnecessary words. It uses a clear structured format (Args, Returns) that is easy to parse. 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?
The description covers the tool's purpose, parameters, and return format adequately. An output schema exists (not shown), but the description states the CSV columns, which is sufficient for understanding what the tool does. Could mention error handling or rate limits, but not essential for a read-only list operation.
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 coverage is 100%, and the description repeats parameter defaults and boundaries already present in the schema. It adds explicit default values (10 for top, 0 for skip), but this is marginal value. 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 'Lists available datasets from the CBS OData Catalog', which is a specific verb+resource. However, it does not explicitly differentiate from siblings like 'cbs_search_datasets' or 'cbs_list_local_datasets', which could cause confusion about when to use this tool.
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 guidance is provided on when to use this tool versus alternatives. Siblings exist (e.g., search, local), but the description does not mention them or specify scenarios. This leaves the agent to infer usage without support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all locally saved CSV datasets in the downloads directory.
Returns: str: List of CSV files with sizes and row counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint as true, indicating safe, non-destructive behavior. The description adds transparency by stating the return format includes 'sizes and row counts,' which is not captured in annotations. 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?
The description is two sentences, no unnecessary words, and front-loads the core purpose. Every sentence adds value: the first states the action, the second describes the return format.
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 list tool with no parameters and rich annotations, the description is largely complete. It specifies the return as a string with CSV files, sizes, and row counts. A minor gap is not stating whether file paths are included or just names, but given the output schema exists (though not shown), this is acceptable.
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 schema coverage is 100%. The description does not need to add parameter details. According to calibration, baseline is 4 for no 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 explicitly states 'Lists all locally saved CSV datasets in the downloads directory,' which clearly indicates the tool's purpose with a specific verb and resource. It distinguishes itself from siblings like cbs_list_datasets (likely global) and cbs_inspect_dataset_details (detailed inspection) by specifying 'locally saved' and '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 for listing local CSV files but provides no explicit guidance on when to use this tool versus alternatives such as cbs_list_datasets or cbs_search_datasets. It lacks when-not-to-use or alternative recommendations, leaving reliance on agent inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queries data from a dataset with optional filtering and column selection.
Args: params: QueryDatasetInput containing: - dataset_id (str): Dataset ID (e.g., '85313NED') - top (int): Number of records (default: 10) - skip (int): Records to skip (default: 0) - filter (str, optional): OData filter (e.g., "Perioden eq '2023JJ00'") - select (List[str], optional): Column names to return - compact (bool): Return summary for large results (default: True) - translate (bool): Translate coded dimension values to text (default: True)
Returns: str: CSV data with human-readable dimension values
Note: Use cbs_get_metadata with metadata_type="dimensions" to find filter codes.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input model for querying datasets. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: returns CSV, uses OData filter syntax, and translates dimension values. Annotations already provide safety profile.
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?
Well-structured with Args and Returns sections, but slightly verbose. Could be more concise while retaining clarity.
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?
Covers all parameters, explains return format (CSV), includes annotations, and references sibling for metadata. Sufficient for a query 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 repeats parameter info but adds example filter and translate explanation, adding marginal 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?
Clear verb 'Queries' and resource 'data from a dataset', with optional filtering and column selection. Distinguishes from siblings by referencing cbs_get_metadata for filter codes.
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?
Implies usage for querying data and hints at using cbs_get_metadata for filter codes, but lacks explicit guidance on when to use this tool versus alternatives or 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.
Saves a dataset to a CSV file.
Args: params: SaveDatasetInput containing: - dataset_id (str): Dataset ID (e.g., '85313NED') - file_name (str): File name to save the dataset - top (int): Records per request (default: 1000) - skip (int): Records to skip (default: 0) - fetch_all (bool): Fetch all records with pagination (default: False) - translate (bool): Translate coded values to text (default: True)
Returns: str: Success message with file path and record count
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input model for saving datasets. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false, suggesting overwrite behavior. The description does not add details about file overwrite, error handling, or permission requirements. With annotations present, the bar is lower, but missing file behavior context limits transparency.
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 followed by a parameter list. While concise, the parameter list is redundant with the input schema. Still, it is front-loaded and not verbose, earning a 4.
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 saves to a file, but the description lacks details about file handling (overwrite behavior, required permissions, supported formats). An output schema exists, mitigating the need for return value details, but file behavior context is missing.
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 repeats parameter meanings from the schema without adding new insights. It does not clarify parameter interactions beyond what the schema already provides (e.g., fetch_all vs top/skip).
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 'Saves a dataset to a CSV file,' specifying the verb and resource. It differentiates from siblings like cbs_save_dataset_to_duckdb (saves to DuckDB) and other query/list tools, making the purpose specific and 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?
No explicit guidance on when to use this tool versus alternatives (e.g., cbs_save_dataset_to_duckdb or cbs_query_dataset). The description only lists parameters without explaining context, prerequisites, or situations where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches for datasets in the CBS OData Catalog by keyword.
Args: params: SearchDatasetsInput containing: - query (str): Search term (e.g., "Bevolking", "Inflation") - top (int): Number of records to return (default: 10) - skip (int): Number of records to skip (default: 0) - search_field (str): Where to search - "all", "title", or "summary"
Returns: str: CSV string containing matching datasets
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input model for searching datasets. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, covering safety and idempotency. The description adds that results are returned as a CSV string, which is useful but not a major behavioral disclosure 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?
The description is concise: two sentences for overall purpose, followed by a structured bullet list for parameters. It avoids fluff and is easy to scan.
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 and the existence of annotations and output schema mention (CSV string), the description fully covers what the tool does, its parameters, and its return type. No gaps remain for this 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 description coverage is 100%, with each parameter already documented in the schema. The description repeats those descriptions verbatim (e.g., 'query (str): Search term'). It adds no new meaning or context beyond what the schema provides.
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 'Searches for datasets in the CBS OData Catalog by keyword,' specifying the action (searches), resource (datasets), and context (CBS OData Catalog). This distinguishes it from sibling tools like cbs_list_datasets (which lists all) and cbs_inspect_dataset_details (which shows details of a specific 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?
The description implies usage when a keyword search is needed, but it does not explicitly state when to use this tool over alternatives (e.g., cbs_list_datasets). Given multiple siblings, explicit when-to-use and when-not-to-use guidance would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tool serves a clearly distinct purpose: listing, searching, checking availability, estimating size, retrieving metadata, inspecting details, querying data, saving to file, and listing local files. There is no overlap or ambiguity.
All tools follow a consistent 'cbs_verb_noun' pattern in snake_case (e.g., cbs_list_datasets, cbs_query_dataset). The naming is predictable and well-structured.
With 9 tools covering discovery, metadata, querying, and local storage, the count is well-scoped for a data access server. Each tool is justified and the set feels neither sparse nor bloated.
The tool surface covers the full lifecycle of working with CBS datasets: discovery, metadata inspection, size estimation, querying with filtering, and saving locally. Minor gaps exist (e.g., no delete for local files, no direct download without saving), but these do not hinder core workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
data.overheid.nl MCP — the Netherlands national open-data portal (CKAN API).
Netherlands Open Data (data.overheid.nl/data) CKAN MCP.
Statistics Netherlands (CBS / StatLine) OData MCP.
Search and query government open-data portals (Socrata SODA API).
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/soulnai/nl-opendata-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server