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

With no annotations, the description carries the full burden and does substantial work: it explains how `want` is resolved against knob names and option values, notes that a knob name beside a number means a range, beside on/off a toggle, beside a hex a colour zone, and discloses a confidence signal that can be below 'high'. It does not state whether the call is purely read-only, what happens on an unmatched `want`, or how the GLB URL is produced, leaving some behavioral gaps for a tool with zero annotation coverage.

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 output contract is front-loaded in the first sentence, followed by matching semantics and then the confidence caveat, which is a sensible order. Every sentence carries information, though the first sentence is overloaded with four parenthetical examples that could be trimmed.

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 3-parameter tool with a nested object, no annotations and no output schema, the description covers the input semantics well and names the GLB URL return so the agent knows what comes back. Missing are failure modes — invalid id, an unmatched `want`, or what an empty result looks like — which matter because there is no output schema to fall back on.

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% and the description adds real meaning beyond it for the hardest parameter, `want` — it must use vocabulary from the asset's -params.json, is matched against KNOB NAMES and OPTION VALUES, and explicitly not against colour vocabulary. That is non-obvious and prevents a whole class of failed calls. The `look` object is already well documented in the schema, but `id` is left entirely unexplained in both places.

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 concrete transformation: a plain-words request becomes a ready createAsset() call plus a GLB URL of the resulting variant. That is a specific verb-and-output pair an agent can act on. It stops short of naming a sibling (e.g. get_asset or find_matching) as the alternative, so the boundary between this and those tools must be inferred.

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 a clear triggering condition (instances where the user describes a change in their own words) and an operational instruction to check returned confidence and relay applied values rather than presenting a low-confidence match as exact. It also rules out a class of requests — shader effects — and routes them to the asset page. No explicit contrast with get_asset is offered, so it falls short of full when/when-not/alternative guidance.

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