nl-opendata-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.1
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4/5 across 9 of 9 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on June 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![nl-opendata-mcp MCP server](https://glama.ai/mcp/servers/soulnai/nl-opendata-mcp/badges/card.svg)](https://glama.ai/mcp/servers/soulnai/nl-opendata-mcp)

Score Badge

Copy to your README.md:

[![nl-opendata-mcp MCP server](https://glama.ai/mcp/servers/soulnai/nl-opendata-mcp/badges/score.svg)](https://glama.ai/mcp/servers/soulnai/nl-opendata-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory 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