justicelibre

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds genuine substance by detailing the content categories returned (freshness, terms of use, court codes), but says nothing about auth needs, rate limits, or staleness of the metadata itself. An output schema exists, so return format is handled elsewhere.

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?

Roughly three lines: a content list, an example invocation, and an Args block. It is front-loaded with the substantive content before the example, and nothing is boilerplate. The Args line duplicates the schema enum, slightly diluting conciseness.

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

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

For a single optional-enum lookup tool with an output schema and full annotation coverage, the description supplies everything an agent needs: what each topic yields and a working example. The only omission is any hint that this is a prerequisite step for get_law_article or court-code resolution, which would complete the picture.

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

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

Schema description coverage is 100% and the enum is already in the schema, so the baseline would be 3. The description goes one step further by restating the three topic values and giving a concrete example call (about(topic="codes")), which clarifies intent and default selection for the agent. That is modest added value over the schema, not more.

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 enumerates exactly what the tool surfaces: service metadata (sources, volumes, freshness, terms), administrative court codes, and the codes/statutes accepted by get_law_article. That content listing makes the resource unambiguous and distinguishes it from every sibling, none of which is an informational/metadata tool. It loses a point only because no explicit verb or 'returns documentation about JusticeLibre' statement is given.

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 rather than stated: by saying it lists 'codes and statutes accepted by get_law_article', it hints this should be consulted before calling that sibling, and the example clarifies the topic parameter. However there is no explicit when-to-use statement, no exclusions, and no statement that this is a prerequisite lookup for court/law-code identifiers.

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

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

Beyond the read-only, idempotent, non-destructive annotations, the description discloses matching behavior, word-difference reporting, status semantics including timeout retry, incomplete database caveat, ordering of decisions, and source coverage. This is rich behavioral context that annotations alone do not provide.

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

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

The definition is dense but front-loaded, starting with purpose and key input rules before returning status and coverage details. Every sentence carries relevant information for correct invocation and interpretation, with no filler.

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

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

Despite the existence of an output schema, the description provides enough semantic context about statuses, returned fields, coverage, and timeout handling for an agent to use the tool correctly. It is complete for a one-parameter quotation-checking tool with this complexity.

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

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

Schema coverage is 100%, and the schema already documents the text parameter. The description adds meaningful constraints beyond the schema, including that the quotation should be in its original language and provides a concrete example invocation.

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

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

The description states a specific verb and resource: it finds where a quoted passage comes from. It also scopes the task clearly with the quotation-only input and distinguishes the tool from generic search siblings by focusing on source attribution for a quotation.

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

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

It gives clear usage instructions: paste the quotation alone, check each result against the provided source link, and use the listed get_law_article call for article references. It does not explicitly say when not to use this tool or contrast it with alternatives such as search_case_law or search_decisions_citing.

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

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

Annotations already declare the write profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds value beyond them: 'Never changes existing content' refines the non-destructive claim, and 'skill proposal (inactive until the user activates it)' discloses a non-obvious lifecycle quirk. It doesn't discuss validation behavior or the all-or-nothing reference creation here.

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

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

Front-loaded with the enumerated outcomes and kept to a few tight sentences. The long parenthetical list of reference kinds is slightly dense but earns its place by clarifying scope. No filler 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?

For a 14-parameter polymorphic write tool with an output schema, the description covers the account prerequisite, non-mutating guarantee, per-kind field convention, and skill-proposal lifecycle. Return values are handled by the output schema, so little is missing, though per-kind side effects could be richer.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds a genuinely useful meta-rule: 'Fields marked "kind: …" apply to that kind only', which explains how to read the 14-parameter polymorphic schema. That helps an agent understand the kind-dependent parameters that the schema alone only hints at.

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

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

States a specific verb ('Creates') and enumerates exactly what can be created (case file, subfolder, references, AI note, skill proposal), which is essential for a polymorphic tool. This clearly separates it from siblings like update_account_item, delete_account_item and get_account_item.

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?

Gives a prerequisite ('Requires a JusticeLibre account (OAuth sign-in); without one, the tool says so') and an important scoping rule ('Never changes existing content'), which implicitly routes modifications to update_account_item. It stops short of naming an explicit alternative tool, so 4 rather than 5.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description goes further: no recycle bin, the confirm gate meaning 'nothing is deleted without explicit user agreement', required permissions, and OAuth sign-in. These are exactly the behavioral traits beyond annotations an agent needs before calling a destructive 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?

