MCP server for opendata.swiss (CKAN) by Schwaizer
This is a CKAN client wrapper with 25 read-only tools. Strengths: all tools have clear descriptions (50-150 chars), complete input schemas with proper types and property descriptions, and consistent naming following verb_noun pattern (package_search, organization_show, etc.). All parameters are typed and described. Weaknesses: (1) Tool descriptions are generic and don't explain WHEN to use each tool or differentiate overlapping operations (e.g., package_list vs current_package_list_with_resources vs package_autocomplete all fetch packages but descriptions don't clarify which is best when); (2) No output schemas documented, responses from CKAN API are not shaped or constrained, forcing LLMs to guess result structure; (3) No error handling guidance, tools just wrap API responses without telling agents how to recover from 404s, timeouts, or malformed data; (4) Parameter descriptions sometimes reference internal CKAN terminology ('CKAN fq', 'CKAN facet.field') without explaining what these mean to non-CKAN users; (5) All tools are read-only (no destructive operations), which reduces risk but also means no confirmation patterns are needed; (6) No tool annotations (readOnlyHint, etc.) present to signal safety to agents. The server is functionally correct and would work, but descriptions are more reference-manual than LLM-optimized.
List datasets with embedded resources (CKAN current_package_list_with_resources).
Get datastore info for a resource (CKAN datastore_info).
Search rows in CKAN datastore (CKAN datastore_search). Supports q, filters, fields, sort, pagination.
Execute SQL against CKAN datastore (CKAN datastore_search_sql). Disabled by default by server config.
List groups (CKAN group_list)
Get group by id or name (CKAN group_show)
Show CKAN help for a given action (CKAN help_show)
No documented output schemas. Tools wrap raw CKAN API responses without documenting what fields agents should expect. LLMs cannot infer result structure and cannot plan downstream calls confidently.
Descriptions lack disambiguation. Multiple tools fetch packages (package_list, package_search, current_package_list_with_resources, package_autocomplete) but descriptions don't explain when to use each. Agents will pick randomly and waste context.
No error recovery guidance. Tools don't explain what to do when CKAN returns 404 (resource not found), 429 (rate limited), timeout, or invalid filter syntax. Agents have no recovery path.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
List known licenses (CKAN license_list)
List organizations (CKAN organization_list)
Get organization by id or name (CKAN organization_show)
Activity stream for a dataset (CKAN package_activity_list).
Autocomplete dataset names (CKAN package_autocomplete).
List dataset ids (CKAN package_list).
Search datasets on opendata.swiss (CKAN package_search). Supports q, fq, sorting, pagination and facets.
Get a dataset (package) by id or name (CKAN package_show).
Global activity feed for recently changed datasets (CKAN recently_changed_packages_activity_list).
Get resource by id (CKAN resource_show).
List views for a resource (CKAN resource_view_list).
Get resource view by id (CKAN resource_view_show).
Platform status (CKAN status_show)
Autocomplete tags (CKAN tag_autocomplete)
List tags (CKAN tag_list)
Show details for a tag (CKAN tag_show)
List vocabularies (CKAN vocabulary_list)
Show a vocabulary and its tags (CKAN vocabulary_show)
CKAN jargon in descriptions ('CKAN fq', 'CKAN facet.field', 'CKAN facet.limit') not explained for non-CKAN users. An agent without CKAN knowledge cannot infer what 'fq' means or how to construct it.
No tool annotations. Tools lack readOnlyHint (all are read-only), idempotentHint (many are), or destructiveHint (none). Agents cannot safely reason about retry safety without annotations.
Parameter descriptions reference CKAN field names without examples. 'facetField: Facet fields to aggregate (CKAN facet.field), e.g. ["tags","keywords"]', but what if user wants to facet by organization? Enum list would help.