MCP server for querying legal documents from official sources for AI assistants
Law7 is a STDIO-only legal document query server with 13 tools. Tool naming follows verb-noun convention and is clear (query-laws, get-law, search-regional-law, etc.). However, parameter and tool descriptions lack depth and context. Most tools have minimal descriptions (10-30 chars) that fail to explain WHEN to use the tool or HOW it differs from similar tools. No output schemas are documented in the visible code. Error handling is absent, no recovery guidance, classification, or actionable error messages shown. The server lacks tool annotations (readOnlyHint/destructiveHint). While tool definitions are explicitly visible in the tool files, the descriptions are insufficient for LLM reasoning. Average description length appears to be ~20-35 chars, below the 194-char baseline for A+ tools.
Fetch and ingest legal documents on-demand from official sources
Get a specific version of a legal code article
Get the hierarchical structure of a legal code
Get the full text and metadata of a specific legal document
Get a specific regional KOAP (Code of Administrative Procedure) article
Get statistics about the legal documents database
Get a specific Supreme Court resolution
List all available countries in the legal documents database
Tool descriptions are uniformly terse (10-35 characters). They lack context about WHEN to use each tool, how similar tools differ, and what the output structure is. For example, 'Query legal documents from the database using semantic search' is present but omits: (a) what constitutes a good query, (b) why use this vs search-regional-law, (c) expected result fields and count. This violates the 194-char baseline for production tools and prevents LLMs from reasoning about tool selection.
Output schemas are not documented. The visible code shows input parameter schemas (query, limit, country for query-laws) but nowhere in the codebase excerpt is there a definition of what fields these tools return, their types, or pagination structure. Without output schemas, LLMs cannot extract the right data or chain tools together. E.g., after calling search-court-decisions, what field contains the decision text? The decision ID? The court name? This forces agents to guess or make trial calls.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Query legal documents from the database using semantic search
Search for court decisions and resolutions
Search for legal interpretations and commentaries
Search for regional legal documents
Trace the amendment history of a legal article
No error handling guidance visible in tool descriptions or implementation samples. Tools like fetch-and-ingest (which is destructive/mutating) and search tools do not describe what errors are retryable, what is user-fixable, or what recovery steps to take. For example, if query-laws returns zero results, should the agent try a simpler query, expand the country filter, or inform the user that no laws match? Without error classification, agents cannot plan recovery.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are absent. fetch-and-ingest is a WRITE operation (mutates the database by ingesting documents), but it is not marked with destructiveHint. This leaves agents unaware that calling it twice with the same document_url might ingest the same content twice or fail. search tools are read-only but lack readOnlyHint. Without annotations, agents cannot reason about side effects.
Parameter descriptions are minimal. For example, query-laws has parameters 'query', 'limit', and 'country', but descriptions do not specify: (a) what constitutes a valid query (keywords only? phrases? boolean operators?), (b) what is the range for 'limit' (1 - 100? 1 - 1000?), (c) what format is 'country' (2-letter ISO code like 'ru'? Full name like 'Russia'?). This forces LLMs to guess and make invalid requests.
Tool composition risk: Similar tools exist (e.g., query-laws vs search-regional-law vs search-court-decisions) but distinctions are unclear from short descriptions. When should an agent call query-laws vs search-regional-law? The descriptions do not explain scope, content type, or data source. This creates ambiguity and forces LLMs to reason inefficiently or make wrong choices.