Projector calibration wizard

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

Annotations indicate readOnlyHint=false and destructiveHint=false, which are consistent with a build tool. The description adds useful behavioral context by emphasizing that the tool is rehearsal-safe and does not verify live alignment until run on physical outputs, and by listing exactly what components it generates. This goes beyond what annotations convey.

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 only two sentences, front-loaded with the main action and an efficient colon-separated list of features. It includes the crucial caveat about unverified alignment without wasted words. Every phrase earns its place.

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 purpose, main components, and a key limitation (unverified alignment). It implicitly clarifies that the result is a network built inside the parent_path. With all parameters fully described in the schema, this is nearly complete. However, it does not explicitly state the return value (e.g., reference to the created container), though this is typical for such tools.

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?

All 9 parameters are described in the schema (100% coverage), so the schema does most of the semantic work. The description adds a high-level context by mentioning 'generated grid/crosshair or selected source TOP' (relating to source_path) and per-projector lanes, but it does not provide significant new details beyond schema descriptions. Baseline of 3 is appropriate.

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 uses a specific verb ('Build') and resource ('rehearsal-safe projector calibration network') and enumerates concrete features (grid/crosshair, per-projector crop/corner-pin/level/output lanes, preview layout, notes, brightness/gamma controls). This clearly distinguishes it from sibling tools like create_projection_mapping or create_mpcdi_projection_mapper, which focus on other projection-mapping approaches.

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 establishes a clear context: it is for building a rehearsal-safe calibration network, with the explicit caveat that 'Live projector alignment remains explicitly unverified until run on the physical outputs.' This implies that this tool is not for final alignment/verification, but it does not name alternative tools or provide explicit 'when not to use' guidance beyond that.

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