check_print_readiness

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

Annotations only say readOnlyHint=false and destructiveHint=false, so the description must carry the weight, and it does explain that auto_fix 'repairs degenerate triangles, closes holes, and removes floating regions' plus how can_print is derived. The notable gap is that it never says whether the source file at file_path is left untouched when output_path is empty, which matters for an operation framed as non-destructive.

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 lead sentence is well front-loaded, but the middle is a dense run-on enumerating five verdict values in a single paragraph, and the :param: block at the end is pure duplication of a schema that is already fully documented. Useful content is present but the structure is heavier than needed.

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 no output schema, the description does the necessary work of defining every verdict enum value and explaining that can_print is true only when the mesh is sound and Kiln's verdict permits printing. It is close to complete for an 8-parameter tool; only the file-write/in-place behaviour when auto_fix is set remains unstated.

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 100%, so the schema already documents every parameter, including printer_id ('printer intelligence supplies the build volume') and material. The description's :param: block reproduces those same strings verbatim rather than adding new meaning, so the baseline of 3 applies.

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 first sentence names a specific verb and resource ('print readiness check') and the body enumerates exactly what is validated: parseable, manifold, no floating regions, no degenerate triangles, fits the build plate. It also explicitly distinguishes itself from siblings by noting that it 'reads ``analyze_printability``'s verdict' and that '``validate_and_prepare`` runs the full pre-print pipeline.'

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 this tool is appropriate (single-call soundness plus verdict, with the full pipeline delegated to validate_and_prepare) and states that auto_fix must be True to attempt repairs. It stops short of explicit 'use X instead when Y' routing, and never mentions other near-neighbours such as preflight_check or may_i_print, but the alternative relationships it does name are unambiguous.

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