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

Annotations already cover read-only/idempotent/non-destructive, and the description adds substantial context beyond them: the three-tier matching strategy, that the 50 m fallback is flagged 'probable' with a distance, that principal and secondary syndicates are all returned, the register's limitation (it does not record which works were voted), and a required citation string. This is exactly the kind of behavioural disclosure an agent needs before trusting the answer.

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 content is front-loaded (resource first, then matching caveats, then citation requirement) and the long field enumeration earns its place given there is no output schema. It loses a point for a heavily run-on opening sentence whose list of returned fields and document demands could be more scannable.

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 must describe the return payload itself, and it does so comprehensively — result fields, matching confidence and distance, principal vs secondary syndicates, alerts, and the citation obligation. Nothing an agent needs to call and interpret this tool correctly appears to be missing.

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% with only two parameters, so the schema already carries the meaning of both. The description adds indirect value by explaining the geocoding path (BAN then IGN API Carto) but never addresses the 'place' fallback parameter, so it does not enrich the parameters beyond the schema 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 states a specific verb and resource — what the RNIC registers at a street address — and enumerates the exact fields returned (immatriculation number, lots, syndic, arrêtés, etc.). It is clearly distinguishable from siblings like sales_at_address, property_prices or commune_profile, which concern transactions or area statistics rather than copropriété registration.

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?

Usage context is clear: this is the tool for finding the registered copropriété(s) covering a given French address, and the matching cascade (parcel, normalised address, 50 m proximity) tells the agent what inputs will and won't resolve. However, no sibling alternative is named explicitly for cases where the agent instead wants ownership/transaction or commune-level data.

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