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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description still adds real behavior via dryRun ('only get count and cost'), a cost-preview mode not expressible in annotations, but it omits anything about rate limits, cost magnitude, or result ordering.

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?

One leading sentence states the effect, then a compact per-argument list — front-loaded and free of filler. Slight redundancy in restating parameter names, but the format is scannable and appropriately sized for 8 undocumented parameters.

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 an 8-parameter search with no output schema or schema descriptions, the definition covers all inputs but stops short of completeness: no result shape, no explanation of enrichment tiers, no note on what 'cost' means in dryRun, and no filtering semantics. Adequate to call, not sufficient to call confidently.

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% across 8 parameters, so the description carries the full documentation burden and does document every one, including defaults (limit 10, dataEnrichment 'name'). Depth is thin in places — dataEnrichment lists values 'start, advanced, name' without explaining what each returns, and provinceCode conflates 'department code or region'.

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 concrete verb and resource — returns a list of French companies matching search criteria — and the FR scope implicitly separates it from the IT/EU/WW search siblings. It does not name an alternative explicitly, so an agent must infer the routing from the tool name.

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 when-to-use guidance is given: nothing says when to prefer this over get_company_EU_advanced, get_company_IT_search, or the *_start variants, nor whether criteria are AND-combined. Usage must be inferred entirely from the parameter list.

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