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

With readOnlyHint, idempotentHint, and destructiveHint=false already covering side effects, the description adds substantial behavioral detail: it enumerates the return contents, the 120 m side-zone scope, and the equivalence to the '.md twin' of the street page. It does not discuss errors or output format, but for a read-only tool this is sufficient.

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 dense and front-loaded with the core scope, then uses a colon-separated list to enumerate return elements. Every sentence earns its place, though the first sentence is a long run-on and the reference to the '.md twin' is somewhat cryptic.

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 tool with only two well-described parameters and no output schema, the description covers the returned content, the geographic scope, and the key input caveat. It is slightly incomplete in not distinguishing from sibling tools or clarifying the return format beyond 'same text as the .md twin'.

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 schema already documents both parameters with 100% coverage, so the baseline is 3. The description adds one valuable semantic clarification: the street number is irrelevant because the rule is read at the zone, not at the building, which prevents a likely misuse of the 'voie' parameter.

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 clearly identifies the resource (a French street and its PLU zone) and the operation's output: chapter rules, sector-specific cases, graphic-plan constraints, neighboring zones up to 120 m, prescriptions/servitudes, and triggered permit pieces. It also separates this from building-level queries by stating 'Le numero de rue est inutile : la regle se lit a la zone, pas au batiment.'

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 provides strong context for street-level PLU regulation lookup and even warns not to pass a street number, but it never names sibling alternatives such as get_french_urbanism_zone_rules or get_french_building_permit_pieces, and does not state when this tool should be preferred over them. The selection guidance is therefore implied rather than explicit.

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