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

Beyond the annotations (which already flag destructive=true, idempotent=true, openWorld=true), the description adds substantive behavior: this call actually spends quoted credits, it retains exact source and identity snapshots, and it explicitly does not approve creative or launch ads. That cost and scope-boundary disclosure is exactly the kind of context annotations cannot carry. It stops short of describing failure/partial-failure behavior or how the durable renderer behaves on retry.

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, no filler, and the most important fact — that this spends credits — is placed early. The phrasing "owned durable renderer" is somewhat internal jargon that costs a little clarity without adding information an agent can act on.

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, and the annotations plus the credit/snapshot disclosure cover the safety and cost profile of this destructive, open-world operation. What remains missing is guidance on the required prior quote, the meaning of the revision/fingerprint/request_key parameters, and what happens on an insufficient-budget or stale-revision failure — significant for a six-parameter mutation tool.

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 only 50%, and two of the six parameters — work_id and the entire nested arguments object (operation_id, variant_id, expected_edit_revision, fingerprint, max_credits, output) — carry no schema description at all. The description might loosely gesture at max_credits via "accepted budget" and at fingerprint via "identity snapshots", but it never explains revision pinning, request_key idempotency, or the output kind/frame choice. It does not compensate for the coverage gap.

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 gives a specific verb and resource ("Export the quoted creative") and qualifies it with the renderer used, so an agent knows this is the export step that consumes a prior quote rather than a quoting or reporting tool. It does not, however, name or distinguish itself from the many adjacent siblings such as native.genads_quote_export, native.genads_export_pack, or native.genads_pack_export, leaving some ambiguity in a crowded namespace.

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?

"Only act within the creator's deliberate production request and accepted budget" is a real precondition, and "spends the quoted credits" implies a quote must already exist before calling. But it never states the explicit prerequisite step (native.genads_quote_export) or when to choose an alternative export sibling, so the when-to-use logic is inferred rather than stated.

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