Loading ToolBench
Open data from Spain Government API integration with MCP (Model Context Protocol)
The server defines 3 tools with basic schemas and descriptions, but falls short of production quality in several critical dimensions. All tools have descriptions (not zero), but they are generic and lack the detail needed for LLM decision-making. Parameter descriptions exist but are minimal. Output schemas are not documented, the tools return plain strings via format_* helper functions, making it impossible for an LLM to understand what fields it will receive or how to extract data for chaining. Error handling is present but not recovery-focused (e.g., 'No dataset data could be obtained' gives no guidance on what to do next). Input parameters lack constraints (e.g., limit has no min/max bounds, keyword has no length or format hints). The tool names are clear and action-oriented (list_, search_, get_), which is a strength, but composition is limited, there is no pagination support despite returning lists, no batch operations, and no way to retrieve related metadata in a single call. Security is reasonable (no credentials in params, proper timeout handling), but the server lacks permission gates and audit logging. The code quality is solid (proper error handling in make_sparql_request, JSON decode fallbacks), but the MCP interface itself is underdeveloped.
Get detailed information about a specific dataset.
List datasets available in the Spanish Government Open Data Portal.
Search datasets by keyword in title, description, and keywords/tags.
No documented output schemas. All tools return plain strings (formatted via format_dataset_results, etc.). LLMs cannot infer what fields are present, what data types they have, or how to extract specific values for downstream tool calls or user presentation.
Parameters lack constraints and format guidance. 'limit' has no min/max bounds (could accept 0 or 1,000,000); 'keyword' has no length limit or character restrictions; 'dataset_uri' has no format hint (e.g., must match URI pattern). Descriptions do not state ranges or allowed formats, forcing LLMs to guess.
No pagination support. Tools accept 'limit' but return unstructured strings with no offset/cursor, total count, or next_page indicator. When results exceed limit, the agent has no way to fetch more items, cannot iterate through datasets.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 22 | - | v1 |
Error messages are generic and offer no recovery guidance. Example: 'No dataset data could be obtained' does not tell the LLM whether this is a timeout, invalid keyword, or SPARQL endpoint issue. Violates recovery-guide pattern, errors must be actionable.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). While all three tools are read-only and safe to retry, this is not declared in the schema, forcing LLMs to reason about it or guess.
Descriptions are too brief and lack context for tool selection. 'List datasets available in the Spanish Government Open Data Portal' (86 chars) does not explain when to use list_datasets vs search_datasets, what the output contains, or whether there are any prerequisites. Baseline: A+ tools average 194 chars and include 'when' and 'what next' guidance.