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

Beyond the readOnly/idempotent/non-destructive annotations it adds real behavioral context: every conclusion carries its rule and source, the rule base is date-stamped, and missing facts are returned as questions rather than assumed. It also discloses a critical scope limit (no PLU or servitude lookups; terrain protections must be supplied as parameters) and that output is general information, not legal advice or a municipal decision.

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-loaded with the deliverable list, then scope limits, then the market-data disclaimer and legal caveat. The long opening sentence is dense but every clause names a distinct output; no sentence is filler, though the run-on structure makes the first read heavier than necessary.

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 34-parameter rule engine with no output schema, the description covers scope, the question-back behavior, source attribution, and explicit exclusions. What remains implicit is how the conditional parameters cluster by type_travaux, which an agent must still infer from the schema.

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 description coverage is 100% across all 34 parameters with enums and units documented, so the schema does the heavy lifting and the baseline applies. The description adds only one semantic hint — that terrain protections must be declared via parameters — and otherwise does not explain the interaction between the single required type_travaux and the 33 conditional, often optional inputs.

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 concrete deliverable set with specific nouns: which urbanism formality applies (none, prior declaration, building/development/demolition permit), which Cerfa form, whether an architect is mandatory, which documents, and the instruction deadline. An agent can distinguish this from all six sibling tools, which are price/rent/market tools, without opening any schema.

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 explicitly bounds scope ('ce connecteur ne lit ni le PLU ni les servitudes') and routes away from itself for market data ('pour les prix et les loyers, les autres outils'), which is exactly the sibling set. It does not enumerate a hard when-not-to-use case beyond that, so it stops short of a full routing rule set.

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