justicelibre

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

No annotations provided, so description carries the burden. It implies read-only behavior by offering an overview. However, it does not explicitly state side effects or non-destructive nature. Adequate but not detailed.

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

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

Two sentences with front-loaded purpose. Clear and efficient. Minor redundancy but overall well-structured.

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

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

Given the many sibling tools, this description provides essential context by positioning itself as the first tool to call. It covers key aspects (compatibility, search scopes, database specifics) but could mention output schema details.

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?

Tool has zero parameters, so schema coverage is 100% and no additional parameter info needed. Description adds value by explaining what the tool returns without needing to elaborate on params.

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 provides an overview of the JusticeLibre protocol, including source mapping and routing rules. It distinguishes itself from sibling tools as an introductory meta-tool.

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 to call this tool first ('Appeler cet outil en priorité') to understand compatibility matrices, search perimeters, and database specifics. This provides strong guidance on when to 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?

With no annotations, the description details behavior: it returns a URL or error, and explains identifier handling. It also notes the date parameter's critical role for historical lookups, adding 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 well-structured with bullet points and sections. It front-loads the purpose and every sentence adds value, balancing detail with readability.

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 output schema exists, the description covers return values, parameters, and use cases completely. No 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?

Schema coverage is 0%, but the description thoroughly explains each parameter: identifier formats, legitext for precision, and date format/purpose. This adds significant 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 it constructs canonical URLs from identifiers, listing specific identifier formats and their sources. This distinguishes it from sibling tools which focus on fetching decisions or searching.

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

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

The description explains when to use it (manual verification, clickable links) and provides guidance on optional parameters. While it doesn't explicitly state when not to use it, the context implies its unique purpose.

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?

With no annotations, the description fully discloses behavioral traits: exact SQL lookup, no false positives, disambiguation requirement for 7-digit numbers, return format (decision metadata or error). This adds significant value beyond structured fields.

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 somewhat lengthy but well-structured with Args, Returns, and Examples sections. It is front-loaded with purpose and warnings. Every sentence adds value, but a slightly more concise version might be possible without losing clarity.

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

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

Given 2 parameters, 0% schema coverage, no annotations, but an output schema exists, the description is very complete. It covers parameter details, return format, examples, and important disambiguation warnings. The output schema reduces need for return explanation, but the description still provides a brief overview.

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%, but the description compensates thoroughly. Explains both parameters: numero (required, example format) and juridiction (optional but recommended, with two accepted formats and ambiguity notes). Provides examples and edge cases, making the semantics very clear.

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 retrieves an administrative decision by exact request number, covering all jurisdictions (Conseil d'État, CAA, TA). It distinguishes itself from sibling tools like get_ce_decision by being a unified lookup across all admin courts.

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 clear context on when to use the juridiction parameter (recommended for 7-digit numbers) and when it's unnecessary (for Conseil d'État numbers with no duplicates). Includes examples and warnings about ambiguity. Does not explicitly list alternatives among siblings.

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?

With no annotations provided, the description carries the full burden and does well by explaining the search behavior ('Recherche full-text sur le numéro + filtre juridiction="Conseil constitutionnel"'), data source ('dans judiciaire.db'), and return format (including the possibility of 'None'). It does not mention error handling or performance limits, but covers key operational aspects.

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 front-loaded with the core purpose, followed by format details, behavior, parameters, and return value. Every sentence adds value without redundancy, making it efficient and easy to parse.

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 (2 parameters, no annotations, but has output schema), the description is complete. It explains the purpose, usage, behavior, parameters, and return format, with the output schema handling return value details. No significant gaps remain for effective tool invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It adds significant meaning beyond the schema by explaining the expected format for 'numero' (with examples like '79-105 DC'), clarifying that 'nature' is optional with examples (QPC, DC, L), and referencing search_cc for more details. This effectively documents both 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 specific action ('Récupère une décision du Conseil constitutionnel') and resource ('par son numéro'), distinguishing it from sibling tools like search_cc by focusing on retrieval by identifier rather than broader search. The French phrasing is precise and 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 for when to use this tool (retrieval by decision number) and references an alternative ('cf search_cc'), but does not explicitly state when not to use it or compare it to other sibling tools like get_decision_judiciaire. The guidance is helpful but not exhaustive.

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?