Dense but front-loaded: the core action and types come first, then the confirm gate, then permissions, then the alternative, closing with a concrete example. The semicolon-chained permission clause is slightly cramped but every element earns its place.

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

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

For a destructive mutation tool with an output schema already present, the description covers safety (confirm), authorization (permissions, OAuth), irreversibility (no recycle bin), and the escape hatch sibling. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and the schema already documents the id prefixes, the what enum values, and the confirm default/semantics. The description largely restates this (id s_…/p_…, confirm meaning), adding little syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb (permanently deletes) plus the resource and enumerates the exact item types (case file, saved reference, subfolder, note, unactivated skill). It also names the sibling update_account_item with set_aside as the non-destructive alternative, so an agent can distinguish it from siblings without opening schemas.

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

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

It specifies when to use this tool (permanent deletion, no recycle bin), when not to (use update_account_item with set_aside to keep a trace with a reason), and the preconditions (confirm=true, permission supprimer, notes_ia for AI-saved references). All routing decisions are explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-derivable context: that user-written content is returned as data and never as instructions (prompt-injection stance), and that an OAuth account is required, with the tool reporting its absence.

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 opening clause is well front-loaded, but the rest is a single sprawling sentence with nested parenthetical enumerations that are hard to parse. Nearly every clause is informative, yet the density and structure could be trimmed into separate sentences for 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?

With only two parameters, a full enum, annotations, and an output schema (so return values need not be described), the description covers the remaining gaps: auth requirement and the content-as-data safety note. It is essentially complete, though it could state when a sibling search tool is preferable.

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

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

Schema description coverage is 100% and the kind enum is fully documented in the schema, so the schema carries the parameter burden. The description restates each kind with slightly more detail (e.g., 'e_…' with verification state), but adds little beyond what the enum descriptions already say.

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

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

