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

Annotations declare readOnlyHint=true, which is consistent with the description's search nature. The description adds valuable behavioral details: it returns active aids only, sorts by recent verification, abbreviates long text to 600 characters, and includes a quota cost of 1 unit. This goes beyond the read-only hint by informing the agent of potential quota impact and output truncation, which is not captured 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?

The description is concise and structured: it states the purpose, enumerates filters, specifies output format, and ends with an example and cost. It front-loads the core purpose before listing details. Each sentence earns its place, avoiding redundancy with the schema while providing critical usage context.

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

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

Given the tool's moderate complexity (3 optional params, no output schema), the description is complete: it specifies the output fields, sorting, truncation, and quota cost. The schema covers parameter details. There is no output schema, so the description's explanation of the return format is essential and adequately provided.

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%: each parameter (q, pays, limite) has a description and examples. The tool description adds marginal value by reiterating the semantics in the first sentence ('q (mots cherchés dans le libellé, ...)') and providing a usage example, but since the schema already covers all parameter details, the description doesn't need to compensate. Baseline 3 is appropriate.

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

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

The description clearly states the tool searches public subsidies for businesses ('Recherche des aides et subventions publiques actives destinées aux entreprises'). It specifies the fields searched and the output structure, distinguishing it from sibling tools like propecto_rechercher_marches which search calls for tenders. The verb 'Recherche' with the resource 'aides' is specific 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 explicit filter examples and usage context ('Exemple: {"q": "innovation", "pays": ["FR"], "limite": 5}'). It clearly indicates that the tool returns active aids only and sorts by most recently verified. While it doesn't explicitly mention when not to use it, the clear focus on aids differentiates it from siblings, and the example demonstrates proper usage.

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