Изменить стратегию кампании

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description goes well beyond that by disclosing the three things the server does (campaign type lookup, currency-to-micro-unit conversion with an explicit list of money fields vs percent fields, and the previous strategy in the response), the fact that no compatibility validation happens locally, and that changing strategy type restarts training. The only reason this isn't a 5 is that side effects like training restart sit late in a dense paragraph.

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?

Front-loaded with the one-sentence purpose and the read-copy-edit workflow before the dense rule list, and every sentence carries operational information. It is long and reads as a single run-on paragraph, so structure (bullets or headings for the API rules) is the weak point rather than filler.

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?

Covers everything needed for a mutation tool with nested objects and no output schema: money units and conversion, retention of unset fields, what the response contains (previous plus UpdateResults), which fields are untouched, compatibility rules, prerequisites for conversion strategies (GoalId plus counter on the campaign), and where unsupported cases must go.

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 the baseline would be 3, but the description adds real meaning: both search and network must be sent, unpassed fields within the same strategy retain current values (verified live on unified campaigns), Crr and BudgetIncreasePercent are percentages not money, and PriorityGoals/CounterIds/AttributionModel are not changed by this tool. It does not enumerate every strategy structure field, but it points to get_dictionaries → Currencies for minimums.

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 resource (changes the bidding strategy of a text campaign or unified campaign) and explicitly scopes the format to an API object identical to what list_campaigns with strategy:true returns. The agent can distinguish it from update_campaign and raw_request without opening any schema.

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?

Prescribes the exact workflow (read current strategy → show the user → copy and edit one field) and names the escape hatches: other campaign types and campaigns on a batch strategy go through raw_request. It also lists when the API will reject the call, e.g. auto-strategy on search requires NETWORK_DEFAULT or SERVING_OFF in networks.

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