wan27_image_edit

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

No annotations are provided, so the description carries the full burden. It discloses the output format (URLs, PNG), the 24-hour link expiry, the watermark default, and size constraints for the edit scenario. This gives the agent important behavior it could not infer from the schema, such as prompt length limits and aspect ratio constraints. It does not cover error cases or rate limits, but for a generation endpoint the disclosed behavior is valuable and sufficient.

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 structured as a labeled parameter list with clear bullets. It opens with a meaningful one-line title before diving into parameters. Every sentence adds necessary information: no filler, no redundancies with the schema beyond what is needed for clarity. The list format makes it easy to scan.

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?

Even though an output schema is present, the description goes further by explaining the return structure (URL list, PNG, expiry). It also covers all input constraints and defaults, making the tool usable without external documentation. For a tool with 7 parameters and no annotations, this description is complete in the context of the schema.

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 0%, so the description must fully compensate, and it does. For every parameter (prompt, images, model, size, n, watermark, seed) it adds concrete semantics: prompt length, image count range, data URI format, accepted formats, dimension limits, aspect ratio, file size, model names, size options with the 4K restriction, n range, watermark behavior, and seed range. This is exemplary compensation for a schema that provides no field descriptions.

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 and resource: it performs image editing with multi-image reference using the Wan 2.7 model. Even without sibling tools, the word 图像编辑 (image editing) plus the multi-reference detail makes the purpose unmistakable, and the rest of the description confirms the edit/merge behavior.

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 gives explicit usage guidance on when to choose each model (专业版 vs 更快) and warns that 4K is unavailable for image editing, available only for text-to-image. This is clear and useful for selecting parameters correctly. No sibling tools are listed, so no alternative-tool guidance can be expected, but the coverage within this tool's scope is strong.

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