Loading ToolBench
MCP integration for Blockbench: a Claude Code-launched stdio MCP adapter plus a Blockbench desktop plugin for AI-assisted Minecraft Java block/item model editing.
Server has 9 tools with mixed quality. Naming is generally verb-first and clear (get_, create_, upsert_, capture_). Descriptions are present and substantive (avg ~150 chars), meeting the 10-1024 char baseline. However, critical gaps: (1) Most tools lack documented output schemas, LLMs cannot plan downstream calls without knowing return structure. (2) Parameter descriptions are sparse or missing entirely, e.g., create_cubes has input type 'object' with no field documentation; create_geckolib_project similarly lacks parameter detail. (3) No error handling guidance, tools return envelopes with error codes but no recovery hints. (4) Tool definitions are partially inferred from smoke test scripts rather than explicit registration code, capping confidence. (5) No tool annotations (readOnlyHint, destructiveHint) despite clear read/write semantics. Strengths: health and get_plugin_status have clear, complete descriptions; propose_scoped_directory documents its WRITE risk and parameters well.
Capture a frame of a GeckoLib animation as a PNG data URL.
Create cubes in the current Blockbench model.
Create a new GeckoLib model project in Blockbench.
Create a group (bone) in the current Blockbench model.
Retrieve a GeckoLib animation from the current project.
Get the current plugin status including version, blockbench version, protocol version, capabilities, scope state, and geckolib plugin version if available.
Output schemas not documented. LLMs cannot infer what fields tools return, forcing guesswork on downstream tool chaining. E.g., health returns a result object but structure is not formally declared.
Parameter schemas incomplete or missing. create_geckolib_project and create_cubes declare input as bare 'object' with no field documentation. LLMs cannot determine what fields to pass.
No error recovery guidance. Error responses include codes (E_INVALID_PARAMS, E_PLUGIN_NOT_CONNECTED) but no actionable next steps. LLMs receive 'error' but not 'try this instead'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Report adapter status: WebSocket listener state, plugin connection, plugin versions/capabilities, scoped-directory status, and machine-readable setup errors. Read-only; works while Blockbench is closed.
Propose a scoped directory for file access with an optional reason. Returns the scope status after the user confirms or denies the request.
Create or update a GeckoLib animation in the current project.
No tool annotations. Tools have clear read/write semantics (health, get_plugin_status, get_geckolib_animation are READ_ONLY; others are WRITE) but no readOnlyHint or destructiveHint annotations in schema.
Tool definitions partially inferred from smoke test scripts (scripts/smoke-geckolib-animation-frame.mjs) rather than explicit registration in adapter code. Confidence in actual schema is reduced.