justicelibre

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

The readOnlyHint annotation already declares safety, so the description adds context about what information the tool provides (source mapping, routing rules, identifier compatibility). No contradictions with annotations, and it enriches the agent's understanding of the tool's content.

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, front-loaded with the core purpose and immediately followed by usage guidance. Every word contributes meaning; no fluff or redundancy.

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 this is a simple, zero-parameter help tool with an output schema, the description sufficiently explains what the tool tells the user and when to use it. It's complete for the agent to decide when to invoke it.

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 baseline is 4. The description doesn't need to explain parameters and instead focuses on the value delivered, which 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's purpose: an overview of the JusticeLibre protocol, covering source mapping and routing rules. It distinguishes itself from sibling search/get tools by being a meta-resource about the protocol itself.

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 explicitly instructs calling this tool first ('Appeler cet outil en priorité') to understand the compatibility matrix, search scopes, and database specifics. While it doesn't mention alternatives or when not to use it, the guidance is clear and contextually appropriate for a help tool.

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

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

The tool is annotated readOnlyHint=true, and the description adds substantial behavioral context: it lists recognized identifier patterns, explains the effect of the optional legitext and date parameters (e.g., date appends a suffix to point to historical versions), and specifies that unrecognized formats yield an {'error'} return. This goes well 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 relatively long but well-structured: a clear opening purpose, a 'Utile pour' usage line, a bulleted list of recognized identifiers, and a structured Args section. Every sentence contributes necessary detail for a non-trivial mapping tool, though it could be tightened slightly without loss of 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?

The tool has a complex mapping table across multiple legal databases, and the description covers all critical aspects: identifier formats, parameter semantics, return shape, and error behavior. The highlighted edge case about date being essential for historical versions shows thoughtful completeness. The output schema is present, so return details are redundant, but the description still mentions it.

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?

With 0% schema description coverage, the description bears the full burden of parameter documentation. It explains all three parameters: identifier (the ID to convert), legitext (optional parent LEGITEXT for LEGIARTI to distinguish codes vs non-codified laws), and date (optional YYYY-MM-DD to target a historical version). Each is described with format and purpose beyond the bare 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 opens with a specific verb and resource: 'Construit l'URL canonique d'un document à partir de son identifiant.' This clearly defines the tool's function and distinguishes it from the sibling search/get decision tools, which retrieve data rather than construct source URLs.

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 explicitly states when to use the tool: 'Utile pour vérifier les sources à la main sur le site officiel ... ou pour inclure un lien cliquable dans un courrier.' It also details recognized identifier formats, giving the agent a checklist of supported inputs. It does not explicitly mention alternatives or when not to use, but the use cases are clear enough.

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

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

Beyond the readOnlyHint annotation, it discloses exact SQL lookup behavior, the risk of random homonyms with 7-digit numbers, limitations of short codes for historic decisions, and the error return format. This is far more transparent than typical descriptions.

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?

Structured into clear sections (purpose, coverage, warning, args, returns, examples). Every sentence adds value, and the length is justified by the critical disambiguation guidance. Front-loaded with the main purpose.

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 description is complete for a tool with this complexity: it specifies input formats, disambiguation rules, return values, error handling, and provides two real-world examples. No critical information is missing.

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 has 0% description coverage, but the description thoroughly explains both parameters: numero with examples, juridiction with accepted formats (long names, short codes), ambiguity warnings, and preferred usage. Fully compensates for the schema 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?

The description clearly states 'Récupère une décision administrative par son numéro de requête exact' with explicit coverage of all administrative jurisdictions, distinguishing it from search tools and specific jurisdiction tools like get_ce_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?

It provides explicit guidance on when to use exact lookup versus FTS5, insists on passing juridiction when known, details acceptable formats, and explains when jurisdiction is unnecessary (e.g., CE numbers). Concrete examples illustrate correct usage.

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

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

Beyond the readOnlyHint annotation, the description discloses that the tool performs a full-text search on the number with a jurisdiction filter in judiciaire.db. It also details the return structure, including a structured error dict for 'not_found', adding valuable behavioral context.

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 with sections for purpose, format, arguments, and returns. It contains examples which are useful. Slightly verbose but every line contributes to clarity; it is not overly long.

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 tool with two parameters and an output schema, the description covers all necessary aspects: input format, search behavior, return type, and error handling. An output schema already exists, so detailed return structure is not required, but the description still supplies a concise summary.

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%, but the description fully compensates by explaining 'numero' with format examples and 'nature' as an optional filter with examples, plus a reference to search_cc for allowed values. This adds meaning far beyond the bare 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 'Récupère une décision du Conseil constitutionnel par son numéro' with a specific verb (récupère) and resource (decision by number). It distinguishes from sibling tools by specifying the Conseil constitutionnel jurisdiction and the input format, making it 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?

The description tells when to use this tool: when you have a decision number, with explicit format examples. It also cross-references search_cc for nature values, implying search_cc is for broader searching. It does not explicitly state exclusions, but the context is clear enough for an agent to differentiate.

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

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

