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

Annotations declare destructiveHint=true, and the description earns it by spelling out exactly what is destroyed: existing windows are removed first by default, and an empty list wipes all windows. It adds the non-obvious delivery impact plus the constraint that only full hours are allowed and a window must sit inside one day, which no structured field conveys.

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?

Dense and front-loaded: the warning about delivery impact comes before the format spec, which is the right order for a destructive call. The trailing sentence enumerating removed/created slightly duplicates the output schema, so it is not entirely waste-free.

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 destructive, open-world mutation with four parameters and zero schema documentation, this covers the object shape, defaults, edge cases, and side effects. The only omission is the campaign_id semantics, which is self-evident, and return values are already covered by the output schema.

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 schema types `schedule` only as a loose object array, so the description carries the whole burden — it defines the item keys (day enum range, start_hour/end_hour bounds, bid_modifier with a worked +20% example) and the night-window split pattern. It also documents replace_existing's default and clearing behavior, and the optional workspace slug.

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?

States a specific verb and object ("Werbezeitplan (Ad Schedule) einer Kampagne setzen"), scoped to a campaign rather than an account or ad group. It is easily distinguished from siblings such as ads_schedule_performance (reporting) or ads_update_campaign_settings.

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?

Explains the operative consequence of calling it (campaigns with a schedule only serve inside the defined windows) and gives the clearing idiom (schedule=[] with replace_existing=True). It does not name a sibling alternative or state prerequisites/exclusions (e.g. campaign types that don't support schedules), so it stops short of full routing guidance.

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