Loading ToolBench
An MCP server that provides access to Central Bureau for Statistics (CBS) Dutch open data through tools for querying catalogs, datasets, dimensions, and observations
This server defines 7 tools for querying CBS (Dutch Central Bureau of Statistics) open data. All tools have names starting with action verbs (get_, query_) and descriptions present. However, there are significant gaps in schema completeness, parameter descriptions are minimal, and output schemas are not documented. The tools appear to be READ_ONLY operations against a public data API, which is positive for safety, but the definitions lack the rigor expected for production agent use. Parameter types are declared in the input schemas provided, but descriptions are extremely terse (10-20 chars), often just restating the parameter name without explaining constraints, expected formats, or discovery guidance. No output schema documentation visible. Error handling patterns not evident from the definitions.
Retrieve all available CBS data catalogs
Retrieve all available values for a specific dimension in a CBS dataset
Retrieve all dimensions for a specific CBS dataset
Retrieve detailed metadata for a specific CBS dataset including dimensions, attributes, and schema information
Retrieve observations from a specific CBS dataset with optional filters
Query CBS datasets with optional filters and pagination
Query observations from a CBS dataset with advanced filtering and aggregation
Parameter descriptions are universally minimal (10-25 chars), often just repeating the parameter name. For example, 'catalog' param is described as 'The catalog identifier' with no explanation of what a catalog is, how to discover valid catalogs, or what format to use. LLMs cannot make good decisions with these terse descriptions.
No output/return schema documented for any tool. LLMs need to know what fields to expect in responses (e.g., does get_catalogs return catalog_id, name, description, count? Is it paginated?). Without documented output schemas, agents cannot plan downstream tool calls or extract data reliably.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
Tool descriptions are adequate for discovery (e.g., 'Retrieve observations from a specific CBS dataset with optional filters') but lack guidance on WHEN to use each tool vs. similar ones. For example, get_observations vs query_observations differs subtly, get_observations takes 'filters' (object) while query_observations takes 'filters' (object) + 'groupBy' (array) + 'aggregation' (string). The description should clarify: use get_observations for raw data, query_observations for aggregated results.
No validation or constraint hints in parameter descriptions. For example, 'limit' parameter in multiple tools lacks min/max guidance. What is the valid range? Is 0 allowed? What happens if limit is omitted? Are results paginated? Unbounded numeric parameters invite absurd values from LLMs.
The 'filters' and 'aggregation' parameters in query_observations are weakly specified. 'Filters as key-value pairs for dimensions' does not explain: Are keys dimension IDs? Are values dimension values? What format are values (string, number, array)? What if a filter references a non-existent dimension? Undocumented parameter relationships force LLMs to guess.
No error handling patterns visible in tool definitions. If a catalog, dataset, or dimension does not exist, what error is returned? Is it a 404 with a plain message, or a structured error with alternatives? Error guidance is missing, forcing LLMs to retry blindly.