DFM Check

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

Annotations only provide readOnlyHint and openWorldHint, so the description carries the full behavioral burden. It discloses violation definitions, process-dependent thresholds, handle-side measurement methods, delegation to sheet_check, and how sheet failures gate the final pass. There is no contradiction with the readOnlyHint; the tool screens and returns results without mutating anything.

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 long but dense and well-organized: general mechanics, sheet-metal specifics, then return shape. It front-loads the purpose and avoids filler. A little more restraint would improve readability, but almost every sentence carries necessary technical detail.

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 seven optional parameters, no output schema, and multiple input paths, the description is unusually complete. It documents the return fields, which sub-results appear on which path, how sheet-metal failures affect pass, and the relationship to sheet_check. An agent has enough information to invoke the tool correctly without guessing.

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?

Input schema has 0% description coverage, so the description must compensate, and it does extensively. It defines the faces list structure, the live handle semantics, the sheet block fields, process-dependent min_wall_mm defaults, and exact violation formulas. Minor details like accepted process strings and pull_axis format are left to defaults, but the core meaning of every parameter is effectively documented.

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 opens with a specific action and scope: 'Screen a part for manufacturability against a pull/tool axis.' It clearly defines the three input modes and distinguishes this tool from sheet_check by stating that the press-brake rules are delegated to the same implementation sheet_check calls. An agent can tell what dfm_check does and how it differs from related screening tools.

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?

It explains when to provide a faces list, when to provide a handle, and when to pass an explicit sheet block, including the sheet-metal special case. It explicitly names sheet_check and notes the two tools share the same implementation and cannot disagree. It does not fully contrast dfm_check with broader siblings like dfa_check or moldability_check, but within its stated domain the usage guidance is clear.

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