model_check

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

With no annotations, the description carries the full burden and does substantial work: it discloses computation method (exact boolean volume for moderate parts, voxel estimate for big ones), what is excluded (weld bead and joined parts, touching faces, rest-state overlaps in motion mode), and that look:true produces a rendered image. It stops short of stating cost, accuracy limits of the voxel estimate, or preconditions, which keeps it from a 5.

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?

Information-dense and front-loaded: the core capability comes first, then motion, then look. Parentheticals are heavy but each clause adds real constraints rather than filler; there is no wasted preamble.

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?

The absence of an output schema is offset by the description explaining what is reported (overlapping pairs with volumes, first contact during the sweep, or a rendered picture). The main completeness gap is the undocumented layout parameter and the unspecified preconditions for running a check.

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 0%, so the description must compensate. It partially does: it spells out the shape of the motion object and its intent (sweep that joint, report first contact) and explains look:true (picture with overlaps in red). But the nested motion fields (id, key, from, to, steps) are named without meaning, and the layout parameter and its enum values are never mentioned at all.

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 capability: reporting which parts overlap and by how much, plus an optional motion sweep for first contact. That is clearly distinct from query/describe siblings in substance, but it never names or contrasts an alternative, so the agent must infer that model_query or model_describe is not the right choice for geometric interference.

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?

Usage is only implied through conditional phrasing ('With motion:... it also sweeps', 'look:true returns a picture'). There is no explicit statement of when to prefer this over sibling query tools, no prerequisites (an open model, built parts), and no exclusions such as cost for large assemblies.

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