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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent mutation, so the safety profile is covered. The description adds useful behavior — it names the return payload ('created keyword resource names and count') and documents the default match type — but omits what many agents need most for a non-idempotent add: what happens with duplicate keywords, whether validation fails the whole batch or partially succeeds, and what errors look like.

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?

One front-loaded sentence states the action, followed by tightly structured Args and Returns blocks with no filler. The Returns block is somewhat redundant given an output schema exists, but it is short and does not bloat the definition.

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 3-parameter mutation with annotations and an output schema, the description supplies the field-level detail the schema lacks and confirms the return shape. The remaining gap is failure/duplicate semantics for a non-idempotent write, which an agent calling this repeatedly would want to know.

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 0% and the keywords array is an untyped object in the schema, so the description is the sole source of parameter meaning — and it delivers. It specifies the customer_id format ('numbers only, no hyphens'), the purpose of ad_group_id, and the three sub-fields of each keyword object including the EXACT/PHRASE/BROAD enum, the BROAD default, and the micros unit for CPC bids.

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 and resource: 'Adds keywords to an ad group.' An agent knows exactly what entity is created and where. It does not, however, distinguish itself from close siblings like add_negative_keywords, add_to_negative_keyword_list, or update_keyword, so the agent must infer the boundary from the names alone.

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?

There is no statement of when to use this tool versus alternatives such as add_negative_keywords (for exclusions) or update_keyword (for changing existing bids/match types), nor any prerequisites about the ad group or customer account. Usage is only inferable from the name and the parameter list.

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