Refine Text-to-3D Preview

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

Annotations already declare the non-read-only, non-idempotent, non-destructive profile, but the description adds material behavior the annotations do not carry: the credit cost, the requirement to obtain user approval first, and the model-inheritance rule when ai_model is omitted. It does not restate that each call creates a new task, though that is implied by the example.

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?

Three tight sentences: the action, the cost/approval constraint, then the model-inheritance rule, followed by a compact example. No filler, and the most decision-relevant information (what it operates on, cost, approval) is front-loaded.

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?

With an output schema present, return values need no explanation, and the description covers the pipeline stage, cost, approval gate and model inheritance for a 13-parameter tool. The only minor gap is that it does not state the call is asynchronous and yields a task to poll, though the sibling meshy_get_task_status and the output schema make this inferable.

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 100%, so the baseline is 3, but the description goes beyond it by surfacing the key default behavior ('omit ai_model to inherit the preview's model') and giving a concrete example payload that shows how preview_task_id, texture_prompt and enable_pbr are combined. That is useful guidance layered on top of an already complete schema.

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 precise verb and resource ('Texture a SUCCEEDED meshy_text_to_3d preview') and pins the pipeline position by requiring a SUCCEEDED preview, which cleanly separates it from meshy_text_to_3d (creates the preview) and meshy_retexture. An agent can pick this tool without opening the schema.

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 a clear precondition (preview must be SUCCEEDED), a cost gate (10 credits, 15 at 8K) and an explicit approval requirement before calling. It stops short of naming sibling alternatives such as meshy_retexture or meshy_remesh for existing assets, so it is strong but not exhaustive.

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