Generate PBR textures for a mesh you already have

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

The description is richly transparent. It discloses cost ('SPENDS 3D CREDITS'), non-destructive behavior ('keeping its geometry untouched'), asynchronous operation with explicit polling instructions ('poll get_asset_job until "ready", then download_asset'), and a critical provider limitation with a fallback. These details go well beyond the annotations (readOnlyHint=false, destructiveHint=false, etc.) and give the agent a clear behavioral model.

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?

The description is substantial but every sentence serves a purpose: cost warning, function, use-case justification, input methods, material direction rule, async flow, and provider caveat. It is front-loaded with the cost and core purpose, and while it is longer than average, the information density justifies the length. The structure is logical and scannable.

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 tool with 10 parameters and nested objects but no output schema, the description covers the essential operational flow: how to provide the mesh, how to direct the material, how to handle the async result, and a failure case. It does not detail output structure, but that is handled by the referenced job flow. The description is complete enough for an agent to invoke correctly without reading the entire schema.

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 description clarifies the most important parameter interactions: the mutual exclusivity of prompt and styleImagePath ('EITHER prompt OR styleImagePath, not both') and the two valid inputs for the mesh (modelPath or originalAssetJobId). With 70% schema coverage, this adds critical value beyond the schema, though it does not explain every parameter (e.g., textureSeed, modelVersion), which is acceptable given their optional nature.

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 clearly states the tool's function: applying newly generated PBR materials to an existing mesh while preserving geometry. It specifies the resource (existing mesh) and the action (apply materials), and distinguishes itself from sibling tools like create_3d_asset by explicitly framing the use case as 'when you already own a model and only the materials are missing or wrong.' This makes the purpose unambiguous.

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?

The description gives explicit instructions on when to use the tool (existing mesh, missing/wrong materials) and why it's preferable (cheaper, preserves geometry). It also explains two ways to provide the mesh and a fallback for provider limitations. However, it does not explicitly name alternative tools (e.g., create_3d_asset for new meshes) or state when NOT to use it beyond the implied existing-asset condition, so it falls short of a 5.

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