analyze_mid_print_impact

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

No annotations exist, so the description carries the full disclosure burden and fails: it never says whether the call is read-only or mutates state, whether it writes to engine_output_dir, or what a result looks like. The only real behavioral disclosure is the entitlement requirement 'Requires Kiln Pro', which is useful but far from sufficient for a 4-param tool touching gcode and output directories.

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 one useful clause is front-loaded, but roughly two-thirds of the text is pricing copy and a marketing link rather than tool semantics. That is wasted space in a definition that needs the room for parameter and behavior disclosure.

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 four undocumented parameters, no annotations, and no output schema, the description should explain inputs, side effects and results; instead it explains none of them and substitutes a feature-tier pitch. An agent could not reliably invoke this tool from the definition alone.

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 coverage is nominally 100%, but every parameter 'description' is a placeholder like 'Default: ""' or 'Default: 0.0.', conveying no semantics. The tool description adds nothing about what session_id, carved_gcode_path, engine_output_dir, or requested_depth_mm mean or how they interact, so an agent cannot resolve them from either source.

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 phrase 'Pre-commit truth gate: which layers will actually change' gestures at a diff/preview of layer impact, but never states plainly that this analyzes mid-print edit consequences. The remainder of the description is a Pro upsell, and nothing distinguishes it from the many sibling tools about mid-print edits (add_feature_during_print, decorate_during_print, revert_mid_print_fleet).

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?

Only the word 'Pre-commit' implies timing, suggesting it should be run before committing a mid-print change. There is no explicit when-to-use statement, no prerequisite (e.g., an active print session or a carved gcode), and no naming of alternatives such as revert_mid_print_fleet or generate_recovery_gcode.

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