Beyond the readOnlyHint annotation, the description discloses the fallback behavior: it tries bulk JADE DILA first, then ArianeWeb Sinequa, and that both bases have complementary coverage. It also specifies the error return format with `error_category: "not_found"`, which is valuable for handling failures.

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 efficient. It front-loads the main purpose, then adds fallback details, the alternative tool, and parameter/return information. Each sentence serves a distinct purpose, with no fluff or redundancy.

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 single-parameter, read-only tool with an output schema, the description is complete. It explains the parameter's meaning, the internal fallback logic, and the error contract. It even points to an alternative for a specific identifier type. No critical gaps remain.

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 property 'numero' is just a string with no schema description (0% coverage). The description compensates fully by defining 'numero' as 'numéro de pourvoi' and providing concrete examples ('"497566", "358109"'). This adds meaningful semantic content beyond the raw 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 opens with a clear, specific statement: 'Récupère une décision du Conseil d'État par son numéro de pourvoi.' This names the verb (récupère), resource (décision du Conseil d'État), and scope (par numéro de pourvoi). It also distinguishes from siblings by directing DCE_* identifier lookups to get_decision_text.

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 explicitly provides an alternative usage: 'Pour retrouver une décision via identifiant DCE_*, utiliser `get_decision_text` à la place.' It also conveys when to use this tool (when you have a numéro de pourvoi) and that it tries multiple databases. This gives clear when-to-use and alternative guidance.

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

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

Annotations already mark readOnlyHint=true, so the read nature is covered. The description adds error return structure (full_text vs. error dict with not_found), which is helpful. However, it fails to mention the 'id' parameter present in the schema, leaving ambiguity about which parameter to use. This incomplete disclosure reduces transparency.

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 brief (two short paragraphs) and front-loaded with purpose. Args and Returns are separated. It could be more structured (e.g., bullet lists), but it is efficient for the content provided.

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 context (output schema present, annotations present, sibling list large), the description covers purpose and return format but lacks full parameter documentation (missing 'id' parameter) and no usage guidance relative to siblings. It is adequate but incomplete.

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 parameters. It explains decision_id (format and example) but completely omits the 'id' parameter. For two parameters, only one is documented. This partially compensates but leaves the other parameter 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?

The description clearly states the tool extracts the full text of a European Court of Human Rights decision based on its system identifier (itemid HUDOC). This distinguishes it from sibling tools for other courts (e.g., get_cc_decision, get_cjue_decision) or search functions. The verb 'extraction' and the resource are specific.

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 you have an itemid HUDOC ID, but does not explicitly tell the agent when to use this vs. alternatives like search_cedh for finding IDs. No mention of prerequisites or exclusions. Guidance is implicit only.

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

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

Annotations already declare readOnlyHint=true, so the description only needed to add contextual behavior. It discloses that a decision with full_text is returned or a structured error dict with error category 'not_found' for unknown CELEX. This complements the annotation without contradicting it.

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: purpose, constraint, alternative, then args and returns. It is concise with minimal redundancy. However, the 'Args:' section repeats information already in the schema, and the example could be integrated more compactly.

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 description provides the core usage context: input format, data source, return shape. The output schema exists, so detailed return specification is less necessary. However, failing to explain the 'id' parameter leaves a critical gap, making the description incomplete for a tool with two parameters and zero schema-level descriptions.

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%, yet the description only documents one of the two parameters (decision_id) with an example. The second parameter 'id' is completely unexplained, and its purpose or relationship to decision_id is unclear. This is a significant deficiency for a tool with two parameterized inputs.

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 verb ('Extraction') and resource ('texte intégral d'une décision de la Cour de justice de l'Union européenne'), specifying the required identifier type (CELEX). It distinguishes this tool from siblings like search_cjue by explicitly limiting input to CELEX identifiers and directing users to search_cjue for ECLI-based lookup.

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 (when a CELEX identifier is already known), when-not-to-use (if only an ECLI is available), and the exact alternative (search_cjue to find the CELEX). It also states a prerequisite: the CELEX must first be retrieved via that sibling tool.

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

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

The description discloses the need for OAuth2 authentication and notes that credentials must never transit through the conversation, adding behavioral context beyond the `readOnlyHint` annotation. It also states the tool's inoperability for certain decision formats. Minor deduction as it does not describe any other traits like rate limits or error handling, but the annotation already covers safety.

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 concise and well-structured with a clear purpose, usage notes, and parameter explanations. It is front-loaded with the core action and uses bullet-like structure for constraints. Slight wordiness in the authentication section, but overall efficient for the complexity.

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 moderate complexity (3 parameters, no required ones, no enums, with output schema), the description is complete. It covers purpose, alternatives, exclusions, authentication, and parameter semantics. The output schema exists, so return values need not be explained. No gaps remain for an agent to misinvoke 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?

The schema description coverage is 0% (no schema descriptions), so the description must compensate. The description explains the `decision_id` as a Judilibre identifier and `session_token` as a temporary token, adding meaning beyond the schema's empty defaults. However, `id` (a third parameter) is not explained in the description, leaving a semantic gap. Baseline 3 with moderate compensation.

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 it extracts the full text of a judicial decision via the restricted PISTE API, specifying the exact resource ('décision judiciaire') and the action ('extraction du texte intégral'). It differentiates from the sibling tool `get_decision_judiciaire_libre` by clarifying that the latter should be used for open-access DILA decisions.

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: it should be substituted by `get_decision_judiciaire_libre` when the decision is in DILA open archives, and it is explicitly inoperative for administrative court decisions (formats DCE_*, DTA_*, etc.). It also details authentication prerequisites and alternatives, giving clear context for use.

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

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

