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

With no annotations provided, the description carries the full behavioral burden and handles it well. It discloses that matching is against knob names and option values, that the output includes a createAsset() call and GLB URL, and that confidence must be checked and low-confidence matches reported honestly. This goes well beyond the schema and prepares the agent for the tool's real 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?

The description is dense but somewhat rambling; the second sentence runs together multiple ideas ('matched against...', 'use the words...', 'into a ready createAsset() call...') and has awkward grammar. The first sentence is front-loaded and clear, and the confidence check is a useful final instruction, but the middle could be split into tighter sentences without losing information.

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?

The description covers the essential behavior: input semantics, output elements (createAsset call, GLB URL, confidence), and the correct handling of low-confidence results. It also covers the `look` edge case about shaders. It lacks a precise return-shape description or error behavior, but with no output schema present it still provides enough context for an agent to call and interpret results correctly.

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 67%: `want` and `look` are described, while required `id` is not. The description adds important meaning for `want` by explaining it is matched against knob names/option values and not colour vocabulary, and clarifies that `look` restyles independently of knobs and excludes shaders. It doesn't add anything for `id`, but that parameter is fairly self-evident as an asset identifier.

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 job: turn a plain-words request into a ready createAsset() call plus a GLB URL for a variant of a specific asset. It also distinguishes the matching vocabulary (knob names and option values) from colour vocabulary, which helps separate it from related asset tools. However, it could more directly say 'get/return a variant for an asset' instead of relying on the tool name and phrases like 'ready call.'

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 actionable guidance: use terms from the asset's -params.json, and do not use colour vocabulary for `want`. It also explicitly tells the agent to route shader-related requests (Underwater, Dither, Wobble, etc.) to the asset page instead of using `look`. It does not name sibling alternatives like get_asset or search_assets, but the when-to/when-not-to guidance is clear enough for the main decision.

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