Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@fr-eli-mcp Search CODE for Article L. 1234-5"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Published on PyPI + MCP Registry (io.github.matematicsolutions/fr-eli-mcp). Run without cloning:
uvx fr-eli-mcpRequires PISTE credentials in env: PISTE_CLIENT_ID, PISTE_CLIENT_SECRET (Legifrance/PISTE).
Configure your MCP client (stdio):
{ "mcpServers": { "fr-eli-mcp": { "command": "uvx", "args": ["fr-eli-mcp"] } } }Smart App Control blocks unsigned executables, which covers uvx.exe, pip.exe
and the fr-eli-mcp.exe launcher that pip writes at install time. The python.exe and
py.exe from the python.org installer are signed by the Python Software
Foundation, so running the module through the interpreter works:
python -m pip install fr-eli-mcp
python -m fr_eli_mcppip.exe is blocked for the same reason, so install with python -m pip, not
pip install. If python is not on PATH, use the Windows launcher: py -3 -m fr_eli_mcp.
{ "mcpServers": { "fr-eli-mcp": { "command": "python", "args": ["-m", "fr_eli_mcp"] } } }Do not turn Smart App Control off to work around this - it cannot be re-enabled without reinstalling Windows.
Building from source: see Install.
An MCP server for the French Legifrance API via PISTE. It searches French legislation (LODA laws & decrees, codes), case law from three jurisdictions - Cour de cassation / cours d'appel (JURI), the Conseil constitutionnel (CONSTIT - QPC/DC decisions) and the administrative courts (CETAT - Conseil d'Etat, cours administratives d'appel, tribunaux administratifs) - plus CNIL deliberations (CNIL), collective labour agreements (KALI) and company-level agreements (ACCO), and returns verbatim text with verifiable citations. Part of the eu-legal-mcp line of national legal connectors by MateMatic.
Every response carries the citation contract: a stable eli_uri, a human_readable_citation
(French convention) and a resolvable source_url.
Read-only. The server only queries Legifrance and writes a local audit log. It never modifies official text and never sends anything beyond your query / document id.
Related MCP server: mpc-legifrance
Tool | What it does |
| Keyword search a |
| Consult a LODA law/decree by |
| Verbatim text of a single article by |
| A court decision by |
| A CNIL deliberation by |
| A collective labour agreement text by |
| A company-level agreement by |
| Declare what this connector covers, when each family was captured, and - explicitly - what it does NOT cover. Every gap carries a fallback. |
Fond | Corpus | Verified total |
| CNIL deliberations | >= 26 759 ( |
| Collective labour agreements (conventions collectives) | >= 35 790 |
| Company-level agreements | >= 387 656 |
Fond | Court(s) | Id prefix | Native ECLI |
| Cour de cassation, cours d'appel |
| Yes |
| Conseil constitutionnel (QPC + DC decisions, ~7 400+ live on PISTE) |
| Yes ( |
| Conseil d'Etat, cours administratives d'appel (CAA), tribunaux administratifs (TA) |
| Yes for Conseil d'Etat; frequently |
Conseil constitutionnel decisions get the French citation convention: Cons. const., decision n° 2025-1173 QPC du 7 novembre 2025 - [case name]. JURI/CETAT decisions cite the Legifrance titre
(court, formation, date, dossier number) verbatim.
Judilibre (
api.piste.gouv.fr/cassation/judilibre) was evaluated as an alternative Cour de cassation source but requires its own PISTE API subscription beyond the Legifrance one already held by this connector. Re-verified 2026-07-08: a valid Legifrance token (granted scopeopenid resource.READ) gets403on the sandbox host for every endpoint and auth shape tried (Bearer,KeyId, no-auth ->400), and the sandbox application is rejected outright by the production OAuth endpoint (invalid_client). Subscribing the Judilibre API to the PISTE application is a dashboard action outside this connector. Not integrated -JURIalready covers Cour de cassation case law through the existing Legifrance subscription.
France has an official ELI scheme, but the PISTE lf-engine-app consult API returns the native
ELI field null for the legislation we tested. Following this line's rule - say what you do not
have, never fabricate an ELI - eli_uri carries the stable, resolvable Legifrance resource URL
(CID-keyed), not a /eli/... string parsed from prose. Each response repeats this in eli_note.
Case law is different: the API returns a native, authoritative ECLI for Cour de cassation (e.g.
ECLI:FR:CCASS:2025:C100399), Conseil constitutionnel (e.g. ECLI:FR:CC:2025:2025.1173.QPC) and
Conseil d'Etat (e.g. ECLI:FR:CECHR:2026:506507.20260529), surfaced verbatim in fr_get_decision.
CAA/TA decisions under CETAT frequently have no ECLI - the field is null, never fabricated.
Legifrance requires OAuth2 application credentials from a free PISTE account
(piste.gouv.fr → Applications → subscribe to the Legifrance API → OAuth Credentials).
Credentials are read from the environment only:
Variable | Meaning |
| OAuth token endpoint (sandbox default shown in |
| Legifrance |
| Your PISTE application client id (required). |
| Your PISTE application client secret (required). |
| Disk cache dir (default |
| Audit log dir (default |
Copy .mcp.json.example to .mcp.json (gitignored) and fill in your credentials, or set the
variables in your host environment. The OAuth token is cached in memory and refreshed automatically.
py -3.13 -m venv .venv
.\.venv\Scripts\python.exe -m pip install -e ".[dev]" # Windows
# or: python -m pip install -e ".[dev]" # POSIXpytest tests/test_instructions_drift.py tests/test_parse.py # offline, no creds
pytest tests/test_smoke.py -v # live, needs PISTE creds in .envBecause Legifrance requires a PISTE key, this connector is distributed through the PATRON / appliance channel (governed), not casual drop-in download. See the eu-legal-mcp line notes.
Apache-2.0. Legifrance content is © the French Republic / DILA and subject to the Legifrance / PISTE terms of use; this software only retrieves and cites it.
Declare what this connector covers, how it is sourced, and what it does NOT cover.
Call this before telling a user that the law "does not contain" something, and whenever a search comes back empty: the absence may be a gap in this connector rather than in the law. Every gap carries a fallback saying where to look instead.
Returns:
Coverage with families, an as-of note, and a non-empty list of known gaps.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| status | No | |
| families | No | |
| as_of_note | Yes | States what the dates mean, and what they do not promise. |
| known_gaps | No | Never empty. An empty list would mean 'not checked', not 'no gaps'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by explaining the open-world nature explicitly ('the absence may be a gap in this connector rather than in the law') and by noting that 'Every gap carries a fallback saying where to look instead.' This provides behavioral context beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise. It starts with the core purpose, then provides contextual usage guidance, and ends with return value details. Every sentence earns its place; there is no fluff or redundancy. The formatting with a returned section adds clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters, rich annotations, and an output schema, the description adequately covers what an agent needs. It explains when to invoke the tool, what it returns (families, as-of note, known gaps), and the important caveat about fallbacks. There is no missing information that would affect correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. According to the calibration, a baseline of 4 is appropriate for zero-parameter tools. The description focuses on purpose and behavior, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Declare what this connector covers, how it is sourced, and what it does NOT cover.' It uses a specific verb ('Declare') and resource ('connector coverage'), and it is clearly distinct from sibling tools like fr_search or fr_get_act, which perform searches or retrievals. The purpose is unambiguous and easily distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Call this before telling a user that the law 'does not contain' something, and whenever a search comes back empty.' This clearly indicates the appropriate context. However, it does not explicitly state when not to use it or name alternative tools, though it implies that searches should be done first. This is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consult a LODA law or decree by its LEGITEXT... id.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | version date ``YYYY-MM-DD`` (default: today - the version in force now). | |
| text_id | Yes | a ``LEGITEXT...`` identifier (from ``fr_search`` on fond ``LODA``). |
| Name | Required | Description |
|---|---|---|
| cid | No | |
| nor | No | |
| etat | No | |
| title | No | |
| nature | No | |
| eli_uri | No | |
| text_id | No | |
| articles | No | |
| eli_note | No | |
| source_url | No | |
| num_parution | No | |
| date_parution | No | |
| date_fin_version | No | |
| date_debut_version | No | |
| human_readable_citation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds no new behavioral details (e.g., error handling, rate limits). This is acceptable given the high annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the essential purpose with no wasted words. It could benefit from slightly more context but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple interface with 2 parameters and an output schema. The description is minimal but sufficient for an agent to understand the basic function. More details on behavior or output format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the input schema (100% coverage). The description adds no extra parameter semantics beyond what the schema provides, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool consults a LODA law or decree by a LEGITEXT identifier, which distinguishes it from sibling search tools. However, it does not explicitly differentiate from other get tools like fr_get_text or fr_get_decision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a LEGITEXT ID is available, and the parameter description hints at prior use of fr_search. But there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consult a company-level agreement by its ACCOTEXT... id - METADATA ONLY.
Legifrance distributes the full text of ACCO agreements only as a .docx
attachment, so this tool returns the agreement metadata (company, SIRET, IDCC,
sector, themes, signatory unions, dates) plus the resolvable source_url.
| Name | Required | Description | Default |
|---|---|---|---|
| agreement_id | Yes | an ``ACCOTEXT...`` identifier (from ``fr_search`` on fond ``ACCO``). |
| Name | Required | Description |
|---|---|---|
| idcc | No | |
| siret | No | |
| title | No | |
| nature | No | |
| themes | No | |
| eli_uri | No | |
| secteur | No | |
| code_ape | No | |
| syndicats | No | |
| date_depot | No | |
| date_effet | No | |
| date_texte | No | |
| source_url | No | |
| agreement_id | No | |
| raison_sociale | No | |
| attachment_note | No | |
| human_readable_citation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds value by explaining the tool returns metadata only and why, plus mentions the source_url. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, both essential. The first sentence states the core purpose and a key constraint. The second explains the rationale and return content. No extraneous words; information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one parameter, good schema coverage, annotations present, output schema exists), the description covers the return value (metadata fields plus source_url) and the limitation regarding full text. It is sufficiently complete for an AI agent to understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for agreement_id is already detailed, mentioning its format and origin. The tool description does not add new semantic information beyond what the schema provides. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool consults a company-level agreement by its ACCOTEXT id and returns metadata only. It distinguishes itself from siblings by specifying it targets ACCO agreements and explains why full text is not provided (Legifrance distributes as .docx).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool (to get agreement metadata) and notes that the full text is a .docx attachment, implying it should not be used to retrieve full text. However, it does not explicitly compare with sibling tools or provide when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consult a collective labour agreement text by its KALITEXT... id.
| Name | Required | Description | Default |
|---|---|---|---|
| convention_id | Yes | a ``KALITEXT...`` identifier (from ``fr_search`` on fond ``KALI``). |
| Name | Required | Description |
|---|---|---|
| cid | No | |
| nor | No | |
| etat | No | |
| title | No | |
| nature | No | |
| eli_uri | No | |
| text_id | No | |
| articles | No | |
| eli_note | No | |
| source_url | No | |
| num_parution | No | |
| date_parution | No | |
| date_fin_version | No | |
| date_debut_version | No | |
| human_readable_citation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which cover the behavioral safety profile. The description adds minimal behavioral context beyond 'Consult', which is consistent with annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 12-word sentence that front-loads the verb and resource, with no unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one well-described parameter, rich annotations, and an existing output schema, the description is complete enough to allow an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, so baseline is 3. The tool description does not add additional meaning beyond restating the parameter's purpose and the identifier format, which is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Consult a collective labour agreement text' using a specific identifier format 'KALITEXT...', which distinguishes it from sibling tools like fr_get_act or fr_get_text that deal with different document types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the identifier comes from fr_search on fond KALI, providing context for obtaining the input. However, it does not explicitly state when not to use this tool versus alternatives, though the sibling names imply distinct document categories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consult a court decision by its id (returns the native ECLI).
Covers three jurisdictions via the same Legifrance consult/juri endpoint:
JURITEXT... - Cour de cassation / cours d'appel (fond JURI).
CONSTEXT... - Conseil constitutionnel QPC/DC decisions (fond CONSTIT).
CETATEXT... - Conseil d'Etat, CAA, TA administrative case law (fond CETAT).
| Name | Required | Description | Default |
|---|---|---|---|
| decision_id | Yes | a ``JURITEXT...``, ``CONSTEXT...`` or ``CETATEXT...`` identifier (from ``fr_search`` on fond ``JURI``, ``CONSTIT`` or ``CETAT`` respectively). |
| Name | Required | Description |
|---|---|---|
| ecli | No | |
| text | No | |
| title | No | |
| nature | No | |
| eli_uri | No | |
| solution | No | |
| byte_size | No | |
| formation | No | |
| date_texte | No | |
| source_url | No | |
| decision_id | No | |
| juridiction | No | |
| numero_affaire | No | |
| human_readable_citation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, openWorldHint, and non-destructive. The description adds that it returns the native ECLI and uses the Legifrance consult/juri endpoint, which provides some additional behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise, with the main action in the first sentence and the rest used to explain the id format variants. It is front-loaded and avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, the presence of an output schema, and comprehensive annotations, the description provides sufficient context for an agent to select and invoke the tool correctly. It covers purpose, id formats, and relationship to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. The input schema's description of decision_id already explains the id formats. The tool description reinforces these formats but does not add new semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool consults a court decision by its id and returns the native ECLI. It distinguishes from siblings by specifying three jurisdictions with distinct id prefixes (JURITEXT, CONSTEXT, CETATEXT).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool (when you have a decision id from fr_search with specific fonds) and implicitly differentiates from siblings by listing id formats. It does not explicitly state when not to use or name alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consult a CNIL deliberation by its CNILTEXT... id.
| Name | Required | Description | Default |
|---|---|---|---|
| deliberation_id | Yes | a ``CNILTEXT...`` identifier (from ``fr_search`` on fond ``CNIL``). |
| Name | Required | Description |
|---|---|---|
| num | No | |
| etat | No | |
| text | No | |
| title | No | |
| nature | No | |
| eli_uri | No | |
| byte_size | No | |
| date_texte | No | |
| source_url | No | |
| title_long | No | |
| nature_delib | No | |
| deliberation_id | No | |
| date_publication | No | |
| human_readable_citation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds no behavioral information beyond what is in the annotations, such as potential rate limits or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short, front-loaded sentence that directly states the tool's purpose without any extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter), rich annotations, and presence of an output schema, the description provides sufficient context for an agent to understand the tool's basic operation and dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for deliberation_id that explains its format and source. The main description repeats this information, adding no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Consult' and the resource 'a CNIL deliberation', and specifies the id format 'CNILTEXT...'. It effectively distinguishes from sibling tools like fr_search (which finds the id) and other get tools for different document types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the id source ('from fr_search on fond CNIL'), implying this tool is used after obtaining the id via fr_search. However, it does not explicitly state when not to use it or provide alternatives beyond the implicit dependency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the verbatim text of a single article (LEGIARTI... or KALIARTI...).
| Name | Required | Description | Default |
|---|---|---|---|
| article_id | Yes | a ``LEGIARTI...`` identifier (from ``fr_get_act`` or a ``CODE`` search hit), or a ``KALIARTI...`` identifier (from ``fr_get_convention``). |
| Name | Required | Description |
|---|---|---|
| num | No | |
| etat | No | |
| text | No | |
| eli_uri | No | |
| date_fin | No | |
| eli_note | No | |
| byte_size | No | |
| article_id | No | |
| code_title | No | |
| date_debut | No | |
| source_url | No | |
| full_sections_titre | No | |
| human_readable_citation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by clarifying that the tool returns 'verbatim text' of a 'single article', indicating limited scope. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that conveys essential information without any superfluous words, demonstrating excellent conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, read-only, idempotent) and the presence of an output schema, the description adequately covers the main behavior. It could optionally mention that the output is the actual article text, but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter article_id has 100% schema coverage, with the schema description detailing the identifier format and origin. The description adds no further parameter-level detail beyond the purpose, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches verbatim text of a single article and specifies the acceptable identifier patterns (LEGIARTI... or KALIARTI...), distinguishing it from sibling tools like fr_get_act or fr_get_convention which handle different objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning identifiers come from fr_get_act or fr_get_convention, but does not explicitly state when to use this tool over alternatives or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword-search French legislation or case law on Legifrance.
| Name | Required | Description | Default |
|---|---|---|---|
| fond | No | one of ``LODA`` (laws & decrees), ``CODE`` (codes), ``JURI`` (Cour de cassation case law), ``CONSTIT`` (Conseil constitutionnel - QPC/DC decisions), ``CETAT`` (administrative case law: Conseil d'Etat, cours administratives d'appel, tribunaux administratifs), ``CNIL`` (CNIL deliberations, incl. sanctions), ``KALI`` (collective labour agreements / conventions collectives), ``ACCO`` (company-level agreements - metadata + search only). | LODA |
| query | Yes | free-text query (e.g. "republique numerique", "responsabilite"). | |
| page_size | No | number of hits (1..100). |
| Name | Required | Description |
|---|---|---|
| fond | Yes | |
| hits | No | |
| query | Yes | |
| total | Yes | |
| eli_note | No | |
| dataset_note | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description does not add any behavioral traits beyond stating it is a search operation. No contradiction, but no added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, clear and to the point. No wasted words. However, it could be slightly more informative without becoming verbose, but current structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but indicated true), the description does not need to explain return values. The description covers the essential purpose. Could mention that it searches across multiple fond types, but the schema already does that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed parameter descriptions for fond (enumerating values), query, and page_size. The description does not add meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Keyword-search French legislation or case law on Legifrance' clearly states the verb (search), resource (French legislation or case law), and context (Legifrance). It distinguishes from sibling tools that are all 'get' operations for specific documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It is implied by the sibling names (e.g., fr_get_act) that search is for finding documents while get tools retrieve specific ones, but no direct when/when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.5.3fr_coveragev0.4.1fr_get_actfr_get_company_agreementfr_get_conventionfr_get_decisionfr_get_deliberationfr_get_textfr_searchEach tool targets a distinct type of French legal document (legislation, court decisions, CNIL deliberations, collective agreements, company agreements) with unique ID patterns clearly described. No two tools overlap in purpose.
All tools follow a consistent 'fr_verb' pattern with snake_case, using 'fr_search' for search and 'fr_get_*' for retrieval. This makes the naming predictable and easy to navigate.
With 7 tools covering core French legal document types (acts, articles, decisions, deliberations, conventions, company agreements, and search), the count is well-scoped for the domain without unnecessary redundancy.
The toolset provides search and retrieval for all major Legifrance document types. Minor gaps exist, such as missing tools for listing articles within an act or browsing document structures, but the core operations are covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Official MCP connector for Legalize: read and search its whole open corpus, at any point in time.
Japan Law MCP — Japanese national laws & ordinances via the e-Gov Law API.
Resolve, search and verify legal citations against the official sources, with provenance.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/matematicsolutions/fr-eli-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
