Loading ToolBench
Search French and European case law: all French courts plus CNDA, Conseil constitutionnel, CNIL sanctions, CEDH and CJUE. The engine understands meaning, not just keywords.
LibreJustice MCP Server demonstrates solid definition quality with well-structured tool definitions, comprehensive parameter schemas, and clear descriptions. All 5 tools have properly typed input schemas with detailed descriptions. Tool names follow verb-noun convention (search_, get_, list_) appropriately. However, output schemas are not explicitly documented in the source code provided, and some parameter descriptions could be more LLM-optimized. Error handling patterns and recovery guidance are not evident from the static analysis. The French legal domain context creates specialized but clear naming that avoids ambiguity.
Get Decision. Retrieves the full text and metadata of a specific court decision by its public ID.
Get Legal Text. Retrieves the full text of a specific legal statute or code article by its ID.
List My Activity. Returns the activity log of the authenticated user: recent searches, bookmarks, and reading history.
Search Decisions. Searches French and European case law with semantic understanding. Returns a shortlist of matching decisions with metadata and facets for filtering.
Search Legal Texts. Searches French legal codes and statutes with semantic understanding. Returns matching articles and their sources.
Output schemas not documented in visible source code. While input schemas are comprehensive and properly typed, there is no evidence of documented return types for any tool. LLMs cannot plan downstream tool calls or extract the right data without knowing what fields and structure to expect.
Error handling and recovery guidance not evident. No documentation of how tools handle failures (e.g., no results found, invalid parameters, rate limits), what error codes are returned, or what the LLM should do next (retry, ask user, suggest alternatives). Agents cannot self-correct without this guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2025-06-18+ | v2 |
search_decisions uses free-form string arrays for complex filters (solution, procedure, office, publication, legal_domain) that could be constrained enums. While descriptions explain the valid values, explicitly defining enums would prevent hallucinated values and be self-documenting.
Parameter descriptions in search_decisions lack guidance on common workflows. E.g., 'jurisdiction_type' description lists all court types but doesn't help an LLM choose between TJ vs CA vs CC for a user's intent. Add dependency hints like 'To find appellate decisions, filter by CA (cour d'appel) or CC (Cour de cassation)'.
list_my_activity description is minimal (50 chars) and doesn't explain when to call this vs search_decisions, what 'activity_kind' implies, or whether it requires authentication. Descriptions should guide tool selection.
No documented pagination or result limiting strategy. search_decisions could return thousands of matching decisions; search_legal_texts similarly unbounded. Without explicit limits and pagination parameters (e.g., page, limit, total_count), context windows can be exhausted and agent reasoning degrades.