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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint:false, but the description adds meaningful behavioral specifics: the tool returns a payload that includes an 'endpoint to quote with', and the connector is explicitly limited to French legal protection insurance. These behaviors are not inferable from the annotations or the tool title, so the description earns credit beyond the disclosure.

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?

Two compact bilingual sentences carry the full payload: purpose, search dimensions, return values, and scope. The most important information is front-loaded and every clause earns its place. There is no fluff or repetition outside the intentional language replica.

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 a read-only search tool with full parameter documentation and rich annotations, the description is nearly complete: it names the return payload and the exact scope of the connector. It does not clarify how to consume the returned 'endpoint to quote with' or how ticket and sub_specialty affect search results, but those are edge details for the core broker-lookup invocation.

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 description coverage is 100%, so the baseline is 3. The description reinforces city/language as the primary search dimensions and restates that only protection_juridique is valid, which slightly amplifies the product field's semantics. It does not add meaningful explanation about ticket or sub_specialty beyond what the schema already provides, so it does not push above the baseline.

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 uses a specific verb ('find') with a concrete resource ('a licensed French insurance broker for legal protection insurance') and defines scope via search dimensions (city and language) and return payload (broker name, city, regulatory status, endpoint to quote with). The exclusivity statement ('Legal protection is the only product this connector covers') helps distinguish it from broader insurance or product-shopping tools, though it does not explicitly name sibling tools like get_broker_info.

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?

There is a clear implied use case: search for a broker in a city/language, and the product exclusivity provides a partial exclusion ('only legal protection'). However, it never explicitly points to alternatives such as get_products or get_quote, nor tells the agent when this tool should not be used in favor of a sibling. The routing is left implicit.

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