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

Annotations only indicate readOnlyHint=true and openWorldHint=false. The description adds substantial behavioral context beyond that: result limits (10 without key, 25 with key), requirement of a Bearer key for premium features, visibility of deal-score, and the mandatory citation of source_url. This is precisely the kind of operational detail that helps an agent understand side effects and requirements.

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 front-loaded with the core purpose in English, followed by concise, high-value details in French: marketplaces, tier-based result caps, deal-score visibility, and source_url attribution. Every sentence adds a distinct piece of information with no filler. The mix of languages is functional and does not hurt clarity.

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 14 parameters, no output schema, and simple annotations, the description covers the main operational context (aggregation, limits, auth, source_url). It lacks an explicit statement of what fields are returned in each listing, but the parameters mirror likely result attributes, and the mention of source_url provides a key return-value detail. This is adequate for a search tool but not exhaustive.

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 input schema already has detailed descriptions for most of the 14 parameters (coverage 93%), including examples and enum meanings. The description does not add per-parameter semantics; it only uses the generic phrase 'Recherche multi-critères' which is not parameter-specific. Since schema coverage is high, the baseline of 3 is appropriate, and the description does not need to compensate further.

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 opens with a clear verb+resource pair: 'Search used cars for sale in France across all major marketplaces.' It explicitly names the resource (used cars in France), the aggregation scope (major marketplaces), and distinguishes itself from siblings like car_market_stats or estimate_car_price which serve different purposes. The subtitle 'Rechercher des voitures d'occasion' reinforces the action and subject.

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 gives clear context: this is the general-purpose search tool for French used-car listings across aggregated marketplaces. It explains the free tier versus Premium/Pro key behavior, which helps the agent know when this tool is appropriate. However, it does not explicitly name alternatives or exclusion criteria (e.g., 'for pro-only search use pro_search'), so it stops short of full alternative-based guidance.

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