Annotations already provide readOnlyHint=true, so the description adds value by stating no authentication needed and specifying accepted ID formats. It does not cover error behavior or what happens on invalid IDs, but the output schema exists to describe return values, making this a minor gap. No contradiction with 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 well-structured with a clear purpose sentence, followed by constraints and an explicit exclusion. The Args section is somewhat redundant with the schema but adds clarity. No wasted words, though the missing parameter documentation reduces efficiency.

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 complexity (2 parameters, 0% schema coverage, many siblings, output schema present), the description covers most key aspects: purpose, ID formats, exclusion. However, it fails to explain the 'id' parameter, which is a significant gap. The output schema likely covers return values, so that is acceptable.

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% and the description only explains the 'decision_id' parameter with format examples. The 'id' parameter is entirely undocumented, leaving the agent uncertain about its purpose or whether it is an alias. Given the low schema coverage, the description should clarify both parameters but fails to do so.

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 extracts full text of a judicial decision from an independent index without authentication. It explicitly distinguishes itself from sibling tools by specifying it is inoperative for administrative decisions and only works with specific ID formats (JURITEXT*, CONSTEXT*, JURI*), which differentiates it from get_admin_decision, get_ce_decision, etc.

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: it accepts only judicial free IDs returned by search_judiciaire_libre. It also gives a strong when-not-to-use statement: it is formally inoperative for administrative decisions. This helps the agent select the correct tool among many siblings without naming alternatives explicitly.

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

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

