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

With no annotations, the description carries the full burden and discloses the key non-obvious behavior: the tool returns a generation_id immediately and requires polling, with typical 30–90s latency per variant. It also sets expectations by noting finished assets include measured stats and compliance warnings, though it omits quota costs and failure behavior.

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 sentences with no wasted words: action, async polling contract, and style guidance are all front-loaded and each sentence carries distinct information. The size is proportionate to the tool's complexity.

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 an async generation tool with no output schema and no annotations, the description covers the call flow, polling, expected latency, style options, and result contents. It is complete enough for correct invocation; only failure modes and quota impact are left to the schema or discovered at runtime.

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. The description adds value beyond the schema by linking the low-poly default to the 10k triangle target and attaching per-variant timing, which helps an agent choose sensible parameters.

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 states a specific action ('Generate a Roblox-ready 3D asset') and the input ('from a text prompt'), making the tool's core purpose unmistakable. It does not explicitly distinguish itself from sibling generate_variants, so it stops one step short of full 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?

It gives clear usage context: call this to create an asset, poll get_generation until completion, and expect 30–90s per variant. It does not state when not to use it or name alternatives such as generate_variants, but the intended workflow is sufficiently clear.

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