MCP server for searching Swiss case law using Entscheidsuche API
The Entscheidsuche MCP server provides two search/retrieval tools for Swiss case law. Both tools have basic descriptions and parameter definitions, but several critical issues reduce quality: (1) Tool descriptions are present but minimal (119-121 chars), failing to explain WHEN to use each tool or how they differ; (2) Parameter descriptions are generic and lack actionable constraints (e.g., 'size' has no clear upper bound guidance, 'format' enum is present but not explained in the parameter description); (3) No output schema is documented, forcing LLMs to infer structure; (4) Error handling is silent (try-catch blocks log nothing to the LLM); (5) Parameters lack format/range guidance beyond basic types. The tools are READ_ONLY and functional, but fall short of production-grade documentation expected for confident agent use.
Retrieve the full content of a specific legal document
Search for Swiss court decisions using Entscheidsuche database
Tool descriptions are too short and lack WHEN/WHY guidance. 'Search for Swiss court decisions using Entscheidsuche database' (119 chars) does not explain when to use this tool instead of get_document, what output structure to expect, or common failure modes.
No documented output schema. The search_case_law tool returns a formatted JSON array with fields like 'signature', 'court', 'date', 'title_de', etc., but none of this is visible in a schema contract. LLMs must infer structure from the text response.
Parameter 'size' lacks clear constraint guidance. Described as 'Number of results to return (max 50)', but this limit is not enforced at the parameter schema level (no maximum constraint in zod schema visible). Code has Math.min(size, 50) but LLMs cannot see that in the parameter definition.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 40 | - | v1 |
'format' parameter enum is declared in schema but the parameter description does not explain what each format contains or when to use each. 'Document format to retrieve' is vague; should be 'json: returns structured metadata; html: returns rendered document; pdf: returns binary PDF'.
Error handling is silent to the LLM. When API calls fail (e.g., 'Document not found: 404'), the catch block returns `{content: [{type: 'text', text: 'Error message'}]}` with no guidance on recovery. Should indicate: is it retryable? Should the user search first? Did you use the wrong format?
No guidance on parameter relationships. The 'spider' parameter in get_document is optional ('If not provided, will be extracted from signature'), but the description does not explain the extraction logic or failure modes. What if signature format is invalid?
Result limiting is enforced in code but not declared in tool description. search_case_law caps at 50 results, but the description does not state 'Showing up to 50 results per call; use pagination (from parameter) to access more.' This forces agents to discover pagination through trial.