Droit français et européen officiel (Légifrance, DILA, EUR-Lex, jurisprudence), réponses sourcées.
Scored across 13 tools
The set splits cleanly along French vs. EU and search vs. read axes (rechercher_loi/lire_article/lire_texte vs. rechercher_droit_ue/lire_texte_ue), and lire_decision is clearly the full-text reader for French case law. A few boundaries blur: lire_texte_ue covers both EU act articles and full arrêt text (overlapping conceptually with rechercher_jurisprudence_ue's follow-up step), and rechercher_loi with base=jorf overlaps lire_texte on text identification. Overall still highly distinguishable.
Almost all tools follow a French verb_noun pattern (lire_*, rechercher_*, analyser_conformite, verifier_references, lister_codes) with predictable suffixes for EU variants. Two exceptions are noun-only labels (etat_base, liens_droit_ue_france), which break the otherwise uniform convention. Minor deviation, but the pattern remains readable.
13 tools sit comfortably in the ideal range for a legal research server. Each tool maps to a distinct capability (search legislation, read article, read text plan, read decision, EU search/read, cross-link, freshness, conformity pre-analysis, reference checking) with no filler. Nothing looks redundant or missing from the count perspective.
The surface covers the full legal research lifecycle: discovery (rechercher_*), reading (lire_*), EU-French crosswalk, data currency (etat_base), and citation safety (verifier_references), plus a pre-analysis entry point. Minor gaps: no tool to inspect consolidated version history/compare dates, no enumeration of available jurisprudence bases or EU act lists analogous to lister_codes, and no way to retrieve doctrine/commentary or JORF tables. Agents can work around these via existing search parameters.
Pré-analyse de conformité d'un projet en France et dans l'UE (RGPD, cookies, vente en ligne, abonnements, IA, DSA, droit d'auteur, mentions légales...). description : le projet en quelques phrases (activité, public, données collectées, paiement, prestataires, usage de l'IA). domaines : clés à forcer, séparées par des virgules. Renvoie les obligations probables, la question à vérifier pour chacune et l'outil pour lire le texte. Lire ensuite chaque texte avant de conclure : information juridique, pas certification.
| Name | Required | Description | Default |
|---|---|---|---|
| domaines | No | ||
| description | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose key behaviors: it returns *probable* obligations plus a verification question and the tool to read the source text, and warns this is 'information juridique, pas certification'. It does not state the read-only nature or other safety traits, but the reliability caveat is genuinely valuable.
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?
Front-loads the purpose, then documents each parameter and the follow-up instruction. The parenthetical domain list earns its place by scoping coverage, though the parameter documentation slightly muddles the structure by interleaving schema semantics into the description.
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?
For a 2-param analysis tool with no annotations, the description covers purpose, both parameters, the return nature (though an output schema exists) and the critical verification caveat. It is complete enough to call correctly, with only the domain-key specifics left under-defined.
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 0%, so the description must compensate and largely does: 'description' is explained with concrete content to include (activité, public, données, paiement, prestataires, IA) and 'domaines' is described as forced, comma-separated keys. The 'clés à forcer' phrase is a bit vague about which keys are valid, leaving a small gap.
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?
States a specific verb+resource ('Pré-analyse de conformité d'un projet') with an explicit scope (France/UE, RGPD, cookies, IA, DSA, etc.). This is clearly distinguishable from the sibling lookup tools (rechercher_*, lire_*) because it is the pre-analysis entry point.
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?
Prescribes the workflow ('Lire ensuite chaque texte avant de conclure'), routing the agent to lire_texte/lire_article as follow-ups. It gives clear context for when to use it, but never explicitly contrasts it with alternatives or states 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.
Comptes, date des dumps et du dernier incrémental DILA appliqué pour chaque base : à citer pour indiquer l'actualité des données.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden alone. It is implicitly a side-effect-free informational read and the content it returns is described, but read-only status, cost, and whether this reflects a live or snapshot state are not stated outright. Low risk given zero parameters, but the disclosure is thin.
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?
A single sentence with zero filler, and the returned content is listed before the usage hint. The colon construction is dense but readable and front-loads the useful 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?
With no parameters and an output schema documenting the return shape, the description only needed to convey purpose and when to cite it, which it does. Only the trigger condition for calling it remains implicit.
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 takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The mention of 'chaque base' does hint that the result is a per-database collection, which slightly helps interpretation even though the output schema already covers the structure.
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 names the concrete payload (counts, dump dates, last DILA incremental per database), which is specific enough to distinguish it from every sibling, all of which retrieve legal content rather than dataset metadata. It stops short of a clean verb phrase, but the resource and its contents are unambiguous.
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?
'à citer pour indiquer l'actualité des données' gives one real usage rule: cite this to state data freshness. It does not say when an agent should proactively call it (e.g., before citing a text, or when asked about data currency) nor does it exclude anything, so guidance is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liens entre droit de l'UE et droit français. Sans numero : reference est un acte européen (CELEX, RGPD, « directive 2019/770 »...) et on obtient les textes et articles français qui le transposent ou le citent. Avec numero : reference est un code (« Code de la consommation ») et numero un article (« L217-4 ») : on obtient les actes européens liés. source : transposition (mesures déclarées à l'Union) ou mention (article qui cite l'acte). Liste non exhaustive : seuls sont recensés les rattachements déclarés à l'Union et les citations expresses.
| Name | Required | Description | Default |
|---|---|---|---|
| limite | No | ||
| numero | No | ||
| source | No | ||
| reference | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does meaningful work: it explicitly warns that results are non-exhaustive, covering only declared transposition measures and express citations, which prevents an agent from treating an empty result as proof of no linkage. It also defines the semantics of the two `source` values. It does not mention result volume, pagination, or how `limite` affects output.
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 purpose is front-loaded and each subsequent clause earns its place: the two modes, the source values, then the coverage caveat. It is dense and unformatted, so the mode switch relies on the reader parsing 'Sans numero' / 'Avec numero' inline, but there is no filler.
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?
An output schema exists, so return values need not be explained, and the description covers the two critical things a caller needs: which input form triggers which direction, and the non-exhaustive nature of the corpus. The one substantive gap is the unexplained `limite` parameter for a tool that can return a list of texts.
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 0%, so the description must compensate, and it does for three of four parameters: `reference` is given dual, conditional semantics tied to `numero`, `numero` is illustrated with a concrete example ('L217-4'), and `source` is defined by its two accepted values. `limite` is never mentioned, leaving its effect and default of 15 undocumented anywhere.
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 opening sentence names the resource (links between EU law and French law) and the description then specifies precisely what the tool returns: French texts/articles that transpose or cite an EU act, or the EU acts linked to a given French article. The bidirectional framing makes it obviously distinct from siblings like rechercher_droit_ue or lire_texte_ue, which retrieve one side of the corpus rather than the linkage.
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 gives explicit conditional routing: 'Sans numero' invokes the EU-act-to-French-law direction, 'Avec numero' invokes the French-code-article-to-EU-act direction, with concrete examples of each input form. It also explains that the `source` value selects between transposition and mention. It stops short of naming alternative sibling tools or stating when not to use this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Texte d'un article de code ou de loi, tel qu'en vigueur à une date. code : « Code civil », « Code du travail »... ; numero : « 1240 », « L1221-1 » ; date : AAAA-MM-JJ (défaut aujourd'hui).
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | ||
| date | No | ||
| numero | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden; it does disclose the important trait that results reflect the version in force at a given date (defaulting to today). However, it says nothing about behavior when an article or date is invalid, nor about any permissions or rate limits.
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?
Two compact clauses, front-loaded with the purpose and then the parameter formats, with zero filler. Nothing can be trimmed without losing 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?
An output schema exists, so return values need no explanation, and all three undocumented schema parameters are covered by the description. What remains missing is sibling routing and error behavior, which is a modest gap for a simple read tool.
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 0%, so the description must compensate, and it largely does: it gives concrete formats and examples for all three parameters (code names like « Code civil », numbers like « 1240 » or « L1221-1 », dates as AAAA-MM-JJ). Minor mismatch: the schema default is an empty string while the description says the default is today.
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?
States a specific resource (the text of an article of a code or law) and the key scoping concept (as in force at a given date), so the agent knows exactly what is returned. It does not explicitly distinguish itself from close siblings like lire_texte or lire_decision, which leaves some disambiguation to name inference.
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 says nothing about when to use this tool versus lire_texte, rechercher_loi, or lire_decision, and gives no preconditions or exclusions. Only the parameter examples hint at the intended usage pattern, which the agent must infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Texte intégral d'une décision à partir de son identifiant (JURITEXT..., CONSTEXT..., CNILTEXT...).
| Name | Required | Description | Default |
|---|---|---|---|
| identifiant | Yes | ||
| max_caracteres | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it only conveys that this is a read of 'full text'. It does not disclose the truncation behavior implied by max_caracteres (default 20000), what happens when the identifier is invalid, or any permission/auth requirements.
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?
A single, front-loaded sentence with zero waste that puts the verb and resource first and the identifier format parenthetically. It is efficient, though the extreme brevity leaves needed behavioral detail unstated.
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?
An output schema exists, so return values need not be explained. However, given no annotations and an undocumented max_caracteres that governs truncation, the definition is only minimally complete for correctly invoking and interpreting the tool.
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 0%, so the description must compensate. It meaningfully documents the identifier format (JURITEXT/CONSTEXT/CNILTEXT), which adds real value beyond the schema, but it says nothing about max_caracteres, which controls response truncation — a notable gap for a tool returning large full texts.
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?
States a specific verb (lire/read) and resource (décision) and clarifies that it returns full text from an identifier. The identifier prefix examples (JURITEXT, CONSTEXT, CNILTEXT) make the scope precise. It does not explicitly contrast with siblings like rechercher_jurisprudence or lire_texte, so it falls short of a 5.
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 purpose implies usage (fetch a decision's full text when you have its ID), but there is no explicit when-to-use guidance, no mention of pairing it with rechercher_jurisprudence to obtain IDs first, and no exclusions versus lire_texte or analyser_conformite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fiche et plan d'un texte : identifiant LEGITEXT/JORFTEXT, NOR, numéro IDCC d'une convention collective, ou nom (« Code de la consommation »).
| Name | Required | Description | Default |
|---|---|---|---|
| identifiant_ou_nom | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does clarify the scope of the return ('fiche et plan', i.e. metadata and structure, not the full text) and the accepted identifier families, but says nothing about behavior on an unknown or ambiguous name, whether matching is exact or fuzzy, or permissions.
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?
A single sentence that front-loads the returned value and then the accepted input forms, with no filler. Slightly terse for non-French-legal readers, but every clause carries 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?
For a one-parameter read tool with an output schema (so return structure needn't be described) and no annotations, the description covers purpose and all input formats. The remaining gap is failure/ambiguity behavior when a name is given.
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 0% — 'identifiant_ou_nom' has no description at all — so the description must compensate, and it does: it enumerates four valid identifier forms plus a concrete example ('Code de la consommation'). It stops short of saying whether names must be exact or how ambiguity is resolved.
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 names the resource (a legal 'texte') and what is returned ('fiche et plan'), which separates it from lire_article (an article) and lire_decision (a court decision). The verb is implicit in the noun phrase 'Fiche et plan' rather than stated, so it falls short of a fully explicit verb+resource statement.
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?
Usage is only implied: by enumerating the accepted identifiers (LEGITEXT/JORFTEXT, NOR, IDCC, or a code name) the description signals when this tool is applicable. It never states when to use it instead of rechercher_loi (to find a text) or lire_article (to read a specific article), and offers no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Droit de l'UE : fiche, plan ou article d'un acte, ou texte d'un arrêt. reference : CELEX (32016R0679), alias (RGPD, DSA, DMA, RIA, TFUE, Charte), « règlement (UE) 2016/679 », « directive 93/13/CEE », numéro d'affaire (C-131/12) ou ECLI. article : « 17 », « premier », « Annexe III ».
| Name | Required | Description | Default |
|---|---|---|---|
| article | No | ||
| reference | Yes | ||
| max_caracteres | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries full burden; 'lire' implies read-only, and it does disclose the range of retrieval modes (fiche/plan/article/arrêt), which is genuinely useful. It is silent on truncation behavior (max_caracteres), pagination, and permission/auth requirements, leaving the mutation-free but incomplete picture thin.
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 purpose is front-loaded in the first clause, and the two following fragments carry only format examples with no filler. The telegraphic style is dense but every element 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?
An output schema exists, so return values need not be explained. However, the description never clarifies how the output mode is chosen (omitting 'article' for a fiche/plan vs. supplying it for article text) or what max_caracteres truncation does, which is a real gap for an agent trying to call it correctly the first time.
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 0%, yet the description compensates heavily for 'reference' (CELEX, alias, citation forms, case number, ECLI) and 'article' ('17', 'premier', 'Annexe III') with concrete examples. Only 'max_caracteres' is left unaddressed, and its name plus the 20000 default make it largely self-explanatory.
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 gives a specific verb plus resource ('lire' + 'Droit de l'UE') and enumerates the retrievable outputs (fiche, plan, article, arrêt text), which is far beyond restating the name. It doesn't contrast itself with nearby siblings like rechercher_droit_ue or lire_texte, but the UE scope disambiguates well enough on its own.
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 acceptable reference and article input formats are spelled out, which implies when the tool applies, but there is no explicit guidance on when to choose it over rechercher_droit_ue or lire_article, and no mention of a lookup-first workflow. Usage is therefore inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liste des codes disponibles.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. "Liste" implies a read-only enumeration with no side effects, and the output schema covers the return shape, but the description is silent on scope, completeness, pagination, or permissions.
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?
A single short sentence with no filler, and the core operation is front-loaded. It is arguably too terse, but that is a completeness problem rather than a conciseness violation.
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?
For a simple 0-parameter listing tool with an output schema, the essentials are present, but the description never clarifies what a "code" is (legal codes vs. identifiers) or how the result relates to the other legal-research tools. That ambiguity is the main remaining gap.
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 takes zero parameters, so there is no parameter semantics to explain; baseline 4 applies. The empty schema is self-explanatory and the description does not need to compensate.
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?
"Liste des codes disponibles" gives a clear verb (list) and resource (codes), so an agent knows this is an enumeration tool. It fails to differentiate from siblings such as etat_base or the rechercher_* tools, and does not clarify what a "code" is in this legal-research context.
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 indication of when to use this instead of alternatives, no prerequisites, and no mention of related sibling tools. The agent must infer that this is the way to discover the code corpus before calling lire_texte or rechercher_loi.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche plein texte dans les règlements, directives, traités et la Charte (en français). acte : restreindre à un acte (RGPD, 32022R2065...). Syntaxe : "phrase exacte", AND, OR, NOT, prefixe*.
| Name | Required | Description | Default |
|---|---|---|---|
| acte | No | ||
| limite | No | ||
| requete | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the search scope, French-only language, acte restriction, and supported query operators. It does not mention read-only safety, result ordering, pagination behavior, or the role of the limite parameter, so significant behavioral context is missing.
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 compact, front-loaded, and structured into search scope, acte restriction, and query syntax. Every sentence adds useful information, and there is no wasted text.
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 an output schema, so return values need not be explained. The description covers purpose, scope, and query syntax well, but for a 3-parameter tool it omits any explanation of limite and does not differentiate usage from sibling search tools, leaving enough gaps that an agent might need to guess about result limiting.
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 0%, so the description must compensate. It adds meaningful semantics for requete (phrase exacte, AND, OR, NOT, prefixe*) and for acte (examples RGPD, 32022R2065), but it never explains the limite parameter at all, leaving one of three parameters undocumented.
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 a full-text search verb over a specific resource set (règlements, directives, traités, Charte) and language (français). It is distinguishable from siblings like rechercher_loi or rechercher_jurisprudence_ue by the EU-law scope, though it does not name those siblings explicitly.
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 explains how to restrict by a specific acte and gives query syntax, which implies use for EU legal text search. However, it does not explicitly say when to use this tool instead of alternatives such as rechercher_loi, rechercher_jurisprudence_ue, or lire_texte_ue, leaving comparison to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche de décisions. base : jade (juridictions administratives), cass (Cour de cassation), capp (cours d'appel), inca (Cassation inédits), constit (Conseil constitutionnel), cnil. numero : pourvoi ou requête (21-21.185). du/au : AAAA-MM-JJ. tri : pertinence ou date.
| Name | Required | Description | Default |
|---|---|---|---|
| au | No | ||
| du | No | ||
| tri | No | pertinence | |
| base | No | ||
| ecli | No | ||
| limite | No | ||
| numero | No | ||
| requete | No | ||
| formation | No | ||
| juridiction | No | ||
| publiees_seulement | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about read-only safety, result volume, pagination, rate limits, or coverage per base. It only hints at input syntax; the presence of an output schema excuses return-value explanation but not the operational characteristics an agent needs before calling an 11-parameter search.
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 telegraphic, front-loaded format is dense and waste-free: one clause per parameter with no filler. It is under-specified rather than bloated, so the terseness costs completeness but not 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?
An output schema exists, which removes the need to describe return values. But with 11 optional parameters, zero schema descriptions, and no annotations, the definition leaves too much unspecified — notably requete, which is likely the free-text query and is the single most consequential missing definition.
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 0%, so the description must compensate, and it does for four parameters: base (with values), numero (with a 21-21.185 example), du/au (AAAA-MM-JJ), and tri (pertinence/date). Six parameters remain entirely undocumented — ecli, requete (arguably the primary full-text query), juridiction, formation, limite, publiees_seulement — leaving the most important retrieval knobs unexplained.
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?
"Recherche de décisions" names a specific verb and resource, and the enumerated base values (jade, cass, capp, inca, constit, cnil) make clear this searches French case-law databases. It does not, however, distinguish itself from the sibling rechercher_jurisprudence_ue or from lire_decision, so the agent must infer the boundary.
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?
There is no statement of when to use this tool rather than rechercher_loi, rechercher_jurisprudence_ue, or lire_decision, and no prerequisite or exclusion guidance. The agent is left to infer routing from the base list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche plein texte dans les arrêts de la Cour de justice de l'UE et du Tribunal (en français). du/au : AAAA-MM-JJ. tri : pertinence ou date. Lire ensuite l'arrêt avec lire_texte_ue (numéro d'affaire ou CELEX).
| Name | Required | Description | Default |
|---|---|---|---|
| au | No | ||
| du | No | ||
| tri | No | pertinence | |
| limite | No | ||
| requete | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It specifies the search is full-text and restricted to French, and gives date format and sort options, which adds useful operational context. However, it does not mention the result limit (limite), default behavior, or any access constraints, leaving some gaps for a no-annotation tool.
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?
Front-loaded with the core purpose, followed by compact fragments for date format, sort options, and next step. No wasted sentences, though the fragments could be slightly more structured.
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?
An output schema exists so return values need not be explained, and the workflow hint (read with lire_texte_ue) is helpful. Still, for a search tool with no annotations and 0% schema coverage, the missing semantics for limite and requete leave the definition only adequate, not complete.
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 0%, so the description must explain all five parameters. It covers du/au (format AAAA-MM-JJ) and tri (pertinence ou date), but omits limite entirely and says nothing about requete beyond it being the query. Two parameters remain undocumented by description or 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?
States a specific verb and resource: full-text search in EU Court of Justice and General Court judgments, in French. This distinguishes it from siblings like rechercher_jurisprudence (likely national) and rechercher_droit_ue, but does not explicitly name alternatives.
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?
Provides some context (full-text, French, date format, sort options) and a follow-up step via lire_texte_ue, but never states when to use this tool versus siblings such as rechercher_jurisprudence or rechercher_droit_ue. Usage remains implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche plein texte dans les articles. base : legi (codes, lois, décrets consolidés, défaut), kali (conventions collectives), jorf (Journal officiel tel que publié) ou tout. Syntaxe : "phrase exacte", AND, OR, NOT, prefixe*. code : restreindre à un code, un texte ou « IDCC 1486 ». date : AAAA-MM-JJ, version en vigueur à cette date (défaut aujourd'hui).
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | legi | |
| code | No | ||
| date | No | ||
| limite | No | ||
| requete | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose valuable behavior: default base is legi, and date returns the version in force at that date (default today), which is a meaningful temporal-snapshot trait. It says nothing about result volume, pagination, behavior of the limite parameter, or what happens on malformed query syntax.
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?
Terse, front-loaded with the purpose before the parameter notes, and free of filler. The fragment style ("base : …", "code : …") is efficient, though the syntax sentence is packed densely enough to require careful reading.
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?
An output schema exists, so return values need not be described, and the search-syntax and date-versioning rules are genuinely useful. Still, for a 5-parameter tool with zero schema descriptions and no annotations, leaving limite unexplained and giving no sibling routing is a noticeable gap.
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 0%, so the description must compensate. It explains three of five parameters well: base (with all accepted values and the default), code (restriction to a code/text or "IDCC 1486"), and date (AAAA-MM-JJ with version-in-force semantics). The required requete is only implied by the opening sentence, and limite (default 10) is never mentioned.
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?
States a specific verb and resource ("Recherche plein texte dans les articles") and enumerates the corpora searched (codes, lois, décrets, conventions collectives, Journal officiel). This implicitly separates it from the jurisprudence/UE search siblings, but no sibling is ever named, so the differentiation must be inferred.
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 base values and defaults imply when to pick legi/kali/jorf/tout, which is real routing guidance, but the description never states when to use this tool rather than rechercher_jurisprudence or lire_article, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Contrôle que chaque référence existe avant de la citer. references : « Code civil 1240 », « LEGIARTI000032041571 », « 21-21.185 », « ECLI:FR:... », « RGPD art. 17 », « règlement (UE) 2024/1689, article 50 », « C-131/12 ». citations : extraits censés figurer mot pour mot dans la référence de même rang. Toute ligne INTROUVABLE ou citation ABSENTE interdit la citation.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| citations | No | ||
| references | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that matching is exact ('mot pour mot'), that references and citations are aligned by rank ('de même rang'), and that INTROUVABLE/ABSENTE results block citation. However it never explains what 'exists' means (which sources are checked) or how the date parameter affects behavior, leaving real gaps.
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?
Purpose is front-loaded and the example list, while long, earns its place by pinning down accepted reference formats. The interdiction rule closes cleanly. Slightly dense but free of filler.
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?
An output schema exists, so return values needn't be explained. Yet for a 3-parameter verification tool the description leaves the date parameter and the scope of existence-checking (which databases/treatments) undefined, so an agent calling it has unresolved questions beyond the schema.
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 0%, so the description must compensate. It explains references thoroughly with seven format examples and clarifies citations as word-for-word excerpts matched to the reference of the same rank — a meaningful relationship cue. But the third parameter, date, is entirely undocumented.
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 opens with a specific verb+resource: 'Contrôle que chaque référence existe avant de la citer'. The concrete example formats (Code civil, LEGIARTI, ECLI, C-131/12) make the domain unambiguous. It reads as a verification tool distinct from the search/read/list siblings, though it never explicitly contrasts itself against them.
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?
'avant de la citer' gives a clear trigger (use before emitting a citation) and the rule 'Toute ligne INTROUVABLE ou citation ABSENTE interdit la citation' defines the consequence. It does not name alternatives or state exclusions, keeping it short of a 5.
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.
liens_droit_ue_franceanalyser_conformiteetat_baselire_articlelire_decisionlire_textelire_texte_uelister_codesrechercher_droit_uerechercher_jurisprudencerechercher_jurisprudence_uerechercher_loiverifier_referencesFrench law articles, codes, collective agreements, case law (Judilibre) and IDCC lookup.
France LEGI — the official consolidated French codes (Code civil, Code pénal, Code du travail…
Droit français : textes, jurisprudence, citations et calculs. Connexion OAuth au compte BRANCO.
French court decisions (Cour de cassation and the judicial courts under it) — search, read a…
Add one secure layer between your agents and this server.