Loading ToolBench
Production-grade Slovenian legal research MCP server with comprehensive statute coverage and EU law cross-references
This server has 14 tools with complete schemas and descriptions, but several design issues limit its effectiveness. All tools are READ_ONLY search/retrieval operations with proper typing, which is a strength. However, descriptions are generic (averaging ~100 chars, below the 194-char baseline), many lack context about when to use them vs similar tools, and output schemas are not documented. Tool naming is clear and verb-based, but parameter descriptions are minimal. The server implements a coherent domain (Slovenian law research) with good coverage of legal document types, but the tool interface could better guide LLM selection and composition.
Retrieve a specific case law entry by its document ID
Get all cross-references to/from a legal document
Get EU document cross-references for a Slovenian legal provision
Retrieve a specific EU document by ID
Retrieve a legal document by ID with all its provisions and metadata
Retrieve details of a specific preparatory work entry
Get a specific legal provision by document ID and provision reference
List all legal documents with optional filtering by type or status
Descriptions are generic and lack domain context. 'Search legal provisions by full-text content or metadata' does not explain when to use this tool vs search_case_law or search_definitions, or what constitutes a 'legal provision'. LLMs need explicit guidance to select the correct tool from 14 similar search/get operations.
Output schemas are not documented. The server provides input schemas but does not specify what fields each tool returns. LLMs cannot plan multi-step calls (e.g., does search_legal_provisions return document_id? Does get_legal_document return provision references for chaining to get_provision?). This forces agents to infer structure or make blind calls.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Search case law entries by summary, keywords, court, or full-text
Search legal definitions by term or definition content
Search EU legal documents (directives, regulations, decisions)
Search legal provisions by full-text content or metadata
Search preparatory works (legislative history) for statutes
Validate and parse a Slovenian legal citation
Parameter descriptions are minimal. 'Filter by document ID (optional)' appears in search_legal_provisions and search_definitions but does not explain: Is document_id a statute ID, case ID, or EU directive ID? How do LLMs know which document_id value to pass after a search? This ambiguity forces extra discovery calls.
Similar tools lack disambiguation. 'get_legal_document', 'get_case_law', 'get_eu_document', and 'get_preparatory_work' all follow the same get_* pattern with document_id. Their descriptions do not explain why an LLM should pick one over another or what data types they operate on (statute vs case decision vs directive). This violates the name-clarity pattern and invites misuse.
No error guidance. The schema lists risk='READ_ONLY' but provides no recovery instructions. If a user passes an invalid provision_ref to get_provision, or a non-existent case ID to get_case_law, what error does the LLM receive? How does it recover? The absence of documented error handling violates the recovery-guide pattern.
'limit' parameter lacks constraints. Multiple tools accept a 'limit' parameter with default 20 but no documented max. Can an LLM pass limit=10000 and fetch all results? This violates the enforce-result-limits pattern and risks context window exhaustion.
No pagination metadata. search_* tools return 'limit' but no indication of total_count, has_more, or next_cursor. An LLM cannot tell if it retrieved all matching statutes or only the first 20. This forces blind pagination attempts and prevents exhaustive searches.