Aucune annotation n'est fournie, donc la description porte l'entière responsabilité. Elle divulgue le comportement séquentiel (d'abord JADE DILA, puis ArianeWeb Sinequa) et le retour None si introuvable. Elle ne mentionne pas d'effets de bord ni d'autorisations, mais pour une opération de lecture, c'est suffisant.

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?

La description est concise, bien structurée avec une phrase d'objectif, une phrase de stratégie, une mention d'alternative, une section Args et Returns. Chaque phrase apporte une information utile sans longueur inutile.

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?

Compte tenu de la complexité (deux bases de données, repli) et de l'existence d'un schéma de sortie, la description couvre les aspects essentiels. Elle pourrait mentionner explicitement que l'outil est réservé au Conseil d'État, mais cela est évident. Elle est suffisamment complète pour une utilisation par un 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?

Le seul paramètre 'numero' est documenté par un exemple ('497566', '358109'), ce qui clarifie le format. La couverture du schéma est de 0% (aucune description dans le schéma), donc la description ajoute une valeur de base. Cependant, elle ne spécifie pas de contraintes de longueur ou de motif, ce qui est acceptable pour un simple string.

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 qu'elle récupère une décision du Conseil d'État par numéro de pourvoi, avec un verbe d'action spécifique et une ressource claire. Elle se distingue de l'outil frère get_decision_text qui utilise un identifiant DCE_*, donc différenciation des outils.

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 description fournit des instructions explicites sur quand utiliser cet outil (numéro de pourvoi) et quand utiliser l'alternative get_decision_text (identifiant DCE_*). Elle décrit également la stratégie de repli entre deux bases de données, ce qui aide l'agent à comprendre les cas d'échec.

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?

No annotations are provided, so the description carries the full burden. It states it extracts full text, but lacks details on error handling, permissions, or limitations. For a simple retrieval operation, this is acceptable but not exemplary.

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 front-loads the purpose. However, the Args section could be formatted more clearly (e.g., as bullet points). Overall, 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 the tool's simplicity (1 parameter, output schema available), the description is fairly complete. It explains the input and core function. It does not explain output, but the output schema handles that.

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

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

Schema description coverage is 0%, so the description compensates well by explaining the parameter decision_id as 'itemid HUDOC' with an example ('001-249914'). This adds crucial context beyond the minimal schema title.

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 full text of a decision from the European Court of Human Rights using a system identifier (itemid HUDOC). This specific verb and resource differentiate it from sibling tools like get_decision_cjue or get_decision_judiciaire.

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 when to use the tool: when you have a HUDOC itemid. It also provides an example format, aiding the agent in decision-making. However, it does not explicitly state when not to use it or mention 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?

No annotations are provided, so the description carries the full burden. It does not explicitly state that the tool is read-only or disclose error handling, rate limits, or authentication needs. The term 'extraction' implies retrieval, but more explicit behavioral information would be beneficial.

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 that front-load the purpose and then define the parameter. Every word is essential, and no extraneous information is present.

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 (one parameter, no annotations, and an output schema), the description is complete. It explains what the tool does and how to use the parameter, while the output schema handles return value details.

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%, yet the description compensates fully by explaining the parameter 'decision_id' as a CELEX identifier with format and example. This adds significant meaning beyond the schema's minimal 'Decision Id' title.

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 decision from the Court of Justice of the European Union using a normalized identifier. It specifies the resource (CJEU decisions) and action (extraction), and distinguishes from sibling tools targeting other courts or search functions.

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 the tool: when you have a CELEX or ECLI identifier. It gives example identifiers, but does not explicitly mention alternatives or when not to use it. This is adequate for a simple 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?

With no annotations, description must disclose behavior. It mentions authentication requirement and restricted nature, but lacks details on side effects, error handling, or rate limits. Adequate but not comprehensive.

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: purpose sentence, usage guidance, inoperable cases, then parameter list. Slightly verbose but functional. No wasted sentences.

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 presence of output schema, description covers purpose, authentication, parameter semantics, and usage alternatives. Missing error scenarios but otherwise sufficient for selection and invocation.

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

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

Schema description coverage is 0%, so description carries burden. The Args section adds brief meanings for each parameter, clarifying role (e.g., 'temporary token recommended'). However, descriptions are minimal and could be more precise.

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 extracts full text of judicial decisions via the restricted PISTE API with OAuth2. Differentiates from sibling tool by specifying when to substitute.

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?

Explicitly tells when to use this tool vs get_decision_judiciaire_libre, and declares inoperability for administrative decision formats. Provides clear context for correct 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool requires no authentication, only accepts specific identifier formats, and is inoperative for administrative decisions, which is a critical behavioral constraint.

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 but well-structured with clear sections. Each sentence adds value, and the use of bullet-like lists improves readability. Could be slightly trimmed but remains efficient.

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

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

Given the presence of an output schema, the description does not need to explain return values. It provides complete context on input constraints, identifier origins, and exclusions. Minor missing details on potential error cases, but overall adequate.

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

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

The single parameter decision_id is documented with accepted formats and examples (JURITEXT, CONSTEXT, JURI), adding significant meaning beyond the schema alone, which had 0% coverage. This compensates well.

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 judicial decisions from an independent index, specifies accepted identifier formats (JURITEXT*, CONSTEXT*, JURI*), and distinguishes it from siblings like get_admin_decision by explicitly stating it is inoperative for administrative 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 explicitly states when to use (for libre decisions) and when not (administrative orders). It also references search_judiciaire_libre as the source for identifiers, providing good context, though alternative tools for administrative decisions are not named.

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?

With no annotations, the description carries full burden. It explains the tool returns full text and metadata, and for certain identifiers uses direct plugin retrieval. It lacks an explicit read-only hint but implies 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?

Well-structured with sections for accepted identifiers, incompatibilities, args, and returns. Slightly verbose but front-loaded and organized.

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 tool with an output schema, the description explains return values (metadata, text_segments, full_text) and potential None result. No gaps given the 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 has 0% coverage on the single parameter. The description compensates fully by detailing accepted identifier formats (DCE, DTA, DCAA, CETATEXT, ArianeWeb patterns).

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 administrative court decisions (Conseil d'État, TA, CAA). It lists accepted identifier formats and distinguishes from sibling tools via incompatibilities.

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?

Explicitly lists acceptable identifier formats and provides incompatibilities with redirections to get_decision_judiciaire_libre, get_decision_judiciaire, get_decision_cjue, and get_decision_cedh, guiding when to use 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?

With no annotations provided, the description carries full burden and does well. It explains the key behavioral trait: retrieving historical versions rather than current law (the 'Particularité justicelibre'). It also mentions the 22 supported codes and what happens when date is empty (current version). It doesn't cover rate limits, authentication needs, or error conditions, but provides substantial operational 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 appropriately sized and front-loaded with the core purpose. The 'Particularité justicelibre' paragraph adds crucial context. The 'Args' and 'Returns' sections are well-structured but could be more integrated. Every sentence earns its place, though the French/English mix slightly affects readability for English-only agents.

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 (historical law retrieval), no annotations, 0% schema coverage, but with an output schema, the description is remarkably complete. It explains the purpose, historical context, parameters with examples, supported codes, and return structure. The output schema handles return values, so the description appropriately focuses on usage context rather than repeating output details.

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 description adds significant meaning beyond the 0% schema coverage. It explains what each parameter represents with examples: 'code' as short codes for different legal codes, 'num' as article numbers with format examples, and 'date' as ISO format with guidance on using the citing decision's date. The 'Args' section provides concrete usage guidance that the schema titles ('Num', 'Code', 'Date') lack entirely.

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: 'Renvoie le texte d'un article de loi à une date donnée' (Returns the text of a law article at a given date). It specifies the exact action (return text) and resource (law article), and distinguishes itself from potential siblings by explaining the 'Particularité justicelibre' about historical vs current versions, which is unique among law-related 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 for when to use this tool: to retrieve historical versions of law articles when analyzing past legal decisions. It explains that using the decision's date gives the contemporary version. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the historical focus implies it's not for current law lookups.

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?

With no annotations provided, the description carries full burden and does well by explaining the chronological ordering, return format structure, and practical use case. It doesn't mention rate limits, authentication needs, or error conditions, but provides substantial behavioral context for a read operation.

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?

Perfectly structured with purpose statement, usage context, example, parameter explanations, and return format - all in 4 focused sentences. Every sentence adds value and the information is front-loaded appropriately.

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 (historical version retrieval), no annotations, and the presence of an output schema, the description provides complete context: purpose, usage guidance, parameter semantics, return structure, and ordering behavior. The output schema handles return value details, so the description focuses on what's needed.

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 both parameters: 'code' is described as a short code with reference to sibling tool for valid values, and 'num' is clearly identified as the article number. The description adds essential 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 clearly states the tool's purpose with specific verbs ('renvoie toutes les versions historiques') and resources ('article de loi'), distinguishing it from siblings like get_law_article. It explicitly explains what historical versions are returned and their ordering.

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 guidance on when to use this tool ('utile pour construire une timeline...'), references a sibling tool for context ('voir get_law_article pour la liste des 22 codes'), and includes a concrete example of when it would return multiple versions.

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?

No annotations are provided, so the description carries the burden. It discloses that the tool outputs 51 instances with canonical nomenclature, which implies a read-only, non-destructive operation. However, it does not mention any potential limitations like caching or dynamic data updates.

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 plus a brief enumeration of jurisdictions. Every sentence adds value, and the main purpose is front-loaded. There is no redundancy or unnecessary information.

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

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

Given the tool has no parameters and has an output schema (not shown but indicated), the description fully covers the tool's purpose and output. It states the exact number of instances and their types, which is complete for a listing 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 input schema has zero parameters, so description adds no parameter information. According to the baseline rule for 0 parameters, a score of 4 is appropriate as no additional semantics are needed.

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 is a comprehensive reference of jurisdictional codes, listing the 51 instances covered (Conseil d'État, 9 CAA, 40 TA including overseas jurisdictions). It also explicitly connects to the sibling tool `search_admin`, distinguishing its 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 explicitly instructs users to consult this list before using `search_admin` to determine the exact code. While it provides clear context for when to use this tool, it does not explicitly mention when not to use it or other alternatives, though the sibling list implies its specificity.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it resolves a law number to an identifier, provides examples of inputs and outputs, specifies the return structure including success and error cases (`{error}` if not found), and mentions the source (`Légifrance`). However, it doesn't cover potential rate limits, authentication needs, or detailed error handling beyond the basic error return.

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 and front-loaded: the first sentence states the core purpose, followed by usage context, examples, and parameter/return details. Every sentence adds value—no wasted words—and it's structured logically from general to specific, making it 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?

Given the tool's moderate complexity (1 parameter, no annotations, but with an output schema), the description is complete enough. It covers purpose, usage, examples, parameter semantics, and return values. The output schema exists, so the description doesn't need to explain return types in detail, but it still summarizes the success and error structures adequately for context.

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 0% description coverage, so the description must compensate. It adds significant meaning: it explains the `numero` parameter as a law/ordinance/decree number in format 'YY-NNNN' or 'YYYY-NNNN', provides examples ('68-1250', '2000-321'), and clarifies it's for non-codified texts. This goes well beyond the schema's basic string type, though it doesn't detail validation rules or edge cases.

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: 'Résout un numéro de loi/ordonnance/décret vers son identifiant LEGITEXT ou JORFTEXT Légifrance.' It specifies the verb ('resolve'), resource ('law/ordinance/decree number'), and target ('LEGITEXT/JORFTEXT identifier'), and distinguishes it from sibling tools by noting it's for 'non-codified texts' not in the 'whitelist of 25 short codes' like those used by get_law_article.

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 guidance on when to use this tool: 'Utile pour les textes non codifiés (lois, ordonnances, décrets) qui ne sont pas dans la whitelist des 25 codes courts.' It also names an alternative usage pattern: once resolved, the identifier can be used with `get_law_article`. This clearly differentiates it from sibling tools that handle codified laws or other legal 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?

Discloses BM25 algorithm, source size (~550k decisions), and full-text indexing. No annotations provided, so description carries burden. Could mention pagination behavior but output schema covers return structure.

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 clear sections, bullet points, and warnings. No redundancy; 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?

Covers indexing, tool differentiation, all parameters with examples, return type, and edge case for number search. Complete given complexity and 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?

All 7 parameters are explained in detail with usage tips, FTS5 operators, date format, and defaults. Compensates for 0% schema description coverage.

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's a BM25 relevance-weighted search on full administrative jurisprudence, and distinguishes from date-sorted siblings 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?

Explicitly says to use this for relevance search vs date-sorted tools, and warns not to use for request number lookup, directing to get_admin_decision instead.

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?

With no annotations, the description carries full burden and does well: it explains sorting (chronological, not by relevance), scope (jurisdictions and time range), and output compatibility with 'get_decision_text'. It could improve by mentioning rate limits or authentication needs, but covers key behavioral aspects clearly.

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 and front-loaded: starts with core purpose, then usage guidelines, scope, and parameter details. Every sentence adds value, with no wasted words, making it efficient and easy to parse.

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 (search with jurisdiction filtering) and no annotations, the description is highly complete: it covers purpose, usage, behavior, and all parameters in detail. The presence of an output schema means return values don't need explanation, and sibling context is well-integrated.

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

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

Schema description coverage is 0%, so the description must compensate—and it does thoroughly. It explains all three parameters: 'query' as keywords, 'juridiction' with examples and warnings, and 'limit' with its default. This adds significant 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 clearly states the tool searches for recent administrative decisions sorted chronologically, distinguishing it from sibling tools like 'search_admin' which uses relevance ranking. It specifies the scope (CE + 9 CAA + 40 TA since ~2022) and mentions compatibility with '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?

Explicit guidance is provided: use for 'actualité d'une juridiction' but NOT for finding relevant jurisprudence on a topic—for that, use 'search_admin'. It also references 'list_juridictions' for complete jurisdiction codes and warns that isolated 'TA' or 'CAA' codes return empty results.

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?

With no annotations provided, the description carries full burden. It discloses key behavioral traits: simultaneous querying across multiple courts, merging of results, chronological sorting by date, and default pagination behavior (limit_per_court default 5, total_limit default 0). However, it doesn't mention authentication requirements, rate limits, error conditions, or what the output schema contains.

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 with a clear purpose statement followed by a well-formatted Args section. Every sentence earns its place: the first explains the core functionality, the second describes result processing, and the parameter explanations are concise yet informative. No wasted words.

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

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

Given the tool's moderate complexity (multi-court search with merging), no annotations, and the presence of an output schema, the description is reasonably complete. It covers purpose, usage context, parameter semantics, and key behaviors. The output schema existence means return values don't need explanation, but additional behavioral context (like error handling) would enhance completeness.

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

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

With 0% schema description coverage, the description compensates well by explaining all 3 parameters in the Args section. It clarifies that 'query' accepts keywords, 'limit_per_court' controls results per court with default 5, and 'total_limit' is a global cap after merging with default 0 meaning no limit. This adds meaningful context 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 across all 9 Administrative Courts of Appeal, merges results, and sorts them chronologically by reading date. It specifies the verb ('Requête simultanée'), resource ('9 Cours Administratives d'Appel'), and distinguishes from siblings like search_admin_recent (single court) or search_admin_recent_all_ta (different jurisdiction).

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 indicates this tool is for searching across all 9 courts simultaneously with merged results, distinguishing it from alternatives like search_admin_recent (single court) or search_admin_recent_all_ta (different court type). The context of 'simultaneous query' and 'fusion' provides clear when-to-use guidance versus single-court 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?

With no annotations provided, the description carries full burden and does well by disclosing key behaviors: it queries 40 courts simultaneously, merges and sorts results chronologically by descending date, handles errors with an errors field, and explains result limits (default 5 per court, up to 200 total without total_limit). It doesn't mention rate limits or authentication needs, but covers core operational traits adequately.

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 and front-loaded with the core purpose in the first sentence. The Args and Returns sections are clearly structured. Minor deduction because the French phrasing is slightly verbose in places, but every sentence earns its place by adding 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 the tool's complexity (querying 40 courts, merging, sorting), no annotations, and an output schema present, the description is complete. It explains the purpose, usage context, parameters, return structure (per_court_totals, decisions, errors), and behavioral details like chronological sorting and error handling. The output schema means return values don't need explanation here.

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 fully. It provides detailed semantics for all 3 parameters: 'query' as keywords, 'limit_per_court' with default 5 and implication of up to 200 total results, and 'total_limit' as global cap with 0 meaning unlimited and positive values truncating to most recent N entries. This 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 clearly states the tool performs a simultaneous query across all 40 Administrative Tribunals, merges and chronologically sorts results, and is relevant for mapping territorial divergences on legal questions. It specifies the verb ('Requête simultanée'), resource ('40 Tribunaux Administratifs'), and distinguishes from siblings like search_admin or search_admin_recent by covering all courts nationally.

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: 'Pertinent pour cartographier rapidement les éventuelles divergences d'appréciation territoriale sur une même question de droit.' This provides clear context for usage versus alternatives like search_admin (single court) or search_admin_recent (recent from unspecified scope).

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: parallel querying of multiple sources, BM25 scoring with authority bonuses, and thesaurus-based synonym expansion. It mentions default values and limits (max 100 results). However, it doesn't explicitly address rate limits, authentication requirements, or error conditions.

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 statement, usage guidance, and detailed parameter explanations. Every sentence adds value. It could be slightly more concise in the parameter section, but overall it's efficiently organized with zero wasted content.

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, federated search across multiple sources) and the presence of an output schema, the description provides excellent context. It explains the search methodology, scoring algorithm, source options, parameter behaviors, and return structure. The output schema handles return value documentation, allowing the description to focus on operational context.

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 providing detailed semantic explanations for all 7 parameters. It explains query expansion behavior with thesaurus synonyms, lists valid source options, describes sorting options, clarifies date format requirements, specifies default and maximum limits, and explains the expand_synonyms toggle. This adds substantial value 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 'Recherche fédérée pondérée par pertinence sur toutes les sources' (federated relevance-weighted search across all sources), specifying it queries multiple legal sources in parallel and returns merged results sorted by BM25 score with authority bonuses. It explicitly distinguishes this as the 'ONE-STOP' tool when unsure where to search, differentiating it from sibling tools that search specific sources like search_cedh or search_legi.

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 guidance: 'Tool ONE-STOP quand on ne sait pas où chercher' (when you don't know where to search). It contrasts this comprehensive search with sibling tools that target specific sources, giving clear context for when to use this broad-scope tool versus more targeted 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?

With no annotations provided, the description carries full burden and excels by disclosing key behavioral traits: it specifies the database size (7,112 decisions), mentions FTS5 operators for querying, explains pagination behavior (limit default 20, max 50, offset), describes the return format with field names, and clarifies that empty nature parameter returns all types. This goes well beyond basic functionality.

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 (introduction, args, returns) and uses bullet points for nature values. While comprehensive, it's appropriately sized for a complex tool with 6 parameters and no schema descriptions. Every sentence adds value, though the constitutional context paragraph could be slightly condensed.

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 complex search tool with 6 parameters, 0% schema coverage, no annotations, but with an output schema, the description is remarkably complete. It covers purpose, domain context, all parameter semantics, behavioral details (pagination, defaults, operators), and even previews the return structure. The output schema handles return values, so the description appropriately focuses on usage context.

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?

Given 0% schema description coverage, the description fully compensates by providing comprehensive parameter documentation: explains query accepts FTS5 operators, details all 10 possible values for nature with explanations of each, specifies date format (ISO YYYY-MM-DD), indicates limit range and default, and explains offset for pagination. This 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 clearly states the tool searches decisions from the French Constitutional Council (Conseil constitutionnel), specifying it covers 7,112 decisions. It distinguishes this from sibling tools by focusing exclusively on this specific judicial body, unlike other tools that search different jurisdictions (CEDH, CJUE, Conseil d'État, etc.) or broader searches (search_all).

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 by explaining the Constitutional Council's role in constitutional review and elections, which helps the agent understand the domain. However, it doesn't explicitly contrast when to use this versus sibling tools like search_all or search_judiciaire, nor does it mention any prerequisites or exclusions for 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?

No annotations provided. Description mentions free access and use of an index, but lacks details on query operators, case sensitivity, pagination, or other behavioral traits. The output schema exists but the description itself does not disclose response 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?

Description is concise with two short paragraphs. The main purpose is stated first, followed by an 'Args' section. No unnecessary information, though could slightly improve by front-loading the language scope.

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?

Covers purpose and parameters adequately given the output schema explains return values. However, lacks usage guidelines and behavioral details like whether it supports operators or limits. The language restriction to French is implied but not explicit.

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 0% but the 'Args' section in the description adds meaningful context: query is described as 'mots-clés' with examples, limit is explained as max results defaulting to 20. This 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?

Description clearly states the tool performs text search in European Court of Human Rights jurisprudence using a dedicated index of ~76,000 French-language HUDOC documents. This is distinct from sibling tools like search_cc (Constitutional Council) or search_admin (administrative courts).

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

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

No guidance on when to use this tool versus alternatives. Does not mention when not to use or provide comparison with other search tools in 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?

With no annotations, the description carries full burden for behavioral traits. It mentions free access and data source (EUR-Lex), but omits critical information such as whether the tool is read-only, rate limits, required authentication, or side effects. For a search operation, more transparency is expected.

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: two short paragraphs and a clear arg list. Every sentence adds value, and the purpose is front-loaded in the first sentence. No repetition or filler.

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

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

Given the existence of an output schema, return values are not needed. However, the description lacks crucial usage context like pagination, result ordering, boolean operators, or wildcard support. For a search tool, this leaves gaps in expected behavior.

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 add meaning. It explains 'query' as keywords with examples, and 'limit' as maximum results with a default of 20. This goes beyond the schema's bare titles, though it could provide more detail on valid ranges or syntax.

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 textual search within CJEU jurisprudence, specifying the exact resources (CJEU, Tribunal, orders, AG opinions) and using a specific verb ('Recherche textuelle'). It distinguishes from sibling tools like get_decision_cjue (which retrieves a single decision) and other jurisdiction-specific searches by naming the court and data source.

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 example queries but does not explicitly contrast with sibling tools like search_all or get_decision_cjue. Usage is implied by the court-specific focus, but there is no guidance on when not to use this tool or 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?

No annotations are provided, so the description carries full burden. It mentions the source data (bulk CNIL, 109 MB, ~26k deliberations), which adds useful context about scale and scope. However, it lacks details on behavioral traits such as rate limits, authentication needs, response format, or pagination behavior (though offset and limit parameters hint at pagination). This leaves significant gaps 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 appropriately sized with three concise sentences that are front-loaded: first stating the core function, then source details, and finally domain relevance. There's minimal waste, though the French text might require translation for some agents, slightly affecting clarity.

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

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

Given no annotations, 0% schema coverage, but an output schema exists, the description is moderately complete. It covers purpose and context well but lacks parameter explanations and behavioral details. The output schema likely handles return values, so that gap is mitigated, but overall it's adequate with clear omissions for a search tool with multiple 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 does not explain any parameters (query, limit, offset) or their semantics (e.g., what type of query is supported, how limit and offset affect results). The description adds no parameter-specific information beyond the schema, failing to address the coverage 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 the tool searches within CNIL deliberations, specifying the source (bulk CNIL with size and count) and domain relevance (data protection law, GDPR, algorithmic processing). It distinguishes from siblings by focusing on CNIL deliberations rather than other legal sources like CEDH, CJUE, or judicial decisions, though it doesn't explicitly contrast with other search tools like search_admin or search_legi.

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

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

Usage is implied by mentioning the tool's usefulness for data protection law, GDPR, and algorithmic processing topics, suggesting when it might be appropriate. However, there's no explicit guidance on when to use this versus other search tools (e.g., search_admin for administrative decisions or search_legi for legislation), and no exclusions or prerequisites are stated.

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?

No annotations exist, so description carries full burden. It discloses poor coverage before 1990, explains ID format, live retrieval, and that full sentence queries return zero results.

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 sections and warnings, but slightly lengthy. However, every part adds value, so it earns a high score with minor deduction for verbosity.

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 many sibling search tools, the description is remarkably complete, covering coverage caveats, integration with get_decision_text, and search best practices.

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%, but description includes a dedicated Args section that explains query, limit, and offset with examples and pagination advice, fully compensating.

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 performs semantic search on Conseil d'État case law using a specific engine (Sinequa) and distinguishes from siblings like search_admin by explaining coverage differences.

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 guidance: prefer for public law, use 2-5 keywords, avoid full sentences, and suggests alternative actions if no results (try search_admin or use known ID).

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?

No annotations are provided, so the description carries full burden. It discloses the use of FTS5 index, matching of common citation formats, inverse cross-referencing, and known limitations. This fully informs the agent of the tool's behavior and constraints.

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 concisely structured: one-sentence purpose, followed by mechanism, then clear limitations in a bullet-like format, and parameter descriptions. Every sentence adds value and is front-loaded.

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

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

Given the complexity (4 parameters, no annotations, but has output schema reference), the description is complete. It explains the return format (dict with code, num, total, per_source, decisions with fields) and covers all necessary behavioral and usage details. The output schema is also referenced.

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?

Input schema has 0% parameter descriptions, so the description must add meaning. It explains that 'code' is a court code (e.g., CT, CC), 'num' is an article number (e.g., L1152-1), 'sources' is an optional list from specific values, and 'limit' has default 20 and max 50. This goes 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 searches for decisions that explicitly cite a given law article. It uses a specific verb ('cherche') and resource ('décisions'), and distinguishes itself from sibling tools like search_all by specifying exact citation matching.

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: for explicit article citations. It lists limitations (indirect references, section references, abbreviations) and explicitly recommends search_all for broader conceptual searches. This covers when not to use and 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?

With no annotations provided, the description carries full burden. It discloses the data source (bulk JORF DILA, 1.1GB) and content scope (non-codified texts), and mentions the limit constraint (max 50). However, it doesn't cover authentication needs, rate limits, error conditions, or pagination behavior beyond the limit parameter.

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 with purpose first, then source/scope, followed by parameter explanations and return format. Every sentence adds value with no redundancy or fluff. The bullet-like format for parameters is clear without being verbose.

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 search tool with 6 parameters, no annotations, but with output schema provided, the description is quite complete. It covers purpose, scope, all parameters, and return structure. The main gap is lack of behavioral details like pagination (offset exists in schema but not mentioned) or error handling.

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 all 6 parameters: query (FTS5 keywords), nature (filter with examples), date_min/date_max (publication range in ISO format), and limit (max 50). It also clarifies that query is required and nature is optional.

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 the French Official Journal (JORF post-1990) and specifies the source (bulk JORF DILA) and content types (laws, decrees, orders, circulars, ordinances). It distinguishes from siblings by focusing on JORF content rather than judicial decisions, administrative rulings, or other legal sources.

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 (searching JORF publications post-1990). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools, though the content focus implies alternatives like search_legi for codified law.

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?

With no annotations provided, the description carries the full burden. It details the authentication methods, scope, and technical hindrance ('entrave technique'), adding significant behavioral context beyond the schema. It does not mention error handling or pagination, but the output schema covers return values.

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 slightly lengthy but well-structured: purpose, scope, usage guidance, authentication methods, then parameter list. Every sentence adds value, though the Args section partially repeats schema information.

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

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

Given the tool's complexity (6 parameters, authentication, multiple jurisdictions) and the availability of an output schema, the description covers purpose, scope, usage conditions, authentication details, and parameter meanings comprehensively, enabling an AI agent to use it effectively.

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's Args section fully compensates by explaining each parameter's purpose, including allowed values for 'juridiction' and default/max for 'limit', adding essential meaning beyond the schema 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 searches French judicial jurisprudence via the official PISTE API, lists the covered jurisdictions (Cour de cassation, cours d'appel, etc.), and distinguishes it from sibling tools like search_judiciaire_libre by specifying when to use each.

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 to use this tool only as a last resort or for recent decisions absent from the free DILA database, providing clear when-to-use and when-not-to-use guidance with an implied alternative (search_judiciaire_libre).

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?

No annotations are provided, so the description carries full burden. It discloses: tool is local and authentication-free, uses FTS5 indexing, sorts chronologically descending, returns only snippets (not full text), has known coverage limitations (subset of CA decisions since 2007), and explains how to get full text via get_decision_judiciaire_libre. It also details RG number normalization. All behavioral traits are transparently communicated.

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 headings (Couverture connue, Recherche par numéro de RG) and bullet points. Every sentence adds value, no redundancy. The purpose is front-loaded. Despite length, it remains concise and organized.

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 has 6 optional parameters, an output schema, and a complex context (judicial database with limitations), the description covers all necessary aspects: parameter usage, coverage limitations, relationship to sibling tools, data completeness caveats, and follow-up actions. It is fully complete for an AI agent to select and invoke 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%, so the description must compensate. It does so comprehensively: explains query with FTS5 syntax examples, juridiction filter options (cassation/appel/constit), numero_rg lookup with normalization examples, date format requirements, and limit default. This adds significant meaning beyond the schema's parameter names.

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 performs full-text search in judicial jurisprudence, free from government authentication. It specifies the source (DILA public archives, ~620k decisions, including Cour de cassation, cours d'appel, Conseil constitutionnel). It distinguishes itself from siblings like search_judiciaire (which requires government authentication) and explains specific use cases (search by RG number vs query).

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 and when-not-to-use guidance: it warns about false negatives due to limited coverage, advises using Légifrance or PISTE (search_judiciaire) if no results are found. It also explains that for Cassation appeals, one should use the query parameter with the number, while for CA arrêts, use numero_rg. This clearly differentiates from sibling tools and provides practical 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?

No annotations are provided, so the description carries full burden. It mentions the data source size (745 Mo) and coverage scope, but doesn't disclose important behavioral traits: whether this is a read-only operation, performance characteristics, rate limits, authentication needs, or what happens when limits are exceeded. The limit parameter is documented but without context about consequences.

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 clear front-loading of purpose. The French introduction is concise, and the Args section efficiently documents key parameters. However, the formatting could be improved - the Args section mixes parameter documentation with general description, and there's some redundancy in explaining IDCC format.

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 has an output schema (which means return values are documented elsewhere), the description covers basic purpose and most parameters. However, for a search tool with 4 parameters and no annotations, it should provide more behavioral context about result format, pagination strategy (offset is undocumented), and performance expectations. The 0% schema coverage increases the burden on the description.

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 must compensate, and it does well for 3 of 4 parameters. It explains 'query' as keywords, 'idcc' as optional filter with format example, and 'limit' with maximum value. However, it omits the 'offset' parameter entirely, which is a significant gap since pagination is a key aspect of search functionality.

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 bargaining agreements and branch agreements (KALI) using keywords and optional filters. It specifies the source (bulk KALI DILA) and coverage (national conventions, branch agreements, amendments identified by IDCC). However, it doesn't explicitly differentiate from sibling tools like search_legi or search_jorf, which appear to search different legal domains.

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

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

No guidance is provided about when to use this tool versus alternatives. The sibling list includes many search tools (search_legi, search_jorf, search_admin, etc.), but the description doesn't indicate this is specifically for labor agreements or when it should be preferred over other search tools. Only basic parameter usage is mentioned.

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?

With no annotations provided, the description carries full burden. It discloses key behavioral traits: the search is weighted (FTS5), includes historical versions, and returns paginated results. However, it misses details like rate limits, authentication requirements, error conditions, or whether it's read-only/destructive. The description adds value but doesn't fully compensate for the lack of 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 and front-loaded: the first sentence states the core purpose, followed by source context, then parameter details in a structured Args/Returns format. Every sentence earns its place, though minor formatting could be improved for readability (e.g., bullet points).

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 6 parameters, no annotations, but with output schema present, the description provides good context. It explains the search logic, data source, parameter purposes, and return structure. The output schema means return values needn't be detailed in description. It's nearly complete but could benefit from mentioning error cases or performance characteristics.

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 successfully adds semantic meaning for all 6 parameters: explains 'query' as FTS5 keywords, 'code' as filter for specific codes (CC, CT, CSP), date filters for version start dates in ISO format, and pagination parameters with constraints ('max 50'). This goes well beyond the bare schema, though some format examples would make it a 5.

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 French consolidated codes and laws' using 'FTS5 keywords' on a specific dataset ('bulk LEGI DILA'). It distinguishes itself from siblings by focusing on legislative text search rather than judicial decisions or administrative rulings, as seen in sibling names like search_judiciaire 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 implies usage context by specifying the data source ('bulk LEGI DILA') and search scope ('codes and laws consolidated'), but does not explicitly state when to use this tool versus alternatives like get_law_article or search_jorf. It provides clear technical constraints (e.g., 'limit: max 50') but lacks comparative guidance with sibling tools.

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