Convert Model

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

No annotations are supplied, so the description carries the full behavioral burden, yet it says nothing about the fact that this operation writes a file to disk, whether an existing file at the destination is overwritten, or what happens when out_path is left null. The only real behavioral disclosure is the backend dependency for step, which is useful but narrow. For an unannotated file-mutating tool this leaves significant gaps.

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?

Two short sentences with the core verb first and the format inventory immediately after, then the routing guidance. The cheat-sheet framing is compact rather than wasteful. A parenthetical about the cadquery backend is slightly buried at the end where it is easy to miss.

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?

An output schema exists, so return values need not be described, but the definition is still thin for a 3-parameter, unannotated tool with zero schema description coverage. Missing are the input path semantics, the out_path default and overwrite behavior, and the fmt default rationale. The model is left to infer how to invoke it correctly rather than being told.

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 compensate and it largely does not. The format list loosely implies what fmt accepts, but the default of "glb" is never explained, and neither path (input) nor out_path (destination, nullable, default null) has its meaning or default behavior clarified. An agent must guess where output lands when out_path is omitted.

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 and resource ("Convert between mesh formats") and enumerates the supported formats: stl, obj, ply, off, glb, gltf, dae. That is far more informative than the name alone. It does not, however, contrast itself with near siblings such as create_model or inspect_model, so the reader still has to infer the boundary.

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 delivery cheat-sheet gives concrete format-selection guidance (print -> stl, web/game -> glb, archival/CAD -> step). It also explicitly rules out one case — step output requires the cadquery backend and is not handled by this tool — which is a genuine when-not condition. It stops short of naming which sibling or backend tool to use for step output, and says nothing about when a conversion is preferable to regenerating a model with create_model.

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