Skip to main content
Glama
matematicsolutions

mcp-fr-legal

by matematicsolutions
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

mcp-fr-legal

An MCP server exposing an offline corpus of French law (Legifrance / DILA, full text) in a local SQLite FTS5 database, with tools for search and citation grounding. Snippets are returned verbatim from the database (zero-LLM), each with a document_id, a provision_ref and a Legifrance URL. Anti-hallucination by mechanism, not by trust in the model.

Scope: consolidated LEGI codes and statutes (Code civil, Code du travail, Code penal, Code de commerce, Code de la defense, Code de la securite interieure, ...) - 3,953 documents / 193,681 provisions in the bundled snapshot. No case law (jurisprudence) and no full JORF.

Part of the MateMatic law-connector family: mcp-saos (PL case law), mcp-eu-compliance (EU law), mcp-eu-sparql (live EUR-Lex).

Installation

npm install            # Node 22.5+ (node:sqlite built in, FTS5)
npm run fetch-corpus   # downloads database.db (~303 MB) from the DILA/Ansvar artifact (Apache-2.0 + Etalab)
npm run build
npm start

Air-gapped / fully offline: point FR_LEGAL_DB at a local copy of database.db.

MCP client configuration:

{ "name": "fr-legal", "command": "node", "args": ["/path/to/mcp-fr-legal/dist/index.js"] }

Related MCP server: MCP Magistrat Civil

Tools

Tool

Description

fr_search(query, documents?, limit?)

Full-text (FTS5) over provisions, verbatim snippets + citations.

fr_article(document_id, provision_ref)

Full verbatim text of a provision (tolerant provision_ref).

fr_validate_citation(document_id, provision_ref)

Grounding: whether the citation exists (fail-closed) - anti-hallucination.

fr_list_documents(type?, query?)

List documents (discovery of document_id).

Every tool returns structuredContent.citations (document_id, provision_ref, Legifrance URL, source_authority DILA, license Etalab v2.0, snapshot, age_days, and a staleness_advisory when the snapshot is older than the FR_STALENESS_DAYS threshold (365 by default) - provenance and staleness modelled on russellbrenner/jurisd, Apache-2.0).

Grounding (anti-hallucination)

fr_validate_citation is a grounding primitive: it mechanically checks whether document_id + provision_ref exists in the corpus. Fail-closed - a missing document or provision yields provision_exists=false (not "probably ok"). It plugs into citation-grounding-pl as the anchor resolver for French law (EXISTENCE level).

Zero-cloud / GDPR

No network calls at runtime (the database is opened read-only). Corpus bootstrap (fetch-corpus) is the only moment a network is used. Text is returned verbatim (grounding). For currency, check Legifrance (a snapshot is not the authoritative source - the Journal officiel is).

License and attribution

Citation: MateMatic Solutions (2026), mcp-fr-legal - an offline MCP corpus of French law (Legifrance/DILA), MIT. Data: DILA, Licence Ouverte v2.0.

Available Tools

4 tools
fr_articleA
Read-onlyIdempotent

Pelny verbatim tekst przepisu (document_id + provision_ref, np. 'code-travail' + 'L1233-15'). provision_ref tolerancyjny ('Article L. 1233-15' == 'L1233-15'). Kody bledow: missing_arg, not_found, corpus_error.

ParametersJSON Schema
NameRequiredDescriptionDefault
document_idYesID dokumentu (np. 'code-civil', 'code-travail')
provision_refYesOdwolanie do przepisu (np. 'L1233-15', '1234', 'R123-4')

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds behavioral context beyond annotations, such as tolerance in provision_ref format (e.g., 'Article L. 1233-15' equals 'L1233-15') and error codes (missing_arg, not_found, corpus_error). No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loading the main purpose and including error codes efficiently. However, it is in Polish which may reduce clarity for non-Polish agents; still, it earns its space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description states it returns the full verbatim text. It mentions error codes, which is helpful. Annotations cover safety. Additional details about return format or encoding are missing, but overall it is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already describes parameters. The description adds value by providing an example and explaining the tolerance behavior of provision_ref, which is not present in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the full verbatim text of a legal provision using document_id and provision_ref, with an example. This distinguishes it from sibling tools like fr_search (search) and fr_list_documents (list).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives (fr_search, fr_list_documents, fr_validate_citation). The description implies usage for retrieving a specific article but does not explicitly state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fr_list_documentsA
Read-onlyIdempotent

