Generate a 3D mesh

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

With no annotations, the description carries the full burden and it does well: it discloses that it writes a GLB plus a .json sidecar containing the parameters, inputs, and raw Space response, which is exactly the side-effect information an agent needs. It omits runtime/cost expectations (a 450k-face generation is presumably slow) and whether existing files in out_dir are overwritten.

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 short sentences with zero waste: purpose first, model trade-off second, artifacts written third. Every sentence earns its place and the information 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?

Output schema exists, so return values need not be described, and the sidecar/GLB output is covered along with the two backend choices. The remaining gap is operational — long-running generation, failure modes, and file-overwrite behavior — which for a file-writing generation tool would be worth one more sentence.

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 earns more by explaining the 'model' enum substantively — trellis yields a textured low-poly GLB, hunyuan an untextured high-poly shape — which the schema's terse 'Which Space to use' does not convey. It adds little for seed, out_dir, or extra_views beyond the schema text.

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 first sentence names a specific verb and transformation ('Turn an image into a raw 3D mesh'), and the word 'raw' implicitly places it before render_mesh in the pipeline. It does not explicitly name a sibling as an alternative, so it falls short of the 5 bar for sibling differentiation.

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?

There is no explicit when-to-use statement or exclusion relative to siblings like render_mesh or generate_image. However, the trade-off between the two backends ('textured GLB at ~30k faces' vs 'untextured shape at ~450k faces') conveys implied guidance for choosing a model, which is more than nothing.

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