Annotations provide readOnlyHint: true, and the description adds significant behavioral context: it describes two data sources (bulk JADE local, direct Sinequa plugin), identifier parsing, and return format. No contradiction. The description carries the full burden and exceeds expectations.

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 with sections for accepted identifiers, incompatibilities, and args. It is front-loaded with purpose. While slightly verbose, every section earns its place given the complexity of identifier formats. Could be tightened by merging the last two paragraphs.

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 description covers tool purpose, identifier formats, data sources, error handling, and alternatives. With an output schema present, the explicit return format description is not strictly necessary but adds value. The main gap is the undocumented 'id' parameter, which reduces completeness for a tool with 2 parameters.

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 documents the 'decision_id' parameter with format details, but the 'id' parameter (also in the schema) is completely unexplained. This partial coverage falls short of full compensation. The description adds value for one parameter but misses the other.

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: extracting full text of administrative decisions (Conseil d'État, TA, CAA). It lists accepted identifier formats and distinguishes from sibling tools by specifying incompatible identifiers and redirecting to alternatives (e.g., get_decision_judiciaire, get_decision_cjue, get_decision_cedh). This is a specific verb+resource with clear sibling differentiation.

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 explicitly provides when-to-use and when-not-to-use guidance. It lists accepted identifiers, major incompatibilities with redirects to other tools, and explains the error response format with retryable flags and alternative tools to try. This is comprehensive usage guidance.

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

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

Annotations only indicate readOnlyHint=true, but the description adds substantial behavioral details: the historical rewriting nuance (1992 vs 2016), the returned state fields (VIGUEUR/MODIFIE/ABROGE), and the 'note' field when the version doesn't match the request. This goes well beyond the structured annotation.

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 with a clear lead sentence, a useful illustrative example, and separate Args/Returns sections. It is longer than average but the detail is relevant to the tool's complexity; it earns its place without being excessive.

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 complexity, the description covers all essential aspects: purpose, historical behavior, supported codes, parameter semantics, and return fields (including the note field). The presence of an output schema doesn't relieve the description of explaining the nuanced versioning behavior, which it does thoroughly.

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 has no descriptions (0% coverage), so the description fully compensates by explaining each parameter with concrete examples: 'code' (e.g., CC, CT), 'num' (e.g., 1128, L1152-1), and 'date' (ISO format, optional, with guidance to use the decision date). It also clarifies supported code formats and fallback identifiers.

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 function: 'Renvoie le texte d'un article de loi à une date donnée' with a specific verb and resource. It differentiates from siblings like get_law_versions and resolve_law_number by emphasizing the historical version retrieval and the supported code list.

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 concrete usage context: use the date of the citing decision to get the contemporaneous version. It also explains that for non-supported texts, one should pass a LEGITEXT/JORFTEXT identifier and references resolve_law_number() as a helper. However, it doesn't explicitly contrast with get_law_versions or other search tools.

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

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

Annotations already mark the tool as readOnlyHint true, so the safety profile is known. The description goes beyond this by detailing the return structure (dict with code, code_long, num, count, versions) and the ordering by date_debut ascending, as well as the fields available in each version. This gives the agent a clear picture of the output without invoking the 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?

The description is structured in clear sections (purpose, use case, args, returns) and every sentence adds value. The example with years is concise and illustrative. No filler or repetition; it stays within reasonable length for a tool with a rich return shape.

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 only two required parameters, and the description documents both parameters, the full return dictionary keys, the ordering, and the per-version fields. It also references a sibling for the code list, closing the last ambiguity. This is complete for an agent to select and invoke 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 description coverage is 0%, so the description must compensate. For code it says 'code court (voir get_law_article pour la liste des 26 codes/textes)', giving a direct pointer to valid values. For num it says 'numéro de l'article', which is clear enough. This fully compensates for the stark 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 begins with a clear verb and resource: 'Renvoie toutes les versions historiques d'un article de loi, du plus ancien au plus récent.' This specifies both the action and the object, and the ordering distinguishes it from the likely sibling get_law_article. The timeline example reinforces the unique purpose.

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?

It states an explicit use case: 'Utile pour construire une timeline de l'article et comprendre son évolution.' This tells the agent when to choose this tool. It also references get_law_article for the code list, implying a distinction, but it does not explicitly state exclusions or 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.

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

L'annotation readOnlyHint=true est déjà fournie, et la description ajoute des détails comportementaux utiles : la liste est exhaustive, couvre 51 instances avec leur nomenclature canonique, et sert de référence pour search_admin. Elle ne contredit pas les annotations et apporte un contexte au-delà de la seule sécurité.

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?

Deux courts paragraphes, trois phrases, aucune redondance. L'information essentielle est donnée en tête, suivie d'une directive d'usage. Chaque phrase apporte une valeur : définition, contenu, utilisation.

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?

Pour un outil sans paramètre avec un schéma de sortie, la description est complète : elle explique le quoi, le pourquoi et le quand. Le schéma de sortie couvre certainement le format de retour, donc la description n'a pas besoin de le préciser.

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?

Aucun paramètre n'existe dans le schéma, donc le score de base est 4. La description n'a pas besoin d'expliquer des paramètres, mais elle clarifie la finalité de la sortie, ce qui aide indirectement à comprendre l'usage.

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?

La description indique clairement l'action (« Restitue ») et la ressource (« Référentiel exhaustif des codes juridictionnels »), en précisant le contenu exact (51 instances, types de juridictions). Elle se distingue des outils de recherche car il s'agit d'une liste de référence, et non d'un outil de recherche ou de récupération.

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?

La phrase « Consulter impérativement cette liste pour déterminer le code exact à fournir à l'outil search_admin » donne une directive explicite d'utilisation et mentionne le cas d'usage principal. Elle précise également l'outil alternatif concerné, ce qui guide l'agent dans le choix.

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

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

Annotations only declare readOnlyHint=true, but the description adds valuable context: it specifies the output structure (including error case), gives concrete resolution examples, and explains the acceptable input format. No contradiction exists, and the behavioral expectations are fully disclosed.

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 with a clear purpose, usage context, examples, and argument/return sections. Every sentence serves a purpose and the content is front-loaded with the core function. No redundancy or fluff.

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?

Despite having an output schema, the description still provides a clear return shape and error behavior. It fully explains the tool's role within the broader set of siblings, its input constraints, and its output semantics. This is a complete description for this tool's complexity.

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% and the parameter is simply a string. The description compensates fully by specifying the exact format ('YY-NNNN' ou 'YYYY-NNNN'), providing examples, and explaining the meaning of the resolved identifier. This adds essential 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 tool's function with a specific verb and resource: 'Résout un numéro de loi/ordonnance/décret vers son identifiant LEGITEXT ou JORFTEXT Légifrance.' It distinguishes itself from sibling tools like get_law_article (which retrieves an article) and search_legi (which is a search tool) by focusing on resolving a number to an identifier.

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 explicitly states when to use this tool: for non-codified texts not covered by short codes, and how to chain it with get_law_article once resolved. This provides clear context vs alternatives and a concrete workflow.

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

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

Details BM25 algorithm, FTS5 syntax, source (JADE DILA, ~550k decisions), and important behavioral nuance: searching by 7-digit case number finds citations, not the decision itself. Return format with BM25 extracts is described. Annotations already declare readOnlyHint, so description adds value beyond that.

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?

Well-structured with main paragraph, warning note, and parameter list. Front-loaded with purpose. Slightly verbose in the warning about case number but still efficient. Every sentence adds value.

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 7 parameters, no schema descriptions, and output schema exists, the description covers source, scope, sorting, parameter details, return format, and usage pitfalls. Completely adequate for an agent to understand 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 0%, but the description provides thorough explanations for all 7 parameters: query (FTS5 operators), juridiction (filter by fragment, example), sort (relevance vs date), date bounds (ISO format), limit (default 20, max 50), offset. Adds critical meaning beyond the bare 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?

Clearly states it performs BM25 relevance-weighted search on complete administrative case law (Conseil d'État, Tribunal des conflits, 9 CAA, 40 TA). Explicitly distinguishes from date-sorted sibling tools like search_admin_recent*.

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 explicit when-to-use (semantic search by keywords) and when-not-to-use (case number lookup, redirecting to get_admin_decision). Also contrasts with date-sorted siblings, giving clear context for tool selection.

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

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

Beyond the readOnlyHint annotation, the description reveals that results are sorted by read date descending, the API is live, the coverage is since ~2022, and generated IDs are compatible with get_decision_text. It also discloses the edge case where isolated 'TA' or 'CAA' codes return empty results. This significantly exceeds annotation-only context.

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 moderately lengthy but well-structured with a bold summary, usage guidance, scope, compatibility note, and an Args section. Some redundancy exists between the opening line and the explanation of date sorting, but overall every section earns its place and the structured format improves scannability.

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 three parameters, an output schema, and a readOnly annotation. The description fully covers all parameters, provides explicit use cases and exclusions, describes the scope and sorting behavior, and includes a compatibility note with get_decision_text. With an output schema present, the description does not need to explain return values, and it provides comprehensive context to guide correct 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 input schema provides only names/types/defaults with no descriptions. The description compensates by explaining the query semantics, providing detailed juridiction code examples (CE, CE-CAA, TA69, TA75, CAA69), noting the empty-result edge case, and clarifying the default for limit. This adds substantial 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 tool searches recent administrative decisions sorted chronologically via a live API. It explicitly distinguishes it from search_admin by noting the focus on 'actualité' rather than relevance, and specifies the scope and ID formats. This leaves no ambiguity about what the tool does.

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 explicitly states when to use the tool (for recent decisions of a jurisdiction) and when not (for finding relevant jurisprudence), naming search_admin as the alternative. It also provides detailed examples for the juridiction parameter and warns about empty results for isolated TA/CAA codes, with a pointer to list_juridictions for full nomenclature.

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

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

Annotations only provide readOnlyHint=true. The description adds valuable behavioral details: simultaneous querying, merging, chronological sorting by reading date, and limit behavior (per-court default 5, total limit cap). No contradictions with 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 appropriately sized, with a clear two-sentence overview followed by a structured Args section. Every sentence adds value and there is no redundancy.

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 description covers the tool's core behavior and parameters; an output schema exists, so return values need not be explained. It is complete for a search tool, though it lacks explicit notes on edge cases or prerequisites beyond what the schema implies.

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 fully compensate. It explains all three parameters (query, limit_per_court, total_limit) with meaningful context, including defaults and the meaning of total_limit=0, going well beyond the bare 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 performs a simultaneous query of all 9 Cours Administratives d'Appel, with fusion and chronological sorting. This specific verb+resource distinguishes it from siblings like search_admin_recent and search_admin_recent_all_ta.

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 clearly conveys the context: use this tool to search across all 9 CAA simultaneously. It does not explicitly name alternative tools or exclusions, but the context is unambiguous given the sibling list.

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

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

The description explains behavior beyond the readOnlyHint annotation: it reveals that results are merged and sorted by decreasing date, explains the effect of total_limit (truncation to N most recent entries), and states that the return dict includes per_court_totals, decisions, and errors. This provides substantial context for expected behavior without contradicting 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 well-structured: a one-sentence summary, a fusion/sorting explanation, a use-case statement, and clearly separated Args/Returns sections. Every sentence contributes new information with no fluff, making it appropriately concise for the complexity.

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 description covers the tool's complete behavior: scope (all 40 TAs), sorting, parameter semantics, limit interactions, and return structure. The mention of 'eventuelles errors' addresses error handling. Despite having an output schema, the description adds enough context to fully understand the tool's operation.

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?

Despite 0% schema description coverage, the description dedicates an Args section to fully explain query, limit_per_court (default 5, up to 200 results before total_limit), and total_limit (default 60, 0 = no cap). This adds critical meaning that the schema's bare titles lack.

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 and resource: 'Requête simultanée de l'ensemble des 40 Tribunaux Administratifs' (simultaneous query of all 40 administrative tribunals), clearly distinguishing it from sibling tools like search_admin_recent_all_caa. It also explains the fusion and chronological sorting, making its function 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?

The description states a clear intended use case: 'Pertinent pour cartographier rapidement les éventuelles divergences d'appréciation territoriale sur une même question de droit' (useful for quickly mapping potential territorial divergences in legal interpretation). It does not explicitly list alternatives or exclusions, but the context strongly implies when to use this tool over general search_admin.

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

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

Beyond the readOnlyHint annotation, the description richly discloses behavior: BM25 scoring with authority bonus (CE/Cass/CEDH > CAA > TA/CA), parallel querying of sources, per-source result counts, error handling via source_errors and warning, and truncation with note. This gives the agent a clear model of how the tool behaves in edge cases.

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: a one-line purpose, a short usage hint, then clear Args and Returns sections. It front-loads the key value proposition, and every sentence earns its place given the tool's complexity (7 params, multi-source, error handling). No filler or repetition.

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 complexity and that the output schema exists, the description is complete: it covers purpose, when to use, all parameter semantics, return structure, and edge cases (source failures, truncation). The output schema handles raw return types, while the description explains the meaning of fields like per_source_counts and warning.

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 JSON schema has zero descriptions for its parameters, so the description carries the full burden. It thoroughly explains each of the 7 parameters: query semantics with thesaurus expansion example, sources allowed values, sort options, date format, limit default/max and per-source cap, and expand_synonyms behavior. It also documents defaults and the meaning of return fields, going well 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 explicitly states the tool performs a federated, relevance-weighted search across all sources, and positions it as a 'ONE-STOP' tool when the user doesn't know where to search. It lists the exact sources (DILA judic, JADE admin, LEGI, CEDH, CJUE) and describes the merged output, clearly distinguishing it from sibling source-specific search tools.

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 clearly indicates when to use this tool: 'Tool ONE-STOP quand on ne sait pas où chercher' (when you don't know where to search). It implies that source-specific tools should be used when the target source is known, but it does not explicitly name alternatives or provide explicit exclusion criteria, so it falls just 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.

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

Beyond the readOnlyHint annotation, the description discloses the aggregation of multiple data sources, the alpha status with no BM25 ranking, the simple relevance ordering (mail > organisme > service), and the full traceability fields for PDF-sourced entries. It even mentions licensing and the need to cite archived copies if originals disappear. This is exemplary transparency with 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 well-structured with a one-line purpose, a bulleted list of sources, search behavior, parameter details, and return format. It is dense with no filler, and the sections are clearly separated. The minor '3 vs 4 sources' inconsistency does not harm conciseness.

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 description covers everything needed to invoke the tool correctly: purpose, data sources, search semantics, all parameters, and the complete return structure, including special fields for scraped PDF entries. It also notes the alpha status and ranking limitation. No significant gaps remain for this complexity level.

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%, but the description fully compensates with an 'Args' section that explains each parameter with concrete examples and constraints, including default and max for limit, allowed category and source values, and keyword examples for query. This far exceeds what the schema 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 opens with a specific verb and resource: 'Recherche dans l'annuaire agrégé des adresses électroniques publiques des juridictions et administrations françaises.' It clearly distinguishes itself from sibling legal-document search tools by focusing on public email addresses. The only minor flaw is the '3 sources' label followed by 4 bullets, but this does not obscure the purpose.

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 clear context about the tool's domain and search behavior, such as 'Recherche : substring case-insensitive sur mail, organisme et service' and practical query examples. However, it does not explicitly state when not to use it or compare it to alternative tools, so it falls 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.

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

Annotations declare readOnlyHint=true, and the description adds substantial behavioral context: it covers the number of decisions, the nature filter options and their meanings, the use of FTS5 operators in query, and the return object structure. It does not mention rate limits or authentication, but these are not critical for a read-only 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 description is well-structured with clear sections for Args and Returns, and it is appropriately sized for the tool's complexity. The contextual sentence about the court is useful but slightly extends beyond the core purpose, though it does not become wasteful.

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 tool with 6 parameters (1 required) and a read-only annotation, the description covers all parameter meanings, defaults, constraints (limit max 50), and the response structure. No significant gaps remain, making it fully self-contained.

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 input schema has no descriptions (0% coverage), and the description fully compensates by explaining every parameter: query keywords with FTS5, nature with an enumerated list of values, date range format, limit max/default, and offset for pagination. This transforms the schema from bare names to actionable parameter semantics.

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 'Recherche dédiée au Conseil constitutionnel (7 112 décisions)' as the first sentence, immediately identifying it as a search tool specific to French Constitutional Council decisions. It distinguishes from sibling tools by naming the court and explaining its role, making the purpose 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?

The description provides clear context about when to use this tool: for searching decisions of the Constitutional Council, including constitutional review and election disputes. It does not explicitly mention alternatives or exclusions, but the dedicated scope implied by the description and sibling tool names gives sufficient guidance.

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

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

Beyond the readOnlyHint annotation, the description discloses pagination behavior (truncated/next_offset), dataset size, and access conditions (free access, local index). This provides actionable information for the agent to correctly handle large result sets.

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 concise and well-structured, starting with a clear purpose statement, followed by context about the index, and ending with a clear Args list. Each sentence adds value without redundancy.

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 moderate complexity and the presence of an output schema, the description covers all essential aspects: scope, parameters, pagination, and access. No critical gaps are apparent.

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 provides no descriptions for parameters (0% coverage). The description fully compensates by explaining query keywords with examples, limit default/max, and offset's role in pagination, including the use of next_offset.

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 performs textual search in the case law of the European Court of Human Rights, specifying the resource (~76,000 HUDOC French-language documents). The name and description distinguish it from sibling search tools targeting other jurisdictions (e.g., search_cc, search_cjue).

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 clear context for when to use this tool (for ECHR case law) and gives example queries ('article 8 vie familiale', 'garde à vue'). However, it does not explicitly mention alternatives or when not to use it, unlike the TDQS 4.3 example which names a specific alternative.

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

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

While the readOnlyHint annotation already indicates a safe read operation, the description adds useful behavioral details: pagination via offset/next_offset, truncation handling, and the note about free access. It does not mention any rate limits or additional side effects, but the core search behavior is transparent.

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 efficiently structured: a one-line purpose, a coverage note, a free-access note, and a clear Args list. Every sentence contributes necessary information, and the format is scannable.

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 search tool with an output schema, the description covers the essential aspects: scope, query syntax, result limits, and pagination behavior. It even anticipates the truncated response and next_offset, making it self-sufficient for an agent.

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?

With 0% schema description coverage, the description fully compensates by explaining each parameter: query with examples, limit with default and maximum, and offset with pagination logic. This adds meaning far beyond the bare schema types.

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 states 'Recherche textuelle dans la jurisprudence de la Cour de justice de l'Union européenne', clearly identifying the tool as a text search over CJEU case law. It further specifies coverage (CJEU, General Court, orders, AG opinions) and distinguishes it from sibling search tools targeting other courts (e.g., CEDH, CC).

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 clear context: it searches a localized index of CJEU decisions and is free to access. It gives example queries ('CJUE C-72/24') implying intended use, but does not explicitly state when not to use it or mention alternative tools for retrieving a single decision.

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

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

Annotations declare readOnlyHint=true, which is consistent with the read-only 'Recherche' action. The description adds the source bulk size (~27,000 deliberations), giving some context about the corpus, but doesn't disclose other behaviors like pagination limits or result formatting. This is acceptable for a read-only search but lacks depth.

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 extremely concise: two sentences, with the purpose front-loaded in the first sentence and supplementary context in the second. No unnecessary words or redundancy.

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 (search with query/limit/offset) and the presence of an output schema, the description covers the main purpose and usage context. However, it doesn't explain pagination behavior or any specifics about the return format, and the lack of parameter documentation leaves gaps, but not critical ones for a search 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 description coverage is 0%, and the description provides no parameter explanation. The agent must infer that 'query' is a search term, and 'limit'/'offset' are pagination controls, but these are not stated. The description adds no value beyond the parameter names 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 the tool searches CNIL deliberations, with a specific verb and resource. It distinguishes itself from the many sibling search tools by explicitly targeting CNIL deliberations, a unique jurisdiction/topic.

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 useful context: 'Utile pour le droit des données personnelles, RGPD, traitements algorithmiques' indicates when to use it. It doesn't explicitly mention alternatives or when not to use, but the context is clear enough for the agent to choose this tool for CNIL-related searches.

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

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

Annotations already indicate readOnlyHint=true. The description adds significant behavioral context: the engine uses Sinequa with context extraction, IDs are now usable by get_decision_text, coverage limitations, and query behavior (full sentences return zero results). This goes well beyond what annotations alone provide.

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 relatively long but well-structured with bold text, emojis, and sections. Every sentence adds value (purpose, usage, caveats, parameters). It could be slightly more concise, but the detail is justified given the need to cover multiple important aspects.

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 tool with 3 parameters, an output schema (existence signaled by context), and many sibling tools, the description comprehensively covers purpose, usage context, coverage limitations, parameter semantics, and alternatives. The presence of an output schema means return value details are handled separately, so the description is complete for the agent's decision-making.

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?

Despite 0% schema description coverage, the description includes an 'Args' section that explains each parameter: query with examples, limit with default, offset with pagination instructions. This fully compensates for the schema's lack of parameter descriptions.

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 performs 'Recherche sémantique ciblée sur la jurisprudence du Conseil d’État' (semantic search on Conseil d'État case law), naming the database (ArianeWeb, ~270k decisions). It distinguishes from siblings by stating it should be systematically preferred for public law and by explicitly contrasting coverage with search_admin and get_decision_text.

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 explicitly advises when to use this tool ('À privilégier systématiquement pour le droit public') and when not to (for old decisions before ~1990, directing to search_admin). It also provides an alternative if the user already has a Légifrance ID, and gives search query constraints (2-5 keywords, avoid full sentences).

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

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

Beyond the readOnlyHint annotation, the description discloses concrete behavior: it exploits FTS5, matches common citation formulations, and explains failure behavior (source outages are absent from per_source and listed in source_errors). It also documents what the tool does NOT capture, which is critical for managing expectations.

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: a clear opening purpose, a bolded limitation section, organized Args, and a Returns dictionary. It is longer than average but every part provides necessary operational detail, and the structure makes it easy to scan.

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 complexity, the description is complete: it covers purpose, usage, parameters, return format, limits, and failure modes. The output schema is indicated as present, and the Returns section in the description nicely complements it. No critical information is missing.

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?

With 0% schema description coverage, the description compensates fully. It explains each parameter: code with examples ('CT', 'CC'), num with examples ('L1152-1', '1240'), sources with allowed values and default, and limit with default and maximum. This is far beyond the bare 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 opens with a specific verb and resource: 'Cherche les décisions qui citent EXPLICITEMENT un article de loi donné.' It clearly distinguishes itself from siblings by emphasizing the inverse cross-referencing approach and explicitly contrasting with search_all for conceptual searches.

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 tool states when to use it (explicit citation lookup) and when not to use it, directing users to search_all with thesaurus expansion for conceptual queries. It also documents the known limitation, giving clear decision criteria for tool selection.

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

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

Annotations declare readOnlyHint=true, so safety is already covered. The description adds valuable behavioral details: source (bulk JORF DILA, 1.1 GB), content type (non-codified), and a hard limit on results ('limit: max 50'). This enriches understanding beyond the annotation alone.

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 concise and well-structured with an Args list and Returns line. Every sentence adds information without redundancy. It is easy to scan and understand.

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 description covers purpose, source, content, all key parameters, and the return structure. Given that an output schema exists, the explicit 'Returns' line is a bonus. It is sufficiently complete for 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 coverage is 0%, so the description carries the burden. It explains query (FTS5 keywords), nature (with examples), date_min/date_max (ISO), and limit (max 50). Offset is not mentioned, but it is a common pagination parameter and has a default, so the description compensates well for most parameters.

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 function: 'Recherche dans le Journal officiel (JORF post-1990)'. It specifies the resource (JORF), the action (search), and the scope (post-1990) while listing content types (lois, décrets, arrêtés, circulaires, ordonnances). This distinguishes it from sibling tools like search_legi or search_admin.

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 clear context on what the tool searches (non-codified JORF texts) and the available filters (nature, date range). It does not explicitly name alternatives or say when not to use it, but the scope is unambiguous enough to guide selection.

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

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

Although readOnlyHint=true already signals a safe read operation, the description adds substantial behavioral context: OAuth2 authentication is required, credentials never pass through the conversation, and there is an external technical constraint ('entrave technique'). It also details two authentication paths, which is valuable 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 longer than average but well-structured with sections for scope, usage guidance, authentication, and parameters. Each sentence contributes necessary information, especially given the authentication complexity. Slight verbosity is justified, though it could be tightened.

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 complexity, the presence of an output schema, and readOnlyHint annotation, the description is complete. It covers purpose, scope, usage conditions, authentication steps, parameter semantics, and even mentions alternatives. There are no significant gaps.

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 carries full responsibility for explaining the parameters. It provides meaningful semantic meaning for each argument: query (keywords), session_token (temporary token obtained via the site), juridiction (with specific code mappings), and limit (default 20, max 50). This fully compensates for the bare 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 performs a search in judicial case law (jurisprudence judiciaire) via the official PISTE API, with an explicit scope listing the covered courts. It also distinguishes itself from the free DILA base and from sibling tools like search_judiciaire_libre by emphasizing it is a last-resort option for recent decisions.

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 usage guidance: use only as a last resort or for recent decisions missing from the DILA free base. It also mentions the technical hurdles imposed by the Cour de cassation, which helps the agent decide when this tool is appropriate versus alternatives.

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

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

The description goes far beyond the readOnlyHint annotation. It discloses that results contain only a truncated snippet (not full text), warns not to conclude based on snippets, explains the indexing source (FTS5 on DILA public archives updated daily via Judilibre), lists known coverage limitations (e.g., missing decisions, specific year ranges), and describes pagination behavior ('truncated: true' with 'next_offset'). It also details how to retrieve full decisions via 'get_decision_judiciaire_libre' with the returned id, providing complete behavioral context for a search 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?

The description is comprehensive yet well-structured. It opens with a clear one-line purpose statement, then progressively adds detail: indexing source and coverage, search strategies, limitation warnings, parameter explanations. Each sentence serves a distinct informative purpose—no redundancy or filler. The parameter list is cleanly formatted, and critical caveats are highlighted with emoji markers for scannability.

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 complexity (7 parameters, no required fields, large parameter space, FTS5 search engine, pagination, multiple result types), the description is remarkably complete. It addresses: search scope and limitations, parameter semantics, result behavior (pagination, snippets), error recovery suggestions (what to do when no results), and integration with sibling tools ('get_decision_judiciaire_libre'). The output schema exists but the description still usefully explains return values like 'snippet', 'truncated', and 'next_offset'. Nothing obvious is missing.

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?

Despite 0% schema description coverage (meaning the schema only provides parameter names and types), the description thoroughly documents every parameter. It explains: query supports FTS5 syntax (exact phrases, AND, prefix), juridiction lists valid values, numero_rg normalizes typographical variations, date_min/date_max expect ISO format, limit defaults to 20 with max 50, and offset paginates with next_offset. The description adds substantial meaning beyond the bare 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 opens with 'Recherche plein texte dans la jurisprudence judiciaire, exécutée localement et affranchie de toute obligation d'authentification gouvernementale,' clearly specifying the verb (full-text search), resource (French judicial case law), and a key differentiator (no government authentication required). It further distinguishes itself from siblings like 'search_judiciaire' which requires government authentication, and provides scope details about coverage and 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 gives explicit when-to-use guidance: it is for searching judicial case law without authentication. It also provides when-not-to-use guidance: if the search is fruitless, suggest using 'search_judiciaire' (PISTE) or Légifrance. Additionally, it specifies search strategies for different document types (e.g., using 'numero_rg' for CA cases, 'query' for Cassation appeals), directly helping the agent choose correct invocation paths.

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

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

Annotations only provide readOnlyHint, and the description adds valuable context about the data source size, coverage, and IDCC identification. This goes beyond the annotation's safety hint, though it doesn't detail result ordering or pagination behavior.

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 and well-organized, with a clear purpose first, then source context, then parameter guidance. Every sentence is informative, no fluff.

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 description covers purpose, source, relevant parameters, and includes limit constraints. It lacks explicit mention of offset and doesn't differentiate from siblings beyond domain, but overall is sufficiently complete for a search tool with an output 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?

With schema description coverage at 0%, the description compensates by explaining query, idcc (with a concrete example), and limit (max 50). It omits offset, a minor gap, but otherwise adds meaningful semantic detail 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 searches collective agreements (KALI), specifying the resource type, source (bulk KALI DILA), and coverage. The verb 'Recherche' and the specific domain distinguish it from sibling search tools.

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 clear context on what is searched (national collective agreements, branch agreements, riders, identified by IDCC), implying when to use it. However, it does not explicitly mention alternatives or exclusions, so it falls short of a full 5.

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

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

Beyond the readOnlyHint annotation, the description adds substantial behavioral context: the source (bulk LEGI DILA with historical versions), the FTS5 matching mechanism, limit max 50, pagination, and the exact return structure. This gives the agent a clear picture of what happens during the call without contradicting 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 well-structured with a purpose sentence, source context, matching criteria, then clearly labeled Args and Returns sections. Every sentence provides valuable information without redundancy, and the format is easy to scan.

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 6-parameter search tool with no schema descriptions, the description is remarkably complete: it covers all parameters, describes the return object, notes the maximum limit, and explains the source and scope. This is sufficient for an agent to 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?

With 0% schema description coverage, the description fully compensates by explaining each parameter: query (FTS5 keywords), code (optional filter with examples), date_min/date_max (version start date, ISO), limit (max 50), and offset (pagination). This adds essential meaning beyond the schema's bare titles.

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 performs a weighted search in consolidated French codes and laws (LEGI), specifically finding articles whose text or title contains keywords. This specific verb+resource+scope distinguishes it from sibling search tools like search_jorf or search_kali.

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 clear context: it searches consolidated codes/laws from LEGI, which implies when to use it versus other search tools. However, it does not explicitly name alternatives or state when not to use it, so it falls 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.