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.