uv_report

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

No annotations are provided, so the description carries the full behavioral-disclosure burden. It says it measures and reports but does not state whether it modifies UVs, whether it requires an active layer or selected objects, whether it fails on un-unwrapped meshes, or how results are returned. It mentions numeric thresholds for interpretation, which is helpful context, but the core behavioral profile of a measurement tool on a 3D scene is undisclosed.

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?

Two sentences: the first enumerates the measured metrics, the second gives interpretive thresholds. Front-loaded with the core purpose and no wasted words. Well-sized for the amount of information conveyed.

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?

There is no output schema, so the description must convey what a caller gets back; it lists metrics but not the return format (e.g., per-object report, numeric fields). With no annotations and partially documented parameters, a measurement tool should say more about applicability (which meshes, required state). It is adequate but leaves real gaps.

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 50%: 'objects' has a description ('Object name or list of names.') while 'layer' has none. The tool description does not explain what 'layer' means or how objects and layer interact (e.g., whether layer scopes the measurement). The description adds no parameter guidance, so it neither compensates for nor extends the schema.

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 a specific measurement task: 'Measure UV quality'. It then enumerates the metrics it returns (islands, packing efficiency, stretch, angle error, texel density spread, seam length, overlaps), making the purpose concrete. It is distinguishable from the nearest sibling uv_unwrap (which modifies UVs) since this clearly reports on them, though it does not name that sibling explicitly.

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 implies a use case: evaluating whether existing UVs are good for games, and it provides numeric thresholds (stretch < 3 %, efficiency > 55 %). However, it does not state when to use this versus uv_unwrap or other quality tools, nor what prerequisites (e.g., UVs must already exist) are required. Usage is inferred rather than stated.

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