google_ads_budget_update

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

With no annotations provided, the description fully carries the behavioral disclosure burden. It explicitly warns that the operation is mutating and not automatically reversible, explains that shared budgets affect all campaigns, reveals the currency-unit (not micros) gotcha, and notes the immutable period constraint. This goes well beyond a bare 'update' statement.

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?

Although the description is longer than average, every sentence conveys essential operational detail: the action, mutability warning, return value, shared-budget side effect, unit clarification, and API period limitation. There is no filler or redundant explanation beyond critical safety-relevant facts.

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?

Given the lack of annotations and output schema, the description is remarkably complete. It explains the return value, side effects, required pre-checks, and API constraints. For a mutating tool with six parameters and multiple edge cases (shared budgets, period types, micros vs. currency), this description leaves little ambiguity for an agent.

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?

The input schema already provides 100% parameter coverage, including currency units, mutual exclusivity, and CUSTOM_PERIOD restrictions. The description adds no new parameter-specific meaning beyond echoing key points (e.g., amount not in micros), so the baseline of 3 applies.

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: 'Sets the daily and/or total amount on an existing campaign budget.' This clearly distinguishes it from budget creation (google_ads_budget_create) and retrieval (google_ads_budget_get) by emphasizing 'existing' and enumerating the exact update targets.

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 and preconditions: checking reference_count with google_ads_budget_get before modifying shared budgets, and recording prior state with mureo_state_action_log_append if rollback may be needed. It also states a hard constraint—total amounts only apply to CUSTOM_PERIOD budgets—providing a clear when-not.

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