generate_hunyuan3d_model

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

With no annotations provided and no output schema, the description carries the full burden of behavioral disclosure, but it only states the operation type. It does not reveal whether the generation is asynchronous, whether it returns a job ID, whether the result must be polled and imported, or what happens if no input is provided. The sibling names strongly imply an async pipeline, but the description leaves this entirely to inference.

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?

A single 10-word sentence that front-loads the verb and packs the key differentiators (engine, input modes). No filler or redundancy. It loses a point only because it is so terse that it omits behavioral context that the score elsewhere penalizes.

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 generation tool with no annotations, no output schema, and zero required parameters, one sentence is not enough. The sibling ecosystem reveals a needed workflow (generate → poll → import) that the description never hints at, and an agent would not know how to obtain or consume the result. This is a meaningful completeness gap for correct 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?

Schema coverage is 100%, so the baseline is 3, but the description misses a critical semantic point: it says 'from text or image' without clarifying that at least one input is required despite 'required: []', or whether the two are mutually exclusive, optional, or composable. The description adds no meaning beyond restating the two input modes the schema already documents.

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 names a specific verb ('Generate'), resource ('3D asset'), engine ('Hunyuan3D'), and both input modalities ('text or image'). This clearly distinguishes it from the Hyper3D generation siblings, though it stops short of explicitly naming those alternatives.

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?

No guidance is given on when to choose this tool over generate_hyper3d_model_via_text or generate_hyper3d_model_via_images, nor any mention of the surrounding workflow (poll_hunyuan_job_status, import_generated_asset_hunyuan). With both parameters optional in the schema, there is also no guidance on which input an agent should supply.

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