Generate 2D Image from Text

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

Annotations only declare the safety profile (readOnly=false, openWorld=true, idempotent=false, destructive=false); the description adds latency (~30 s), per-model credit costs, and cross-parameter behavioral constraints such as remove_background having no effect on multi-view output. This is meaningful behavior an agent cannot derive from the structured fields.

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?

Front-loaded with the purpose and latency, then cost, then routing, then a compact example — every element is actionable and nothing is padded. The cost enumeration is dense but it is the information needed for model choice.

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; the description still covers the workflow chain (this task -> image_to_3d / multi_image_to_3d), cost tradeoffs, timing, and the multi-view/aspect-ratio interaction. Nothing an agent needs to invoke this correctly is missing.

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 100%, so the baseline is 3; the description goes beyond it by pairing each ai_model enum value with its credit cost, which drives model selection, and by giving a concrete example object showing prompt, ai_model, generate_multi_view and pose_mode together. Cross-parameter exclusions are repeated from the schema rather than added.

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?

States a specific verb+resource ('Generate a 2D image from text') and frames the artifact as a 2D design stage preceding 3D, which distinguishes it from the 3D siblings in the same family. It does not explicitly contrast with the closer sibling meshy_image_to_image, so differentiation is good but not complete.

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?

Gives clear context for when to reach for it (produces a design for user approval before 3D) and routes the next step explicitly to meshy_image_to_3d with input_task_id = this task, or meshy_multi_image_to_3d for multi-view output. Missing are exclusions ('use X instead when you already have an input image'), which would make it a 5.

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