create_retexture_task

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

With no annotations, the description carries the burden and does disclose defaults (enable_original_uv default true) and enum values for ai_model, plus the exclusive-parameter constraints. It omits key behavior: this appears to be an asynchronous task creator whose result must be fetched via retrieve_retexture_task/stream_retexture_task, and it says nothing about cost, balance, or failure modes.

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?

Dense and front-loaded: purpose first, then input sourcing, then style guidance, then tuning flags. Every sentence adds facts; there is no filler, though the wall of semicolon-separated clauses is a little hard 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?

Covers inputs thoroughly but not the calling contract: no output schema exists, yet the description never says a task ID is returned or that the job is asynchronous and must be polled via the retrieve/stream siblings. For a create-task tool in a large async task family, that is the main missing piece.

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?

The input schema exposes zero properties, so the description is the only source of parameter meaning, and it supplies names, accepted values, formats (.glb/.gltf/.obj/.fbx/.stl), length limits (600 chars), and defaults. It carries real weight, though coverage may be incomplete relative to the documented parameter set.

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 and resource: 'Apply new textures to a 3D model using text or image style guidance.' An agent can distinguish this from create_text_to_3d_task or create_text_to_texture_task on the concept level, though the description never names or contrasts those siblings explicitly.

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 useful input-combination rules (either input_task_id or model_url; either text_style_prompt or image_style_url, mutually exclusive), which is genuine selection guidance. But it says nothing about when to choose retexture over the sibling create_text_to_texture_task or text-to-3D pipelines, and no prerequisites are stated.

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