Loading ToolBench
ICO Database Query REST API Service - provides REST API endpoints for querying ICO (Information Commissioner's Office) Register of Data Controllers data
This MCP server exposes 7 tools for querying UK ICO (Information Commissioner's Office) registration data. The tools have acceptable descriptions and parameter schemas, but significant gaps prevent a higher score. All tools are READ_ONLY (search/lookup operations). Parameter schemas are present and typed for most tools, but descriptions are inconsistent in detail and some parameter descriptions are minimal. The server lacks structured output documentation, error handling guidance, and idempotency markers. Schema documentation is inferred from code rather than explicitly exposed in MCP metadata. Tools follow a reasonable naming convention (verb_noun pattern) but descriptions vary widely in informativeness. No tool combines multiple concerns, and composition is straightforward. However, the lack of explicit error handling patterns, output schema documentation, and LLM-friendly guidance around pagination and result limits pulls the score into the fair/poor range typical of community servers.
Get all historical data versions that have been imported
Get the current data version information including the active dataset version and total record count
Get a specific ICO registration by its registration number
Get all registrations for a specific organisation name
Get all registrations for a specific postcode
Health check endpoint that returns server status and current timestamp
Search ICO registrations with query parameters including organisation name, registration number, postcode, public authority, payment tier, with pagination support
Missing output schema documentation. The rubric requires documented return types for all tools (100% baseline for A+ servers). Tool definitions show parameter schemas but no explicit documentation of what fields are returned or their structure. This forces LLMs to infer output format from sparse descriptions.
No explicit error handling guidance. Tools lack recovery hints or error categorization. For instance, if a search returns no results or an invalid registration number is provided, there is no documented guidance on what the LLM should do next (retry, refine query, ask user). This violates the recovery-guide pattern.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Inconsistent parameter naming and typing. Tools like getRegistrationByNumber, getRegistrationsByOrganisation, and getRegistrationsByPostcode accept different parameter types (registrationNumber vs name vs postcode) with varying descriptions. When multiple tools operate on the same resource (ICO registration), parameter names should align (e.g., all accept 'registrationNumber' or offer both 'registrationNumber' and 'registrationName'). This creates ambiguity for LLMs.
Pagination parameters present in some tools but not others. The 'search' tool includes 'limit' and 'offset' for pagination, but getRegistrationsByOrganisation and getRegistrationsByPostcode only offer 'limit' with no offset/cursor support. This inconsistency forces LLMs to reason differently about how to paginate across tools. Per the paginated-result pattern, all tools returning lists should support consistent pagination.
Parameter descriptions lack detail on constraints and format. For example, the 'postcode' parameter in search and getRegistrationsByPostcode has a bare description 'Postcode to search for' with no guidance on expected format (full postcode, partial, UK-specific format validation). Similarly, 'paymentTier' has no enum values documented. The rubric requires '2-10 uppercase letters' style specificity to prevent invalid LLM input.
No documented limit enforcement or result capping. The 'search' tool has a default limit of 10 but no stated maximum. If an LLM passes limit=10000, it is unclear whether the server enforces a cap or returns an error. Per the rubric baseline, tools should cap results at 20-50 and state this in the description to prevent context window exhaustion.
No tool annotations (readOnlyHint, idempotentHint). The MCP spec (2026-07-28) supports tool annotations to signal properties like read-only and idempotent operations. All 7 tools here are marked Risk: READ_ONLY in the rubric provided, but this is not present in any visible MCP tool definition. Adding toolAnnotations would make these properties discoverable by clients.