Create Azure Kinect body bus

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

Annotations already indicate readOnlyHint=false, openWorldHint=true, and destructiveHint=false. The description adds that it creates a scaffold with placeholders and calibration notes, which gives some context about what gets generated. However, it does not disclose side effects, requirements (e.g., a connected device), or what 'stream maps' entail, so it adds only modest context beyond the annotations.

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 a single, well-structured sentence that immediately states the core function and includes key components. There is no filler or redundancy, making it highly concise and easy to parse.

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?

Despite having 7 parameters and no output schema, the description provides only a high-level overview. It does not explain how parameters influence the scaffold, what the generated network includes beyond vague 'stream maps,' or any required setup or environmental context. The one-sentence description is insufficient for the complexity of the tool.

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 only 29% (2 of 7 parameters have descriptions), and the tool description provides no additional parameter explanations. It does not clarify the role of body_count, device_index, include_color_top, or include_depth_top. With low schema coverage, the description should compensate but does not, leaving parameter semantics inadequate.

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 verb ('Create') and resource ('Azure Kinect body/depth scaffold'), and adds concrete details (TOP/CHOP placeholders, stream maps, calibration notes). This distinguishes it from other depth-camera or body-tracking tools like create_zed_depth_bus or create_nuitrack_body_bus.

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 name and description imply the tool is for Azure Kinect hardware scaffolding, but there is no explicit guidance on when to use it over alternatives (e.g., other depth buses) or when not to use it. Usage is implied by the hardware-specific wording but lacks clear exclusions or alternative references.

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