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

Annotations only declare readOnlyHint=true and openWorldHint=false, so the description carries the rest and delivers: results are sorted by distance, the optional DVF enrichment covers the last 24 months, and each call costs 5 credits. It does not mention pagination limits beyond 'limit' or failure behavior, keeping it below a 5.

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?

Front-loads the one-line purpose, then organizes parameters, a chaining tip, an example, and cost under clear labels. It is longer than strictly necessary but nearly every line earns its place; the enum glosses and example are the only mildly verbose stretch.

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?

With no output schema, the description compensates by explaining the return shape (businesses within radius, distance-sorted, optionally DVF-enriched) and adds cost, chaining, and a worked example. An agent has everything needed to invoke it correctly and know what comes back.

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 baseline is 3, but the description adds genuine meaning beyond the schema: it expands each enum value with a human-readable gloss (e.g. 'notaire' — notary, 'promoteur' — property developer) and explains why include_dvf_stats matters (competitive intelligence). This is real added value the raw enum list lacks.

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 specific verb (Find) plus resource (real estate businesses) and scope (near a location, sourced from the INSEE SIRENE registry). It also names the sibling get_real_estate_business_details as the follow-up tool, so an agent can distinguish this search tool from the detail-lookup sibling.

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?

Names an explicit alternative (get_real_estate_business_details with the siren field) and a use case (competitive intelligence via DVF enrichment), and discloses cost (5 credits). It stops short of stating when NOT to use this tool or how it compares to other search-orientated siblings like search_property_transactions.

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