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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds real behavioral detail beyond them: it mutates external Meta state and may affect spend, and it explains the precondition/atomicity rule that mismatched plans are rejected 'before reserving or applying anything.' It does not say whether a repeated call is idempotent or what happens to the approval_ref after use, which would be the remaining gap for a destructive write.

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?

Three sentences, front-loaded with the action and its approval gate, then the precondition/atomicity rule, then the external-state warning. Every clause adds information and none restates the tool name or annotations.

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 mutation with an output schema (so return values need no explanation) and annotations covering the safety profile, the description supplies the approval precondition, the plan-binding rule, and the external-impact warning. Only the undocumented connection_context parameter and lack of explicit sibling routing keep it short of complete.

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 0% (patterns only, no descriptions), so the description carries the burden and does explain the role of approval_ref and expected_plan_digest as the selectors of the stored plan. The third parameter, connection_context, is never mentioned, leaving one of three parameters undocumented in prose.

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 — 'replace the daily budget of one Meta ad set' — which cleanly separates it from operations_confirm_adset_bid and operations_confirm_adset_status, and the 'after explicit user approval' framing distinguishes it from the prepare-phase siblings. An agent can identify the action and its target without opening the 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?

It gives a clear precondition ('after explicit user approval') and notes that it rejects other operation kinds, so the agent knows this is the confirmation half of a prepare/confirm pair. It never names the corresponding prepare tool (adsets_prepare_budget_change) or explicitly excludes campaign-level budget confirmation (operations_confirm_campaign_budget), so routing is inferable rather than stated.

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