Lista dostepnych dokumentow (kody/ustawy) - discovery document_id. Opcjonalnie filtr type (np. 'statute') i query (fraza w tytule). Kody bledow: corpus_error.

ParametersJSON Schema
NameRequiredDescriptionDefault
typeNoFiltr typu dokumentu (np. 'statute')
limitNoLiczba wynikow (1-200, domyslnie 30)
queryNoFraza w tytule/nazwie

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds error code 'corpus_error' and clarifies the tool's discovery purpose, providing useful context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with an additional error code note, front-loading the purpose and avoiding any extraneous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool, the description covers the core functionality and optional filters. It omits mention of pagination or the limit parameter, but these are well-defined in the schema, so the description is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Parameter descriptions in the schema already cover type, limit, and query with examples and ranges. The description adds no new semantic meaning beyond what the schema provides, meeting the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists available documents (codes/laws) for discovering document IDs, distinguishing it from sibling tools like fr_article (retrieve specific article) and fr_search (full-text search).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing documents to find IDs, but does not explicitly state when not to use it or mention alternatives, leaving the agent to infer from sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fr_validate_citationA
Read-onlyIdempotent

Grounding: czy cytat (document_id + provision_ref) ISTNIEJE w korpusie (anti-halucynacja). Fail-closed: brak dokumentu/przepisu => provision_exists=false. Zwraca document_exists, provision_exists, in_force + citation. Kody bledow: missing_arg, corpus_error.

ParametersJSON Schema
NameRequiredDescriptionDefault
document_idYesID dokumentu
provision_refYesOdwolanie do przepisu do weryfikacji

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds significant context: it explains the fail-closed mechanism, lists all return fields (document_exists, provision_exists, in_force, citation), and mentions error codes ('missing_arg', 'corpus_error'). This goes beyond annotations to inform the agent about expected outputs and failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact with three sentences: purpose, fail-closed behavior, and return fields/errors. Each sentence conveys distinct information with no redundancy. The use of Polish with some English terms is slightly informal but still efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 required params, no output schema), the description covers the essential aspects: what it does, its behavior on failure, and what it returns (including error codes). It does not explain the sibling tools but that is partially covered by their names. The absence of output schema is compensated by the explicit listing of return fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Both parameters (document_id, provision_ref) are fully described in the input schema (100% coverage). The description's mention of them adds no new semantic details; it only restates their role in the citation check. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: grounding citations by checking if a document_id and provision_ref exist in the corpus, explicitly calling it anti-hallucination. This distinguishes it from siblings like fr_search or fr_article, which have different primary functions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides fail-closed behavior (if document or provision missing, provision_exists=false) but does not explicitly guide when to use this tool versus alternatives like fr_search or fr_article. The use case of citation validation is implied but not contrasted with siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0
Disambiguation5/5

Each tool has a distinct purpose: retrieving a specific article, listing available documents, full-text search, and citation validation. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent pattern with 'fr_' prefix and snake_case verbs/nouns (article, list_documents, search, validate_citation).

Tool Count5/5

Four tools is well-scoped for a legal research server, covering essential operations without unnecessary complexity.

Completeness5/5

The set covers retrieval, listing, search, and validation—core operations for legal reference. No obvious missing functionality given the domain.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/matematicsolutions/mcp-fr-legal'

If you have feedback or need assistance with the MCP directory API, please join our Discord server