Loading ToolBench
The server provides 4 boolean operation tools for Blender mesh manipulation. All tools have descriptions and input schemas with typed parameters. However, several critical gaps prevent higher scoring: (1) Tool names lack action-verb prefixes that LLMs expect (booltool_auto_* vs verb_noun convention); (2) Descriptions are adequate but generic, lacking WHEN/WHY guidance for LLM tool selection; (3) Output schemas are minimally documented, responses contain 'object', 'operation', and optional 'warning' fields, but this is inferred from code, not explicitly documented; (4) No error handling guidance, exceptions are caught but responses don't tell the LLM what to do if an operation fails; (5) Parameter descriptions are present but minimal (single line each); (6) No acknowledgment of the destructive nature of these operations (target objects are deleted), no confirmation pattern or dry-run capability.
Auto boolean difference: subtract the target object from the main object. The target object is used as a cutter and removed after the operation. Uses Bool Tool extension if installed, otherwise falls back to native boolean modifier (a warning will be included in the response).
Auto boolean intersect: keep only the overlapping volume of two objects. The target object is removed after the operation. Uses Bool Tool extension if installed, otherwise falls back to native boolean modifier (a warning will be included in the response).
Auto boolean slice: split the main object using the target as a cutter. Creates two separate pieces from the intersection. The target object is removed after the operation. Uses Bool Tool extension if installed, otherwise falls back to native boolean modifier (a warning will be included in the response).
Auto boolean union: merge two mesh objects into one. The target object is consumed and joined into the main object. This is useful for permanently joining meshes so parts don't float away from their bodies. Uses Bool Tool extension if installed, otherwise falls back to native boolean modifier (a warning will be included in the response).
Tool names do not follow verb_noun convention. Names like 'booltool_auto_union' embed tool/library name ('booltool_auto') rather than starting with action verb. LLMs parse 'verb_noun' patterns to infer intent, 'merge_mesh' or 'combine_mesh' would be clearer than 'booltool_auto_union'. Current names obscure the primary action.
Descriptions lack WHEN/WHY guidance for tool selection. All four descriptions state WHAT the tool does but do not explain when to choose one boolean operation over another, or what the expected outcome is in practical modeling workflows. E.g., 'Union merges two meshes; use this when combining separate geometry into a single solid.' Current descriptions assume domain knowledge.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
No output schema documentation. The tools return {'object': str, 'operation': str, 'warning'?: str}, but this is inferred from code analysis. No formal response schema is documented for the LLM to understand what fields to expect or how to chain downstream operations.
Destructive operations (target object deletion) lack confirmation or dry-run support. These tools permanently delete target objects. No confirmation_request pattern is present. An agent could accidentally destroy user geometry without recovery option.
Error handling provides no recovery guidance. Code catches exceptions and may fall back to native boolean modifiers with a warning, but LLM receives no actionable next steps if operation fails (e.g., 'malformed mesh', 'non-manifold geometry', 'no overlap'). Error responses do not categorize as retryable, user-fixable, or fatal.
Parameter descriptions are minimal. 'object_name': 'Name of the main object to keep' and 'target_name': 'Name of the object to merge into the main object' provide no guidance on how LLM should know these names, whether names must be exact, or what happens if an object is not found. No mention of mesh-type requirement until runtime.
Missing tool annotation hints. Tools do not declare destructiveHint (these modify/delete objects), readOnlyHint (false), or idempotentHint (false, repeated calls with same objects produce different state). Agents cannot reason about side effects without these hints.