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

The description discloses that the tool is experimental and unstable, may return only partial text or an empty response even when the upstream run succeeds, and costs 3 MESH/call. These details go well beyond the annotations, which only indicate readOnlyHint false, openWorldHint true, and destructiveHint false.

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?

The description is concise, with each sentence adding value: purpose, required inputs, caveat, and pricing. The opening repeats the title slightly, and the 'market wrapper' phrasing is a minor clarity stumble, but overall it is efficient.

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 tool with one nested parameter and no output schema, the description covers the key inputs and the risk of unstable output. However, it omits the exact payload structure (how fields nest under 'input') and any detail about successful output format beyond 'ready-to-post copy', which an agent would need for reliable invocation.

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?

The schema only provides a generic 'input' object with unrelated examples, but the description compensates by naming the concrete fields: target.handle, target.platform, target video context, and brand. It does not specify the exact nesting or types, so not a 5.

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 states it is an experimental duet or stitch ideation wrapper and lists required inputs, making the purpose clear. However, it uses a noun phrase rather than an explicit verb like 'generate', and 'wrapper' is somewhat vague, though still distinguishable from sibling tools.

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 explicitly says to buy it for pipeline testing and not for guaranteed ready-to-post copy, which gives clear when-to-use and when-not-to-use guidance. It does not name specific alternatives, but the exclusion is clear enough.

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