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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safe, non-mutating, and idempotent nature is covered. The description adds valuable context beyond annotations: the 'sector' parameter has alias resolution (e.g., 'abogados' resolves to canonical slug) with the response declaring the translation in _meta.sector_resolved_from. It also explains the access level difference between anonymous and authenticated callers. These are important behavioral traits not captured by the annotations.

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 two sentences of core purpose plus one sentence each for sector details and authentication behavior. It is well front-loaded with the main purpose and examples. The only minor issue is that the sector detail could be slightly more compact, but overall every sentence justifies its presence and it remains concise at around 70 words.

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 (5 parameters, 1 with a large enum), 100% schema coverage, and existence of an output schema, the description covers all necessary aspects: what the tool searches, what parameters are available with important behavioral notes (sector alias resolution, auth-based access levels), and examples. The output schema presumably documents the return format, so the description does not need to. All dimensions are sufficiently addressed.

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 five parameters with types, constraints, and descriptions. The description adds value by explaining that 'sector' is a closed vocabulary with alias resolution behavior and that aliases like 'abogados' resolve to canonical slugs with response metadata. It also clarifies the 'city' parameter with example city names beyond what the schema provides. This is a clear addition of meaning 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?

The description clearly states the tool searches verified entities across 10 countries by various criteria (name, keyword, country, city, sector). It gives concrete query examples like 'find me a dentist in Madrid' and 'list law firms in Barcelona', which explicitly differentiate it from sibling tools that do entity lookups by ID (entity_lookup, professional_lookup) or retrieve dossier/competitor data (get_full_dossier, get_competitors). The verb is specific and the resource is well-defined.

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 clear usage context by mentioning search queries and filters, and gives example natural language queries. It also notes that anonymous callers get limited results while authenticated TRACE+ keys unlock full records. However, it does not explicitly state when NOT to use this tool in favor of siblings like entity_lookup or professional_lookup, which would be useful for disambiguation.

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