dutch-gov-mcp

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation4/5
Most tools have distinct purposes, such as get_cbs_dataset vs. get_dataset for CBS-specific vs. general metadata, and lookup_company vs. lookup_company_finances for different company data types. However, some overlap exists between search_cbs_datasets and search_datasets, which could cause confusion despite their CBS vs. general focus.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, with clear prefixes like 'get_', 'list_', 'lookup_', 'query_', and 'search_' that align with their actions. This uniformity makes the tool set predictable and easy to navigate.
Tool Count5/5
With 14 tools, the server is well-scoped for its domain of Dutch government data access, covering CBS statistics, company lookups, and general dataset searches. Each tool serves a specific function without redundancy, making the count appropriate for the server's purpose.
Completeness4/5
The tool set provides comprehensive coverage for querying and retrieving Dutch government data, including metadata, dimensions, resources, and statistical queries. A minor gap is the lack of update or delete operations, but this is reasonable for a read-only data access server, and agents can work around this limitation.
Average 3.2/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves details but does not disclose any behavioral traits such as required permissions, rate limits, error handling, or whether it's a read-only operation. This is inadequate for a tool with no annotation coverage.
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 a single, efficient sentence with zero waste. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration, making it highly concise and well-structured.
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?
Given the tool's low complexity (single parameter, no annotations) and the presence of an output schema, the description is minimally complete. It states the basic purpose but lacks context on behavior, usage, or differentiation from siblings, which is insufficient for full understanding despite the output schema covering return values.
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?
The description adds no meaning beyond the input schema, which has 100% coverage and fully documents the 'resource_id' parameter. With high schema coverage, the baseline is 3, as the description does not compensate with additional context like format examples or usage notes for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the purpose ('Get details about a specific file/resource') which is clear but vague. It uses a generic verb 'get details' and resource 'file/resource' without specifying what details are returned or distinguishing it from siblings like 'list_resources' or 'get_dataset'. It avoids tautology but lacks specificity.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or compare to sibling tools such as 'list_resources' for browsing or 'get_dataset' for similar operations. Usage is implied only by the name, with no explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but lacks critical behavioral details: it doesn't specify if this is a read-only operation (implied by 'Get' but not explicit), what the output format is (though an output schema exists), error conditions, rate limits, or authentication needs. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
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 appropriately sized and front-loaded: the first sentence states the core purpose, and the second adds clarifying context about dimensions. Both sentences earn their place by defining the tool and explaining 'dimensions', with no wasted words. However, it could be slightly more structured (e.g., by explicitly noting it's a read operation), preventing a perfect score.
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?
Given the complexity (a simple lookup tool with 1 parameter), high schema coverage (100%), and presence of an output schema, the description is somewhat complete but has gaps. It covers the basic purpose but lacks usage guidelines and behavioral details (e.g., error handling). The output schema mitigates the need to explain return values, but without annotations, the description should do more to compensate, making it only 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?
The description adds minimal meaning beyond the input schema. It mentions 'CBS dataset' and 'dimension definitions', which contextualizes the 'dataset_id' parameter, but the schema already has 100% coverage with a clear description ('CBS dataset identifier'). Since schema_description_coverage is high (>80%), the baseline is 3, and the description doesn't significantly enhance parameter understanding (e.g., it doesn't explain what a 'dimension' entails in detail).
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 the tool's purpose: 'Get dimension definitions for a CBS dataset.' It specifies the verb ('Get') and resource ('dimension definitions'), and distinguishes it from siblings like 'get_cbs_dataset' (which likely retrieves dataset metadata) or 'query_cbs_data' (which likely queries actual data). However, it doesn't explicitly differentiate from 'get_dataset' or 'search_cbs_datasets', which might also involve dataset-related operations, keeping it from a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a dataset ID from another tool), exclusions, or comparisons to siblings like 'get_cbs_dataset' or 'search_cbs_datasets'. The agent must infer usage from the purpose alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe important behavioral aspects like whether this is a read-only operation, what the output format looks like, whether results are paginated, or if there are rate limits. The description is minimal and lacks operational context.
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 a single, efficient sentence that states the core functionality without any wasted words. It's appropriately sized for a simple listing tool and gets straight to the point.
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?
Given that there's an output schema (which handles return values) and the input schema has full description coverage, the description is minimally adequate. However, for a tool with no annotations and multiple sibling tools that might retrieve similar data, the description should provide more context about when this specific listing approach is appropriate.
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?
The input schema has 100% description coverage, with the single parameter 'include_details' clearly documented in the schema. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline expectation when schema coverage is complete.
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 the verb ('List') and resource ('organizations that publish data on data.overheid.nl'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_organization' or 'lookup_company', which might retrieve similar organizational data through different mechanisms.
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?
The description provides no guidance on when to use this tool versus alternatives like 'get_organization' or 'lookup_company'. It doesn't mention prerequisites, exclusions, or specific contexts where this listing function is preferred over other organizational tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('List all files and resources') but does not describe traits like pagination, rate limits, permissions needed, or what 'all' entails (e.g., recursive listing). This leaves significant gaps for a tool that likely returns multiple items.
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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
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?
Given the tool has an output schema (which likely describes the return structure), the description does not need to explain return values. However, with no annotations and multiple sibling tools, the description is minimal and lacks context about usage and behavior, making it only adequate for a basic listing 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?
The input schema has 100% description coverage, with the parameter 'dataset_id' clearly documented. The description does not add any meaning beyond the schema, such as examples of dataset IDs or how slugs/names are resolved. Baseline 3 is appropriate as the schema handles the parameter documentation adequately.
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 the verb 'List' and the resource 'files and resources in a dataset', making the purpose understandable. However, it does not distinguish this tool from siblings like 'get_dataset' or 'get_resource', which might retrieve specific items rather than list contents, so it lacks sibling differentiation.
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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_dataset' (which might retrieve metadata) and 'get_resource' (which might fetch a single resource), there is no indication of context, prerequisites, or exclusions for using 'list_resources'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool lists tags with optional filtering but fails to disclose key behavioral traits such as pagination, rate limits, authentication needs, or output format. For a list operation without annotations, this leaves significant gaps in understanding how the tool behaves.
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 a single, clear sentence that efficiently conveys the tool's purpose and optional feature. It is front-loaded with the main action and avoids unnecessary details, making it highly concise and well-structured.
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?
Given the tool's low complexity (one optional parameter) and the presence of an output schema, the description is minimally adequate. However, it lacks details on behavioral aspects like pagination or error handling, which are not covered by annotations or the output schema alone, making it only partially complete.
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?
The input schema has 100% description coverage, with the 'query' parameter documented as an optional prefix/substring filter. The description adds minimal value by mentioning 'optionally filtered by a search term,' which aligns with but doesn't expand beyond the schema. This meets the baseline of 3 for high schema coverage.
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 the verb ('List') and resource ('available tags'), and specifies optional filtering. It distinguishes from siblings like 'list_organizations' or 'list_resources' by focusing on tags. However, it doesn't explicitly differentiate from potential tag-related siblings not present in the list, keeping it at 4 rather than 5.
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?
The description provides no guidance on when to use this tool versus alternatives. It mentions optional filtering but doesn't specify scenarios for filtering or not, nor does it reference sibling tools like 'search_datasets' for broader searches. This lack of contextual usage advice results in a low score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe important behavioral aspects like whether this is a read-only operation, what format results are returned in, whether there are rate limits, authentication requirements, or what happens when no results are found.
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 a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a search tool and front-loads the essential information.
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?
Given that an output schema exists (so return values are documented elsewhere) and the input schema has 100% coverage, the description is minimally adequate. However, for a search tool with many similar siblings, it should provide more context about when to choose this specific tool and what makes it unique.
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?
The input schema has 100% description coverage, thoroughly documenting both parameters. The description adds no additional parameter information beyond what's already in the schema, so it meets the baseline of 3 for high schema coverage.
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 the action ('Search') and target resource ('CBS statistical datasets'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'search_datasets' or 'query_cbs_data', which appear to have overlapping functionality.
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?
The description provides no guidance on when to use this tool versus alternatives like 'search_datasets' or 'query_cbs_data'. It mentions the organization (CBS) but doesn't clarify what makes this search different from other search tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It doesn't mention rate limits, authentication requirements, response format, pagination behavior beyond the offset parameter, or whether this is a read-only operation. The description merely states what the tool does without revealing how it behaves.
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 a single, efficient sentence that states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the essential information about what the tool does.
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?
Given the tool has an output schema (which handles return values) and 100% schema coverage for inputs, the description is minimally complete. However, for a search tool with multiple similar siblings and no annotations, it should provide more context about when to use it and what distinguishes it from alternatives.
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?
With 100% schema description coverage, the input schema already documents all four parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. This meets the baseline expectation when schema coverage is high, but doesn't provide extra value.
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 the tool searches Dutch government datasets on a specific platform (data.overheid.nl), providing a specific verb ('search') and resource ('Dutch government datasets'). However, it doesn't distinguish this from sibling tools like 'search_cbs_datasets' or 'get_dataset', which appear to serve similar purposes in the same domain.
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?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'search_cbs_datasets', 'get_dataset', and 'query_cbs_data' that likely overlap in functionality, there's no indication of when this general search tool is preferred over more specific ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'gets' metadata, implying a read operation, but doesn't cover important aspects like authentication requirements, rate limits, error handling, or what 'detailed metadata' includes. This leaves significant gaps for an agent to understand how to use it effectively.
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 extremely concise—a single sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded with the core functionality and wastes no space on redundant information.
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 that there's an output schema (which handles return values) and the input schema has 100% coverage, the description provides adequate context for a simple read operation. However, the lack of behavioral details (like authentication or error handling) and usage guidance relative to siblings prevents a perfect score.
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?
The schema description coverage is 100%, with the single parameter 'dataset_id' fully documented in the schema. The description doesn't add any additional parameter information beyond what's already in the schema, so it meets the baseline expectation without providing extra value.
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 the tool's purpose with a specific verb ('Get') and resource ('detailed metadata for a CBS dataset'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_cbs_dimensions' or 'get_dataset', which might have overlapping functionality.
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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_dataset', 'search_cbs_datasets', and 'query_cbs_data', there's no indication of when this specific CBS dataset metadata tool is preferred or what distinguishes it from similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves metadata but doesn't specify aspects like authentication requirements, rate limits, error handling, or the format of the returned metadata. This leaves significant gaps for an agent to understand how to interact with it effectively.
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 a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose, making it easy to parse and understand quickly.
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's low complexity (one parameter, no nested objects) and the presence of an output schema (which handles return values), the description is reasonably complete for its purpose. However, it lacks behavioral details that would be helpful in the absence of annotations, such as how 'detailed metadata' is structured or any usage caveats.
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?
The input schema has 100% description coverage, with the single parameter 'dataset_id' documented as 'Dataset ID or slug/name.' The description adds no additional meaning beyond this, such as examples or constraints, so it meets the baseline score of 3 where the schema does the heavy lifting.
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 the verb ('Get') and resource ('detailed metadata for a specific dataset'), making the purpose understandable. However, it doesn't distinguish this tool from similar siblings like 'get_cbs_dataset' or 'search_datasets', which likely retrieve dataset information with different scopes or filters.
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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_cbs_dataset' (likely for CBS-specific datasets) and 'search_datasets' (likely for broader searches), there's no indication of context, prerequisites, or exclusions for this tool's usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'List' which implies a read-only operation, but does not cover aspects like pagination, rate limits, authentication needs, or what the output format entails (though an output schema exists). For a tool with zero annotation coverage, this is a significant gap in transparency.
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 a single, efficient sentence that front-loads the purpose with no wasted words. It directly states the action and resource, and the examples are concise and relevant, making it easy to parse quickly.
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?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is minimally adequate. However, with no annotations, it lacks behavioral context like safety or performance traits. The description covers the basic purpose but does not fully address the gap left by missing annotations, making it incomplete for optimal agent use.
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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by specifying the resource as 'CBS statistical themes' and providing examples, which clarifies the tool's scope beyond the schema. Baseline is 4 for zero parameters, as the description compensates with contextual details.
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 the verb 'List' and the resource 'CBS statistical themes', with examples like 'Arbeid, Bevolking, Economie' that clarify the scope. It distinguishes from siblings like 'list_organizations' or 'list_tags' by specifying 'CBS statistical themes', though it doesn't explicitly contrast with similar tools like 'list_cbs_datasets' (not in siblings) or 'get_cbs_dataset'.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context for usage, or comparisons to sibling tools such as 'search_cbs_datasets' or 'get_cbs_dataset', leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the action ('Query') and output ('Returns observation rows'), but lacks details on permissions, rate limits, error handling, or data freshness. For a query tool with no annotation coverage, this leaves significant behavioral gaps.
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 extremely concise and front-loaded: two sentences that directly state the tool's purpose and output. Every word earns its place with zero waste or redundancy.
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's moderate complexity (5 parameters, 1 required), 100% schema coverage, and presence of an output schema, the description is reasonably complete. The output schema means the description doesn't need to explain return values. However, the lack of usage guidelines and behavioral transparency (with no annotations) prevents a perfect score.
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%, so the schema fully documents all 5 parameters. The description adds no parameter-specific information beyond what's in the schema. According to guidelines, with high schema coverage, the baseline is 3 even without param info in the description.
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 the tool's purpose: 'Query statistical data from a CBS dataset. Returns observation rows.' It specifies the verb ('Query'), resource ('statistical data from a CBS dataset'), and output format ('observation rows'). However, it doesn't explicitly differentiate from siblings like 'search_cbs_datasets' or 'get_cbs_dataset', which likely serve different purposes.
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?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools like 'search_cbs_datasets' and 'get_cbs_dataset', there's no indication of when this query tool is appropriate versus those for searching or retrieving dataset metadata. No context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions dataset limitations ('free open dataset') but doesn't cover other critical aspects like read-only vs. mutation, authentication needs, rate limits, error handling, or response format. For a lookup tool with no annotation coverage, this is a significant gap in transparency.
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 and front-loaded, consisting of two sentences that efficiently convey the core purpose and key limitations. Every sentence adds value without redundancy, making it easy for an AI agent to parse quickly.
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?
Given the tool's complexity (a lookup with one parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete behavioral details, it lacks completeness for safe and effective use. It covers scope but misses operational context like permissions or errors.
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?
The schema description coverage is 100%, with the parameter 'kvk_number' fully documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, such as examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 the tool's purpose: 'Look up publicly filed financial statement metadata for a Dutch company.' It specifies the verb ('look up'), resource ('financial statement metadata'), and scope ('Dutch company'). However, it doesn't explicitly differentiate from sibling tools like 'lookup_company', which might handle different company data, leaving room for ambiguity.
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 provides some usage context: 'Only covers BV and NV companies in the free open dataset.' This implies when to use (for those company types in that dataset) but doesn't explicitly state when not to use or name alternatives. For example, it doesn't clarify if 'lookup_company' is for non-financial data, leaving usage guidance incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'Get details' but doesn't specify if this is a read-only operation, what authentication is required, rate limits, error handling, or the format of returned details. For a tool with no annotation coverage, this leaves significant behavioral gaps.
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 a single, efficient sentence that front-loads the core purpose without unnecessary words. It earns its place by clearly stating what the tool does, making it easy to scan and understand quickly.
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 an output schema (which handles return values), 100% schema coverage for parameters, and no complex nested objects, the description is reasonably complete. It covers the basic purpose and resource, but could improve by adding more behavioral context since annotations are absent, especially for a tool that might involve data retrieval nuances.
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%, so the schema already documents both parameters ('organization_id' and 'include_datasets') thoroughly. The description mentions 'details' and implies datasets might be included, but adds no additional meaning beyond what the schema provides, such as examples or edge cases. Baseline 3 is appropriate when schema does the heavy lifting.
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 the verb ('Get details about') and resource ('a specific publishing organization'), making the purpose understandable. It distinguishes from sibling tools like 'list_organizations' by focusing on a single organization rather than listing multiple. However, it doesn't specify what details are included beyond datasets, leaving some ambiguity.
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 details about a specific organization are needed, distinguishing it from 'list_organizations' which retrieves multiple organizations. However, it lacks explicit guidance on when to use this tool versus alternatives like 'lookup_company' or 'search_datasets', and doesn't mention prerequisites such as needing an organization ID.
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?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the dataset limitation (free open dataset only), company type restrictions (BV/NV only), and data truncation (postal codes to 2 digits). However, it doesn't mention error handling, rate limits, authentication needs, or what happens with invalid KVK numbers.
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 perfectly concise with three focused sentences: the core purpose, dataset/type limitations, and data format detail. Every sentence earns its place by providing essential information without redundancy or fluff.
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 an output schema (so return values don't need description), 100% schema coverage, and moderate complexity, the description is reasonably complete. It covers purpose, scope limitations, and data format details. The main gap is lack of behavioral details like error conditions or performance characteristics.
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 a single well-documented parameter, so the baseline is 3. The description adds context about what the KVK number represents ('Chamber of Commerce registry') and that it's 8-digit, but this largely repeats schema information rather than providing significant additional semantic meaning.
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 the specific action ('Look up') and resource ('Dutch company'), distinguishes the scope by specifying 'Only covers BV and NV companies in the free open dataset', and differentiates from siblings like 'lookup_company_finances' by focusing on basic company data rather than financial information.
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 provides clear context for when to use this tool: for Dutch companies with KVK numbers, specifically BV/NV types in the free dataset. It implicitly suggests alternatives for other company types or datasets, but doesn't explicitly name when-not-to-use scenarios or direct alternatives like 'get_organization'.
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:

[![dutch-gov-mcp MCP server](https://glama.ai/mcp/servers/Alishark14/dutch-gov-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Alishark14/dutch-gov-mcp)

Score Badge

Copy to your README.md:

[![dutch-gov-mcp MCP server](https://glama.ai/mcp/servers/Alishark14/dutch-gov-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Alishark14/dutch-gov-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/Alishark14/dutch-gov-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server