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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered; the description adds real context beyond that: the data sources and vintages (RPG 2025, BNVD 2024 as of 31 Dec 2024, Rigal & Perrot 2013-2022, SISE-Eaux 2025), the non-commercial CC BY-NC licence, and the ambiguous-input fallback behavior.

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?

Purpose and the identifier rule are front-loaded in the first two sentences, with attribution and data vintages trailing. The source/licence block is long but serves a genuine compliance and trust role; it could be tightened without losing information.

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, idempotent single-record lookup with 100% schema coverage and no output schema, the description covers what is returned (the exposure-sheet components), the ambiguous-input path, the data vintage of each source, and licensing — enough for an agent to call it correctly and interpret the result.

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 the baseline is 3, but the description adds semantics the schema does not encode: the mutual exclusivity rule ("un seul parmi insee, code_postal ou slug") is absent from the schema, which marks all three as optional with no oneOf/anyOf, and the shared-code_postal → "options" response is explained only here.

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+resource: it produces an exposure sheet for a single commune, and enumerates the exact content (combined Rigal & Perrot index, farmland within 1 km, nearby schools, BNVD purchases, chemical profile). That content list implicitly separates it from compare_communes, rank_communes and search_communes, but no sibling is named explicitly, so it stops short of a 5.

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?

It gives a strong constraint on how to call it — exactly one of insee, code_postal or slug — and explains the shared-postal-code fallback returning an "options" field. It never says when to prefer this tool over compare_communes or show_commune_map, so the guidance is implied by the data returned rather than stated.

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