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

Annotations already declare non-read-only, destructive, idempotent, closed-world, so the description is not the sole source of safety information. It does add genuinely new behavioral context: frozen source/settings, a server-recorded approval prerequisite, and consumption inside a shared credit ceiling. However, it never says what 'destructive' means here (credits spent, prior media replaced?), nor whether the call returns immediately or starts a job that must be awaited, which is the most important behavior for a generation tool.

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?

Two compact sentences, front-loaded with the verb and the produced artifact, with no redundant restatement of the title. The clause 'using direct native admission or the approved bounded specialist mode' is jargon that costs space without adding actionable information.

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 no explanation, and annotations cover the safety profile. What remains missing for a credit-consuming, destructive generation call is failure/retry behavior, expected latency or job-polling expectations, and the concrete effect of the credit ceiling — gaps that matter given this tool sits among many wait_for_* and inspect_generation_job siblings.

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 100%, so both parameters (proposal_id, request_key) are already documented in the schema itself. The description's references to 'approved' and 'server-recorded approval' loosely reinforce that proposal_id must be an approved proposal, but it adds no new syntax, format, or retry semantics beyond the schema baseline.

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 names a concrete verb and output ('Produce the approved image or video') tied to a resource ('an exact saved clip'), so an agent can tell it is a media-generation tool. It stops short of differentiating itself from closely related siblings such as native.generate_series_media, native.generate_element_take, or native.genads_generate, and the qualifiers 'direct native admission' and 'bounded specialist mode' are opaque rather than clarifying.

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?

No sentence says when to pick this tool over the many sibling generation tools, nor what preconditions must hold beyond 'approved'. The mention of two internal modes ('native admission' vs 'specialist mode') is a routing detail with no stated criteria for choosing between them, so the agent is left to infer usage entirely.

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