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

With no annotations, the description carries the full disclosure burden and succeeds. It reveals critical behavioral traits: criteria are immutable and must be removed then re-added, geo/language criterion ids equal constant ids while audience criterion ids must be captured from the add response, Google's default mode is targeting when no mode is set, and dry_run should always be true first. These go far beyond any schema and fully inform the agent of side effects and response expectations.

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 long but information-dense with no filler. Every sentence adds a distinct constraint, example, or routing rule. The most important scoping statement is front-loaded, and dense clauses like 'GEO, LANGUAGE and AUDIENCES' are immediately followed by operation-specific rules. This is justified complexity for an 11-parameter tool.

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 complex tool with no output schema, the description covers all invocation-critical aspects: ops, levels, combination constraints, product-type restrictions, Demand Gen exceptions, removal id mechanics, immutability, dry-run guidance, and sibling routing. It even references the add response field created_criteria[].entity_id, giving the agent the information needed to capture audience criterion ids for later removes. Nothing necessary for correct invocation is missing.

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?

Although schema description coverage is high (82%), the description adds substantial meaning beyond the schema: the difference between user_list_id and audience_id (Demand Gen), the composite criterion_id format '<parent_id>:<criterion_id>', the rule that audiences cannot combine with geo/languages in one call, and the fix for search-language targeting deprecation. It also ties parameters to sibling tools like adsap_google_list_audiences and adsap_google_search_geo_targets, making parameter values reliably discoverable.

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 opens with a specific verb-resource pair ('Manage a Google Ads campaign or ad group's targeting AFTER creation') and names the exact scope: GEO, LANGUAGE, and AUDIENCES. It clearly distinguishes itself from the sibling adsap_google_manage_keywords by explicitly routing campaign negative keywords to that tool, so an agent can select the right tool without opening schemas.

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 explicit when-to-use guidance: after campaign creation, for add/remove of geo/language/audience criteria, and with channel-specific rules (Search/Shopping, Display, Performance Max, Demand Gen, Video). It also provides an explicit when-not-to-use by stating 'Video supports no audience edits' and directing campaign negative keyword removal to adsap_google_manage_keywords op 'add_negative'.

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