local_risk_france_commune_brief

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

No annotations are provided, so the description must carry behavioral disclosure. It does not mention side effects, API calls, potential errors, or whether the tool actually executes searches or just provides queries. The phrase 'to run next' hints at behavior but leaves ambiguity. This is insufficient for a composite tool.

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 a single, grammatically complete sentence that front-loads the primary verb ('Create') and resource, then lists components concisely. It avoids redundancy and is easy to parse.

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 explain what the returned brief contains. It lists main components but does not specify the structure, format, or behavior (e.g., whether it returns a plan or an executed brief). The term 'to run next' is vague and could mislead. More detail is needed for a tool of this complexity.

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% for the single parameter `code_insee` with description 'Commune INSEE code.' The tool description adds no extra meaning beyond this, so the baseline of 3 applies. No examples or format hints are given beyond the schema.

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 states it 'Create[s] a source-oriented local-risk brief for a commune' and lists specific components (geo.api identity, Géorisques links, data.gouv search queries). This distinguishes it from sibling tools that perform individual operations like get_sources or search_data_gouv, making the purpose unambiguous.

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 implies a composite use case (brief with multiple sources) but does not explicitly specify when to choose this over calling individual sibling tools. It lacks 'use this instead of X' guidance. Only a general context is provided, so it is not fully explicit.

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