geometry_import

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

Without annotations, the description must fully disclose behavior. It only states the basic import action and supported formats, but fails to mention whether the tool overwrites existing geometry, requires a current model, or how it handles errors (e.g., invalid file path). The return value is vaguely described as 'Import operation info', offering no concrete behavioral detail.

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 concise (4 lines excluding header) and front-loaded with the main action. The parameter list is readable but uses plain text without bullet formatting, which could be improved for clarity. Every sentence adds value, with no redundancy.

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 no annotations, no output schema, and 4 parameters with 0% schema coverage, the description is incomplete. It lacks details on prerequisites (e.g., must a model exist?), error handling, and return value structure. The tool interacts with files and likely has side effects (e.g., modifying the current model), but these are not mentioned.

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?

With 0% schema description coverage, the description adds some value by labeling each parameter: file_path, geometry_name, import_type, model_name, and noting defaults (e.g., model_name defaults to 'current model'). However, it does not provide valid value examples for import_type (e.g., 'CAD', 'mesh') or clarify geometry_name's format, leaving gaps for the agent to infer.

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 clearly states 'Import geometry from a CAD file' and lists supported formats, distinguishing it from sibling tools that create primitives (e.g., geometry_add_block) or manipulate geometry. The verb 'import' and resource 'geometry from a CAD file' are specific and unambiguous.

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 use when a CAD file is available and lists supported formats (STEP, IGES, STL, NASTRAN, etc.), providing usage context. However, it lacks explicit exclusions or comparisons to alternative geometry creation tools, such as geometry_create or geometry_add_*. This leaves the agent to infer when to import versus build from scratch.

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