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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is covered; the description adds genuinely new behavior: the operation is queued asynchronously, it is pinned to a stored plan via ref+digest, it rejects mismatched operation kinds before reserving or applying anything, and it may affect ad spend. It does not discuss idempotency or what happens if the same approval_ref is confirmed twice.

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 tight sentences with the approval precondition and plan-pinning rule front-loaded, and the external-impact warning last. No filler, though the trailing phrase 'and may affect spend' slightly overlaps the destructive annotation.

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?

An output schema exists, so return values need not be explained. For a destructive, open-world mutation the description supplies the key context an agent needs (approval gate, plan pinning, async queueing, spend impact); only the unmatched-approval failure behavior and connection_context usage are left implicit.

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%, so the description carries the full burden. It conveys the role of approval_ref (selector of the stored approved plan) and implies that expected_plan_digest validates that plan, but it never explains the expected digest format or the significance of connection_context, which is entirely unaddressed. Partial compensation only.

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: queue creation of an approved Meta campaign, ad set, and ad structure. It also distinguishes itself from other operation kinds ('rejects other operation kinds'), which helps against the large operations_confirm_* sibling family, though it never names a specific alternative such as operations_confirm_campaign_recreate.

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?

Gives a clear precondition — 'After explicit user approval' — and states that only the stored plan referenced by approval_ref/expected_plan_digest is used, with other operation kinds rejected. What is missing is an explicit negative case describing what an agent should do instead when there is no approval or when the plan digest does not match.

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