MCP server for the Swiss Parliament (Curia Vista OData API)
parlament-mcp demonstrates solid tool design with consistent naming (verb_noun pattern), comprehensive parameter schemas, and clear descriptions. All 10 tools follow action-verb conventions (search_, get_, list_). Descriptions average ~120 chars, meeting the 10-1024 char baseline. Input schemas are well-structured with type definitions and parameter descriptions. However, output schemas are not explicitly documented in the source, and error handling lacks recovery guidance. Tool composition is clean (single responsibility), and pagination is properly implemented (limit/offset). Security is sound: read-only operations, no credential exposure. Missing: tool annotations (readOnlyHint), structured output documentation, and error classification patterns.
Get detailed information about a specific parliamentary business by ID
Get detailed information about a specific parliament member
Get full debate transcript for a specific session
Get detailed voting results for a specific vote
List members of the Swiss Parliament (National Council or States Council)
List parliamentary sessions
List votes in the Swiss Parliament
Search for parliamentary business (motions, postulates, interpellations, questions) in the Swiss Parliament
Output schemas not documented in source code. Tool descriptions state what is returned (e.g., 'Get detailed information') but do not specify the response structure, field names, or types. LLMs cannot plan downstream tool calls without knowing what fields to extract.
Error handling lacks recovery guidance. No tool description explains what to do if a search returns no results, an ID is invalid, or the API is unreachable. Errors should guide the LLM to alternative actions (e.g., 'Try a broader search term' or 'Check the business_id format').
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | <=2025-11-25 | v2 |
Search parliamentary debate transcripts (Amtliches Bulletin)
Check the status and reachability of the Curia Vista API
Tool annotations missing. No tools declare readOnlyHint=true, even though all 10 are read-only operations. Tool annotations enable clients to optimize caching, logging, and permission checks. Current spec (2026-07-28) supports this.
Parameter descriptions for filter/search fields lack constraint documentation. E.g., 'business_type' accepts 'Motion, Postulat, Interpellation, etc.' but the description does not enumerate valid values or state the format. Enums should be explicit.
source_status tool has minimal description ('Check the status and reachability of the Curia Vista API') and no parameters documented. Unclear when an LLM should call this vs. handling errors from other tools. Should explain: call this first to diagnose connectivity, or call after a failure to confirm the API is down.