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

With no annotations, the description carries the full behavioral burden. It discloses useful traits: required prior resource reads, a Pro-plan entitlement gate for in-action/commercial output, that parameters must be resolved through adgpt_capabilities, and that wizard state is persisted. It does not distinguish read actions (plans, getWizardState, voicePreviewStatus) from mutating ones (saveWizardState, tagScript), nor mention side effects, cost, or async polling behavior for the generate/voice actions.

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?

Prerequisites and the plan gate are buried mid-paragraph rather than front-loaded, and the 'Actions: ...' sentence repeats the input schema enum verbatim, which earns no credit per the structured-data rule. The content is dense and mostly necessary, but the ordering and the redundant enum listing cost it a point.

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?

This is a nine-action multiplexer with a generic passthrough `params` object, no output schema, and no annotations, so the description has to do a lot. It covers prerequisites, entitlement, and parameter discovery, which are the essentials for calling it, but nothing describes per-action intent or return shape, leaving the agent dependent on adgpt_capabilities for every action's meaning.

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 50%: `action` is fully enumerated in the schema, but `params` is an opaque free-form object. The description compensates in exactly the right way by telling the agent to call adgpt_capabilities with the operationId to learn an action's parameters, which is the only real path to correct `params` values. It adds no per-action parameter hints of its own, so it is adequate rather than rich.

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+resource framing: a 'talking-head / UGC-in-action wizard for a SAC campaign' that generates scripts, strategies, per-character plans, previews voices, tags scripts, and persists wizard state. It names the concrete capabilities rather than restating the title, so an agent knows what class of work this handles. It does not explicitly contrast itself with the sibling adgpt_ugc tool, which is the most likely source of confusion in this cluster.

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 states concrete prerequisites ('Read adgpt://pipeline/characters and adgpt://pipeline/voices first'), a gating condition ('In-action and commercial videos need a Pro plan or higher'), and a discovery route ('Call adgpt_capabilities with the operationId to see an action's parameters'). That is real when-to-use guidance. It lacks an explicit when-not or a direct comparison against adgpt_ugc, keeping it short of a 5.

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