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

The description adds meaningful behavioral context beyond annotations: it reveals a dry-run/confirm workflow ('Dry-run valide par Google d'abord ; confirm:true pour appliquer') and that negative:true performs an exclusion. Annotations already indicate readOnlyHint=false and destructiveHint=false, but the confirmation requirement is a critical behavioral trait not present in the schema or annotations. However, it does not disclose potential side effects, rate limits, or permissions.

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 remarkably concise—three short sentences covering purpose, prerequisite, and confirmation flow. It is structurally front-loaded with the key action first, then the workflow. Every sentence adds necessary information, with no filler or repetition of schema fields.

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 tool with 5 parameters, no output schema, and a non-trivial confirmation flow, the description covers the essential aspects: what the tool does, how to obtain the target ID, and the dry-run/confirm process. It does not describe the response/return value, but that is less critical given no output schema. The absence of an explicit note on customer_id being optional is already handled by the schema description.

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 baseline is 3. The description enriches parameter understanding by linking geo_target_resource_name to the lookup workflow ('L'identifiant s'obtient avec ads_geo_target_search'), and clarifies that confirm:true is required to apply and negative:true toggles exclusion. This goes beyond the schema's bare field descriptions, which mostly restate names and simple types.

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 the tool's function: 'Ajoute une zone au ciblage d'une campagne, ou l'exclut avec negative:true' (Adds a zone to a campaign's targeting, or excludes it with negative:true). It specifies a concrete verb ('ajoute') and target resource ('zone au ciblage d'une campagne'), and the negative:true modifier explicitly covers the exclusion case. This distinguishes it from sibling tools like ads_geo_target_search (search) and ads_add_keywords (keywords).

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 gives clear context for use: adding or excluding a geographic zone to a campaign. It also provides a prerequisite by stating 'L'identifiant s'obtient avec ads_geo_target_search' (the identifier comes from ads_geo_target_search), which is essential for correct invocation. However, it does not explicitly mention when to prefer this over alternative tools, nor does it state any exclusions (e.g., 'use ads_add_negative_keywords for negative keywords').

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