import_file

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

There are no annotations, so the description carries the full load and does it reasonably well: it discloses the CAD→occurrence / mesh→body mapping and, importantly, that a failed import is atomic ('leaves the design as it was'). It omits where the path must resolve (local vs server filesystem) and any size/format limitations, which matters for a file-IO mutation.

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?

Front-loaded with purpose and format list, then behavior, then return shape, then a short example — a sensible order with little waste. The inline JSON return sketch is slightly dense but earns its place given there is no output schema.

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 annotations and no output schema, the description compensates by explaining the return structure and the atomicity guarantee. The remaining gap is operational: how the path is resolved and whether the target component must already exist before import.

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 100%, so all four parameters are already documented, establishing a baseline of 3. The description adds only marginal meaning: the implicit root default for target and the example path, while mesh_units and explicit format override are left to the schema.

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?

States a specific verb (import) plus the resource and enumerates the accepted formats (STEP, IGES, SAT, SMT, F3D, STL, OBJ, 3MF). It also distinguishes the two outcomes — CAD files become occurrences, meshes become mesh bodies — which no sibling tool claims.

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 implied by 'into a component of the active design' and the CAD-vs-mesh split, so an agent can infer when this is the right call. But no alternates or exclusions are named (e.g. when to prefer assembly_add_occurrence or form_create_from_tsm instead), leaving the agent to guess.

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