compare_3d_clouds

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

The description discloses several behavioral traits beyond annotations: EDL is off in split mode, distance colors are based on world-space distance to the right, unmatched points are NaN, paired mode requires equal counts, the one-million point limit, and that changes mark distances stale. It also notes that restored distance fields require explicit computation. Annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description carries the burden and does so well.

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 well-structured, front-loading the primary purpose and then explaining distance behavior, limits, and recompute semantics. Every sentence adds information, though the density makes it slightly harder to parse. It is appropriately sized for a tool with 7 parameters and complex behavior.

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?

Given the tool's complexity (7 params, 3 enums, output schema present), the description covers the key behaviors: split-mode camera linking, distance computation semantics, point limits, staleness, and recompute. It does not explain the output schema's return values, but the presence of an output schema reduces that burden. Minor gaps include not explaining 'detail' or 'status' action behavior, but the overall context is sufficient for an agent to select and invoke the tool 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 description coverage is 0%, so the description must compensate for the 7 parameters. It explains the meaning of max_distance ('nearest within max_distance'), method ('paired uses corresponding decoded order and requires equal counts'), action ('recompute,left=<source> reuses recorded settings'), and left/right ('Distance colors left by world-space distance to right'). It does not explicitly explain scene_id or detail, but the schema's enum names and defaults provide some context. Overall, the description adds significant meaning beyond the raw 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 states a specific verb ('Enable linked side-by-side WebGL views with the same camera') and resource ('3D clouds'), and distinguishes the tool from siblings like align_3d_clouds by explicitly saying 'No alignment is run.' It is clear about the core purpose, though it does not name a specific sibling tool for comparison.

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 clear context for when to use the tool (enabling/disabling linked views, computing distances, recomputing distances) and provides an explicit alternative for recompute ('recompute,left=<source> reuses recorded settings'). It does not explicitly say when not to use it versus a specific sibling, but the action enum and behavior descriptions imply the usage boundaries.

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