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

Annotations only say the tool writes and is non-destructive; the description adds genuinely new behavior: entities are created PAUSED for safety and require manual activation, and cpc_bid_eur is inert under Smart Bidding. That is real context an agent cannot get from the annotations. It stops short of stating return payload, duplicate-name behavior, or whether creation is idempotent (an output schema exists, so returns are partly excused).

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?

Five short lines, purpose front-loaded followed by one line per non-obvious parameter. The repetition of the PAUSED default is justified because the description attaches the safety rationale the schema default alone cannot convey.

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 6-parameter mutation tool with an output schema, this covers creation scope, default state, conditional bid behavior, and workspace resolution — enough to call it correctly in the common case. Missing pieces are secondary: campaign_id validity requirements, name constraints, and error behavior. The German-only text alongside an otherwise English catalog is a minor consistency gap rather than a completeness one.

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%, so the description must carry the load, and it does for four of six parameters: type_ with concrete values, cpc_bid_eur with a conditional-effect rule, workspace with a single-workspace exception, and the status default with rationale. Only name and campaign_id are left undefined, though both are self-evident from their keys.

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 opening line gives a specific verb and resource ("Neue Ad Group in einer Kampagne anlegen"), so an agent immediately knows this creates an ad group inside an existing campaign. It does not name or differentiate against any sibling (e.g. ads_create_ad, ads_create_campaign, openai_ads_create_ad_group), but the noun is distinctive enough that confusion risk is low.

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?

Usage is only implied: a campaign must already exist and type_ should match it ("passend zur Kampagne"). The PAUSED-by-default note hints at a follow-up activation workflow, but there is no explicit "use this when... / use ads_create_campaign instead when..." routing or statement of prerequisites such as campaign existence or permissions.

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