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

With readOnlyHint=true annotation already indicating read-only behavior, the description adds significant value beyond it: it details the coverage (as of 10/09/2026, with counts per jurisdiction), the sorting behavior (chronological descending despite BM25 scoring), and the critical limitation that results return only snippets, not full text. This is rich context that helps the agent set expectations and avoid misinterpretation. The only minor gap is not explicitly stating that the tool is read-only, but the annotation covers that; the description's extra detail on coverage and snippets compensates well.

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 detailed but well-structured: starts with the core purpose, then coverage, then usage caveats, then parameter explanations. It uses markdown headers and bullet points for clarity. Some redundancy exists (e.g., repeating the warning about false negatives in both the coverage section and later), but overall it is information-dense without being rambling. The front-loading of the core purpose and the alternative is effective. A 5 would require trimming the repetitive caution, but it remains concise for the amount of 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 high complexity (7 parameters, 0% schema coverage, multiple jurisdictions, edge cases like RG variants, pagination, false negatives), the description is remarkably complete. It covers all parameters, provides usage examples for RG and Cassation numbers, explains output limitations (snippet only), and points to the 'get' tool with decision ID formats. With an output schema present, it need not explain return values in detail, but it even hints at truncated/next_offset. There is no missing information an agent needs to call 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?

The schema coverage is 0%, so the description must carry all parameter semantics, which it does excellently. It explains each parameter in detail: query supports FTS5 syntax (phrase, AND, prefix), juridiction defines allowed values and mappings (e.g., 'tj' includes old TGI/TI), numero_rg normalizes variants, date_min/max are ISO, limit/offset with pagination and truncated/next_offset. This far exceeds what the schema provides. A 5 would require even more nuance, but it's already very strong; the slight deduction is for not clarifying the exact format of date_min/max beyond ISO, but that is minor.

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 case law, executed locally without government authentication. It specifies the resource (bulk DILA archives enriched by Judilibre) and distinguishes itself from the sibling 'search_judiciaire' by mentioning it as an alternative, making the tool's unique offering explicit.

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

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

The description explicitly provides when to use this tool (for open-data judicial case law with local execution, no auth) and when not to (when the user needs Légifrance or PISTE via search_judiciaire). It also gives specific guidance for searching by RG number vs. Cassation pourvois, and warns about false negatives, providing actionable alternatives. This is thorough and directly guides tool selection.

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