preview_kit

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed world, so the safety profile is covered. The description adds meaningful context — the output is a rider/kit preview in the game's visual style and is meant to be compared against a reference — but it never says what is returned (images, paths, count), whether rendering is slow or costly, or where output goes.

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 purpose sentence is front-loaded and the view definitions earn their place, but the text is jammed into run-on lines with embedded definitions ('front34_left = ...') and inconsistent casing ('body:') that make it harder to scan than necessary. Little is wasted, but the structure is loose rather than tight.

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?

With no output schema and no annotations about return payload, the description should say what an agent gets back (rendered images, file references, counts) and what the kit input must look like. It covers the workflow and two parameters reasonably but leaves the required kit format and the return shape unspecified, which are exactly the gaps a preview/render tool needs filled.

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 0%, so the description must carry the parameter burden. It does real work for two of three params: body is constrained to 'male'/'female' and views gets a full enumeration plus a concrete default (front, front34_left, back) that the schema does not express (schema default is null). But the required 'kit' parameter — typed only as anyOf object/string with additionalProperties true — is never explained, leaving the most important input undefined.

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 conveys that this produces a visual render of the kit on the game's rider model ('in the game's look'), which is a distinct resource from siblings like get_kit_spec or validate_kit, and it explicitly names compare_to_reference as the follow-up step. However, it never uses a direct verb (render/produce/generate), so the agent infers the action from the name plus phrasing rather than being told outright.

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 workflow context: use this, then follow with compare_to_reference and fix what differs — an explicit sequencing cue that no sibling states. It does not state when NOT to use this tool (e.g., after edits vs. before) or explain prerequisites for the kit argument, so it stops short of full when/when-not guidance.

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