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

Well beyond the annotations, it discloses the pre-flight rechecks (account, Owner, module, token, inventory, expiry), that Google validateOnly runs before at most one create, and what provider readback does and does not prove. This is strong mutation-safety context consistent with idempotentHint=true and destructiveHint=false. It loses a point for undefined internal jargon ("Owner", "module", "M6 completion") that an agent cannot operationalize.

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?

It is dense and front-loads the invocation gate, which is good, but it reads as telegraphic internal shorthand with several unevidenced phrases ("Secondary goal only", "M6 completion") that dilute the signal. Every clause is trying to earn its place, yet some do so only for a reader who already knows the system.

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 mutation tool with no output schema and 0% schema description coverage, the description compensates on safety and retry semantics but not on parameter meaning or what a successful call returns. An agent knows how to be careful but not exactly which values to pass or what state to expect afterwards.

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%, so the description must carry parameter meaning, yet it only lists the four names already enforced as required by the schema. The only added meaning is implicit provenance — that operationId and planHash come from the approved preview — with no explanation of what planHash binds or how customerId is scoped. Constraints and formats are left entirely to the schema patterns.

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 implies a creation step gated on an approved preview ("at most one create", "After explicit approval of the exact preview") but never plainly states the verb+resource, e.g. that it creates the Google Ads purchase conversion action produced by the sibling prepare tool. The German title "Kaufaktion anlegen" and the unexplained framing ("Secondary goal only") leave an agent to infer what is actually being applied.

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 clearly gates invocation on explicit approval of the exact preview and states scope exclusions (no upload, no bidding selection). It also prescribes the failure path: unknown or crashed submissions must be read back, never retried with a new key. It does not name the read-back sibling (get_google_ads_purchase_action_operation), leaving the agent to infer which tool to use.

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