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

With no annotations, the description carries the full burden and discloses substantial behavior: it produces a 3D model, 2D DXF, bill of materials, and engineering checks, and it details the calculations performed for each machine type. It also states the per-call credit cost. It does not cover permissions, rate limits, or error behavior, but for a design-generation tool this is a strong disclosure.

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 front-loaded with the tool's purpose and outputs, then efficiently enumerates machine-specific parameters in a dense but readable format. It is appropriately sized for a complex multi-mode design tool, though the semicolon-heavy list format could be slightly clearer.

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?

Given the absence of annotations, output schema, and schema parameter descriptions, the description supplies the essential context: outputs generated, calculations performed per machine type, and required nested parameters. It omits the role of the 'material' enum and any error or prerequisite behavior, but is otherwise complete enough for correct invocation.

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 0%, so the description must explain parameters. It provides detailed nested parameter meanings and expected values for all three machine modes (e.g., input_rpm, input_torque_nm, ratio for gearbox; ground, crank, coupler, rocker for four_bar). It does not explain the top-level 'material' or 'title' parameters, leaving a small gap.

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 states a specific design verb and resource: 'Design a working mechanism with 3D model, 2D layout DXF, bill of materials and engineering checks.' It also enumerates three machine types and their outputs, making the tool's scope clear. However, it does not explicitly differentiate itself from sibling CAD tools such as cad_build, cad_part, or cad_calc.

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 implies usage by listing supported machine types and their parameter sets, and notes the cost of '1 credit per call.' It does not state when to choose this tool over siblings like cad_build or cad_part, nor does it provide when-not-to-use guidance.

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