States a specific verb ('Reads one object') plus the resource (the user's JusticeLibre account) and enumerates the four kinds of objects it can return. An agent can distinguish it from create_account_item, update_account_item, delete_account_item, and the search_* siblings without opening any schema.

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 maps each kind to its use case (account, case_file, item, ticket) and tells the agent that id is omitted for kind=account, which implies when to call it. However, it never names an alternative for retrieving data (e.g., search) or states when NOT to use this tool, so usage is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine behavior beyond that: how duplicate case numbers are served (one judgment, rest in autres_documents), that administrative numbers are refused, the homonymes fallback for CE, and pagination via offset. It does not contradict any annotation.

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

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

The purpose and lookup keys are front-loaded, followed by edge cases and then a compact example block. It is longer than average but the examples map directly to parameter combinations an agent must choose between, so they earn their space. Minor redundancy between the examples and the Args section keeps it from a 5.

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

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

With an output schema present, return values need not be described, and the description instead covers everything else an agent needs: accepted id schemes, all lookup modes, edge-case handling for duplicates and rejected inputs, and the offset/pagination path for long documents. Nothing material is missing.

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

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

Schema description coverage is 100%, so baseline is 3. The description goes beyond the schema by giving format examples per parameter (CETATEXT000007641393, 497566, 23/05688, 24-14.641, C-72/24) and clarifying that id may itself be a case number, which the schema does not spell out. That is real added meaning over the field descriptions.

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

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

The opening line states a specific verb and resource ('Full text of a decision') and immediately names the two lookup keys (id or numero+court). It is easy to tell apart from the search_* siblings because it returns full text of a single known decision rather than listing. It stops short of 5 only because it never names an alternative tool explicitly.

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

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

It specifies exactly when each input form applies (id from a search, numero+court, court_name for RG, bare numero for Cass/ECHR/CJEU) and gives worked examples for every mode. It also handles the negative cases: a bare administrative number is 'refused', duplicate numbers route to autres_documents or homonymes, and it discloses doctrine/JORFTEXT/KALIARTI id support. Conditions are concrete rather than implied.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description layers on genuinely additive behavior: the `not_in_force_at_date` error with `premiere_version`/`ancien_numero`, the `hors_date` flag when fallback_current is used, the 120-articles-per-page pagination via `suite`, and the `etat`/`note`/`info_numero` flags signalling Légifrance lag and renumbering. This is the kind of edge-case disclosure annotations cannot carry.

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 core purpose is front-loaded and every sentence carries information — nothing is filler. It is nonetheless a dense wall of parentheticals and semicolon-chained clauses that is harder to scan than it needs to be, and the two trailing examples could be trimmed.

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

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

With an output schema present, return values need no explanation, and 100% schema coverage plus rich annotations leave little structural burden on the description. It covers namespaces, date semantics, views, pagination and error modes thoroughly; the remaining gap is sibling disambiguation, which is the one thing an agent still has to guess.

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

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

Schema description coverage is 100% and the schema text is itself highly detailed, so the baseline is 3. The prose largely restates the same parameter semantics (code formats, view values, offset as a `suite` value, fallback_current behavior); the only mildly additive element is the worked example showing num plus date for citing an old decision.

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

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

The description opens with a precise verb+resource statement: an article of a French code or statute, as in force on a given date. It goes further by enumerating the accepted code namespaces (codes, LEGITEXT, statutes, European texts, treaties, EU acts). It never names or contrasts a sibling, however, so an agent must infer the boundary with search_legislation or get_legislative_history on its own.

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

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

It gives concrete routing context inside the tool: how to discover code abbreviations (about(topic="codes")), that omitting num yields the whole text, that view="versions"/"map" switch to history or citation graphs, and that passing a decision's date serves the article as it then stood. What is missing is explicit when-not guidance — nothing says when to prefer search_legislation or the separate get_legislative_history tool over view="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?

Annotations already declare read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description goes well beyond them: it discloses data-coverage limits (post-2012 AN files, key dates only before), the full response structure (parcours steps, documents with number/date/authors/URL, votes, minutes, Constitutional Council decision, Official Journal), the meaning of `issue` as adopted/rejected, and the max-20 files ceiling.

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

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

Front-loaded with the purpose and what the response contains, followed by a compact example and the parameter list — the reader can stop after the first sentence if they only need the gist. The Args block duplicates the schema word-for-word, which is mild waste for docstring-style convention but not harmful.

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 zero-required-parameter, read-only lookup with four simple scalar params and an output schema, the description supplies everything an agent needs: domain meaning, coverage limits, input modes, return shape, and citation guidance. Return-format detail is technically redundant given the output schema, but it adds useful context rather than creating a gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The 'Args' block largely restates the schema fields verbatim (query operators, loi example, limit max, steps meaning) rather than adding syntax, format, or interaction rules beyond it; the only marginal addition is the example call and the note that `issue` distinguishes adopted from rejected outcomes.

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

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

States a specific verb+resource — retrieving the legislative history (travaux préparatoires) of a French statute or bill — and pins down scope ('Assemblée nationale files since 2012; key dates only before'). This is clearly separable from sibling tools like search_legislation, get_law_article, and get_decision, which retrieve current text or case law rather than the drafting trail.

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?

Gives a concrete call example and implies the two entry paths: keyword `query` for browsing file titles versus exact `loi` number, plus the downstream instruction to 'cite documents by number and URL.' It never states when not to use it or points to search_legislation as the alternative for full-text lookup, so the routing guidance is clear but incomplete.

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

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

Annotations cover read-only/idempotency/destructive hints, but the description adds rate limits (3 tickets/day, 5 messages/hour), attachment limit (3 plain-text), account/OAuth requirement with fallback behavior, and that tickets are marked 'via AI'. This is rich behavioral context 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?

Front-loads purpose and usage constraint, then packs limits, reply routing, and auth requirements into a tight paragraph. Every sentence contributes; slight density but no filler.

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

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

With output schema present and annotations covering safety, the description still supplies auth, rate limits, consent, and routing needed to invoke correctly. Nothing critical is missing for this mutation tool.

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

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

Schema coverage is 100%, so parameters are fully documented in the schema. The description reinforces the attachment limit and enum categories but adds no new syntax, format, or defaults 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?

States a specific verb 'opens' and resource 'ticket' with the JusticeLibre team, and the purpose categories (wrong data, missing source, bug, idea). It distinguishes itself from reply_ticket by describing opening, and points to get_account_item for reading replies.

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 'Use only if the user asks for it or approves it', giving a clear consent prerequisite. It does not explicitly route reply actions to reply_ticket, but it does point to get_account_item for reading replies.

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?

Goes well beyond the annotations by disclosing the AI-attribution marking, the consent requirement, a concrete rate limit (5 messages/hour), an attachment cap with format restriction, and the OAuth account dependency with its failure behavior. Annotations only cover the generic safety profile, so this extra operational context is genuinely additive.

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

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

A single compact block that front-loads the core action and the AI-attribution detail before the constraints. Every clause carries information, though the terse fragment "Permission tickets" is slightly cryptic and the rate/attachment/account details crowd into one run-on sentence.

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

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

An output schema exists so return values need no explanation, and the description covers the remaining gaps for a mutating, externally visible action: consent, attribution, rate limits, attachment limits, and auth prerequisites. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so the parameters are already documented, and the description's attachment constraint (3 plain-text files) merely restates maxItems=3 and the plain-text note. No additional meaning is added about ticket_id format or message semantics 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?

States a specific verb (adds a message) and resource (an existing ticket) plus the crucial scoping detail that the message is sent on the user's behalf and marked "via AI". This clearly distinguishes it from the sibling open_ticket, which creates tickets rather than replying to them.

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

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

Gives an explicit gating condition: "Use only if the user asks for it or approves it," which is exactly the guidance an agent needs before invoking a tool that acts on someone's behalf. It also notes the account prerequisite, but it never names open_ticket or any alternative, so the routing advice is incomplete.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds the useful behavioral note that resolution yields both an id and a source URL, and that European article references route to get_law_article, but says nothing about behavior on unresolvable or ambiguous references, which is the main risk for a resolver.

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 core mapping is front-loaded and each bullet of accepted formats adds routing value; the two inline examples demonstrate the call shape. It is dense but nearly every clause earns its place, with only mild redundancy between the format bullets and the Args section.

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

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

With an output schema present, return values need not be explained, and annotations cover the safety profile, so the description only needed to clarify inputs and the sibling handoff — which it does. The only gap is failure/ambiguity behavior for references that match nothing or match several texts.

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

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

Schema description coverage is 100%, so a 3 baseline applies, but the description goes beyond the schema by illustrating format families for 'reference' ("loi n° 91-647", "Cass. 2e civ., 14 oct. 1999, n° 96-21.701", "art. 8 CEDH") and by explaining legitext's purpose (a LEGIARTI belonging to a text outside the codes) and date's role (article version). This meaningfully disambiguates the optional 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 opens with a specific verb+resource pair ('Turns a reference into an identifier and an official link') and then enumerates the exact input families it accepts (statute/decree numbers, LEGIARTI/LEGITEXT/ECLI/CELEX identifiers, decision citations, European article references). This makes it clearly distinguishable from siblings like search_legislation, which locate documents rather than resolve an already-known reference.

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

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

It states the precise input shapes that trigger this tool and even names the downstream handoff ('→ official link and the get_law_article call'), which tells the agent how to continue after resolving an article. It stops short of saying when NOT to use it (e.g., versus search_legislation when no reference is known), so it is clear context without explicit exclusions.

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

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

Annotations already cover readOnly/idempotent/non-destructive and openWorld=false, so the bar is lower, but the description adds real behavioral context: synonym expansion is on by default, citations and ECLIs are auto-recognized, singular/plural are folded together, quotes force exact matching, and the corpus is French so queries should be in French. Return format is left to the output schema.

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

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

Purpose and routing are front-loaded, followed by an example, then Args. The Args section duplicates the schema descriptions and the example query adds little, but the overall text is scannable and each paragraph has a role.

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

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

With an output schema and full annotation coverage in place, the description supplies everything an agent needs for a 7-parameter search: corpus scope, language requirement, operator grammar, citation handling, synonym behavior, and the alternative tool for narrow queries.

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

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

Schema coverage is 100%, so the baseline is 3. The 'Args' block largely restates the schema's own parameter descriptions (operators, NEAR = within 10 words, sources list, date format, limit max, synonym default) rather than adding syntax or edge-case detail beyond it.

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

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

The description states a specific verb and resource ('Searches all sources'), enumerates the corpora covered (French and European case law, codes, Journal officiel, collective agreements, doctrine), and explicitly distinguishes itself from the sibling search_case_law. An agent can tell it apart from sibling tools without opening any schema.

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

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

It gives explicit when-to-use ('Entry point for an open question') and names the alternative for the narrow case ('for one specific court, use search_case_law'). It does not route among the other lookalike siblings (search_doctrine, search_legislation, search_recent_admin_decisions), so the guidance is clear 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?

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful operational constraints beyond annotations, such as French keywords, English-only ECHR/CJEU texts, and court-specific limits on date filtering and sorting.

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 front-loaded with purpose and the key sibling alternative, then presents concise parameter notes. Some entries repeat the schema or are terse to the point of being unclear (`date_max: same`), but there is little wasted text.

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

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

With 10 optional parameters, an output schema, and rich annotations, the description provides enough context to call the tool correctly: court options, sorting, date constraints, pagination behavior, query syntax, and known language limitations.

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

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

Schema description coverage is 100%, so parameter meanings are already documented. The description largely repeats schema text, though it adds a concrete example and clarifies that `query` is optional when `numero_rg` is provided.

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

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

The description states a specific verb and resource: retrieving decisions of one court or court family by relevance or date. It explicitly distinguishes the latest-administrative-decisions use case by naming the sibling tool `search_recent_admin_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?

It gives clear context for when to use this tool, including an example query and court codes, and routes 'latest decisions' to `search_recent_admin_decisions`. It lacks explicit when-not-to-use guidance beyond that one alternative.

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

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

Annotations already cover readOnly, idempotent, non-destructive, and closed-world traits. The description adds genuinely useful behavioral context beyond them: the match is restricted to explicit citations with a resolvable article number, not conceptual relevance.

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

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

Front-loads the purpose, then the exclusion, then a usage example in three tight sentences with zero filler. Well structured and immediately actionable.

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

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

With annotations and an output schema present, the description needn't explain return values or the limit/sources behavior documented in the schema. It is complete for correct invocation, missing only cross-references to other sibling search tools.

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

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

Schema coverage is 100%, so the schema already documents all four parameters with examples. The inline example (code="CC", num="1240") adds a marginal hint about abbreviation format, but parameter meaning is largely carried by 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?

States a specific verb and resource: returns court decisions that EXPLICITLY cite a given article. It implicitly distinguishes itself from `search` by naming that sibling as the concept-based alternative, so an agent can tell the two apart without opening schemas.

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?

Clearly states the positive case (explicit citations with an article number) and the negative case (indirect references or citations lacking an article number), routing the latter to `search`. It does not mention other sibling search tools (e.g. search_case_law), but the core when/when-not routing is present.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds domain scope but nothing beyond annotations about result handling, ranking, or limits beyond the max-200 figure already in the schema.

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

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

Front-loaded domain statement followed by a concrete example and a compact Args block; nearly every line earns its place. Minor redundancy in restating schema parameter text verbatim in the Args section.

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

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

With an output schema present and rich annotations, the description only needs to establish scope and query semantics, which it does. The main residual gap is the absence of guidance on how category/source relate to the returned directory structure, though that is partly left to the 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?

Schema description coverage is 100%, so the schema already documents all four parameters, and the Args block largely restates them. The worked query example with the OR operator is a modest value-add, but nothing compensates for or exceeds the schema's own documentation.

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

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

The description names the specific resource domain — French public addresses and contacts (courts, greffes, town halls, CCAS, prefectures) — which clearly separates it from siblings like search_case_law, search_doctrine, or search_decisions_citing. It does not, however, frame the action explicitly or contrast itself with the generic `search` sibling, so a 4 rather than a 5.

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

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

Usage is conveyed only by example ("tribunal judiciaire Dunkerque") and by the enumerated categories of offices; there is no statement of when to prefer this over `search`/`resolve_reference` or what the tool does not cover. The example implies context but leaves selection to inference.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the description does not need to repeat safety. It adds valuable non-obvious context: that these are opinions which do not bind a judge, and the identifier distinction between numero and doc_id for conclusions. This goes beyond what annotations or schema provide.

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

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

It is front-loaded with the key distinction (not court decisions) and includes a useful example. It is relatively concise, though the list of sources is long and the sentence about identifiers is slightly dense. Overall, it earns its place.

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

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

Given the complexity of multiple sources and the need to differentiate from case law tools, the description provides the essential context: what the documents are, their non-binding nature, and a concrete example. Output schema exists, so return values need not be explained. This is complete for an agent to use the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning about the source parameter by enumerating the allowed values in natural language and clarifies the use case for arianne_crp conclusions (case number is numero, doc_id is internal). This provides context beyond the schema's generic enum list.

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

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

The description names the specific resources (CADA opinions, Défenseur des droits decisions, rapporteurs publics conclusions, BOFiP, Code du travail numérique, CNIL deliberations) and explicitly explains what they are not ('These are NOT court decisions'), which clearly distinguishes it from siblings like search_case_law and search_decisions_citing.

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

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

It gives a clear usage example and explains that these are not binding decisions, which helps an agent understand when to use this rather than case law search. However, it does not explicitly state when NOT to use it or name the alternative (search_case_law) for court decisions, leaving some inference required.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior: keywords must be in French, limit is capped at 50 per page, KALI tout includes repealed texts, and operator syntax (OR/AND/NOT/NEAR, NEAR=within 10 words).

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 top portion is well front-loaded (purpose, alternative, example, corpus behavior), but the Args block duplicates all ten parameter descriptions that already appear at 100% coverage in the schema, so a large fraction of the text does not earn its place.

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

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

For a 10-parameter search tool with an output schema (so return values needn't be explained), the description covers corpora, filters, operators and pagination adequately. Only minor gaps remain, such as rate limits or default result ordering.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's Args block largely restates the schema verbatim; the only marginal added meaning is the worked example (query + code) and the corpus-specific behavior notes, which do not add syntax or format detail beyond the schema.

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

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

States a specific verb (keyword search) and names the exact resources and corpora it covers (LEGI codes/statutes, JORF, KALI agreements, EU law). It also explicitly routes the 'known article' case to the sibling get_law_article, so an agent can distinguish it from that tool without opening either schema.

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?

Gives clear usage context: it names get_law_article as the alternative for a known article and explains per-corpus behavior (kali with idcc → table of contents; query='Syntec' → agreements; KALI id → sections). It does not state explicit exclusions or when not to use it, but the routing guidance is concrete.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: it is a daily mirror of open data, dates refer to the decision date, and per-call caps are bounded (max 100, 0 = no cap), which matters for pagination expectations.

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

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

The purpose and query-syntax rules are front-loaded well, but the trailing 'Args:' block largely restates the input schema verbatim, adding length without new meaning. The structure is legible yet carries redundancy an agent does not need twice.

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

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

With 7 optional parameters, full schema coverage, rich annotations, and an output schema that already documents return values, the description supplies everything still missing: the query language, the court-mode semantics, and the cap behavior. Nothing an agent needs to invoke it correctly is absent.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond it by documenting query syntax that the schema does not: all words required, double quotes for exact phrases, uppercase OR/AND/NOT/NEAR operators, and the French-keyword caveat about acronyms such as 'OQTF'. That is real semantic value for the highest-risk parameter.

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?

Opens with a specific verb+resource and scope: 'Latest decisions from the administrative courts' open data (daily mirror), sorted by date'. It also explicitly differentiates itself from the closest sibling by naming the recency-vs-relevance distinction against `search_case_law`, so an agent can pick between them without opening either schema.

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 parenthetical '(by relevance: `search_case_law`)' routes the agent to the alternative and implies the selection rule (this tool for latest-by-date, the sibling for relevance search). However, there are no explicit when-not conditions and no guidance on the combinatorial court modes (ALL_TA vs ALL_CAA vs CE-CAA) beyond the enum listing.

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?

Goes well beyond the annotations: idempotency is stated ('giving the same values again changes nothing'), mutation semantics ('Overwrites the previous values'), a hard constraint ('Notes written by the user cannot be changed'), deletion being out of scope, and the auth requirement with explicit failure behavior. This is exactly the extra context annotations cannot carry.

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 first sentence front-loads the verb, resource, and kind→field mapping; subsequent short clauses cover idempotency, overwrite, the user-note restriction, the deletion sibling, and auth. No padding 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?

Covers identity of the tool, mutation behavior, idempotency, a notable constraint, deletion routing, and auth failure mode. With 19 parameters fully documented in the schema and an output schema present, nothing essential is missing.

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

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

Schema description coverage is 100% and the schema already documents each parameter including kind-specific meanings. The description restates the kind→fields mapping but adds little syntax or format detail beyond what the schema provides, so the baseline 3 applies.

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?

Starts with a specific verb+resource ('Sets the state of an existing case file...') and then enumerates the four kinds it operates on, each with its editable attributes. This lets an agent distinguish it from create_account_item and delete_account_item without opening the schema.

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 names delete_account_item as the tool for deletion ('Nothing is deleted: deletion is delete_account_item'), which is a clean exclusion. It also states the OAuth requirement and that the tool reports missing accounts. It doesn't enumerate when to prefer get_account_item or create_account_item, so it falls short of full routing guidance.

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