Défibrillateurs à La Réunion

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the bar is met; the description goes further by naming the upstream dataset, disclosing that results carry distance, walking time, exact placement and hour-access vs 24h status. It also embeds a safety obligation (tell the user to call 15/112 and start chest compressions) that an agent could not infer from any structured field.

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?

Core identity, data source and example queries are front-loaded, which is right. It runs a little long — the bilingual restatement and the coverage statistic are slightly padded — but every element (examples, access-hours nuance, emergency instruction) carries information rather than filler.

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 a single optional parameter, no output schema and annotations covering the safety profile, the description still fills the main gaps: where the data comes from, how many devices, what fields come back, and what the agent must tell the user in an emergency. Nothing needed to invoke or interpret the call is 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% and the 'lieu' schema description already enumerates communes, beaches, neighbourhoods, cirques, peaks and 'lat, lon' coordinates, plus the empty-input case. The prose restates the same concept at a higher level without adding syntax or normalization rules, so the baseline 3 applies.

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 — the nearest AEDs (defibrillators) to a place in Réunion — plus the data source (Géo'DAE), the coverage (1 200+ devices across 24 communes) and the returned attributes. No sibling tool covers this domain, and the French/English pairing removes ambiguity for either language of query.

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?

Two concrete example phrasings (« défibrillateur le plus proche de la plage de l'Hermitage », « défibrillateur à Cilaos ») show the exact query shape the tool expects, and the schema's 'empty = whole island' note is echoed. There is no explicit when-not-to-use guidance, but no sibling could plausibly be confused with this one, so the gap is minor.

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