remix_image

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

No annotations are provided, so the description carries the behavioral disclosure burden. It mentions that the tool returns a task id and is asynchronous by nature (implying task-based workflow), referencing polling via wait/poll params. However, it does not disclose rate limits, auth requirements, cost implications, or the asynchronous execution model explicitly. It adds modest context beyond the schema.

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 a single efficient sentence that packs the core purpose (create task, API provider, operation) and the return signature without any waste. Front-loaded with the primary action verb. Every word earns its place.

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?

Given no output schema and 2 undocumented params, the description could do marginally more to explain the task lifecycle and how the returned task id relates to get_task. However, with 10 parameters at 80% schema coverage, the schema does most of the documentational work, and the description correctly anchors the async task model. The sibling get_task exists to fill the task-tracking gap.

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 coverage is 80% with 10 parameters, so most parameters are already documented in the schema. The description's mention of return values (task id, status, output URLs) complements the undocumented params like wait, timeout_ms, and poll_interval_ms by situating them in a task lifecycle. For 2 undocumented params (timeout_ms, poll_interval_ms), the description's task-frame reference provides useful context. The description doesn't need to repeat schema details.

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 a specific verb ('Create'), resource ('a Qwen Image task on RunAPI'), and operation ('remix image'), clearly distinguishing it as the remix variant among siblings like text_to_image and edit_image. It also notes the return signature (task id, status, output URLs). It could be slightly stronger by explaining the distinction from edit_image explicitly, but the purpose is clear.

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?

The description implies remix operation (requires source_image_url, mentions 'remix image' in the name), but does not explicitly state when to use this vs edit_image or text_to_image. It does not describe when not to use it or any prerequisites (like needing a public HTTPS URL — though that is in the schema). No explicit alternative guidance is provided.

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