geometry-convert_to_mesh

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action (convert non-mesh to mesh) but does not disclose side effects: what happens to the original object when keep_original=false (likely deleted or replaced), whether the conversion is destructive, any prerequisites (e.g., object must be convertible), or performance implications. The description lacks this essential context for a potentially destructive 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?

The description is a single, concise sentence that is front-loaded with the core purpose. It is efficient with no wasted words. However, it may be slightly under-specified given the missing behavioral and parameter details, but as a concise purpose statement it earns a 4.

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 tool has 3 parameters, one required, no annotations, and no output schema, the description is incomplete. It does not explain conversion limitations (which geometry types are supported), the effect of keep_original (whether the original is deleted or preserved), or the return value (success message or new mesh name). For a tool that is likely destructive and has multiple options, the description lacks critical operational context.

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 should compensate. However, the description adds no parameter information. The schema shows three parameters: name, object (required), keep_original. The description's mention of 'non-mesh geometry object' somewhat clarifies the purpose of the object parameter but provides no guidance on name (optional converted mesh name) or keep_original (keep source object and create a copy). Since parameter info is entirely absent in the description, and schema coverage is 0%, a 3 is generous but reflects that the object parameter's role is implied by the description, and the other two are self-explanatory from their titles/defaults.

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 'Convert a non-mesh geometry object to a mesh' uses a specific verb (convert), a clear resource (non-mesh geometry object), and states the intended result (to a mesh). It distinguishes from siblings like geometry-create_curve or geometry-report by focusing on conversion to mesh, and complements the geometry_node tools which modify meshes via nodes.

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 when to use: when a non-mesh geometry needs to become a mesh. But it does not explicitly state when not to use (e.g., not for mesh conversion of already-mesh objects, or alternatives like modifiers or geometry nodes). The context of Blender's geometry domain is implied but not elaborated. A 3 is appropriate as it provides clear context but lacks explicit exclusions or alternative guidance.

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