Loading ToolBench
Blockbench MCP server: let AI (Claude, Cursor) create Minecraft models, textures, rigs and animations in Blockbench, take screenshots, install plugins and more.
Server has 6 tools with mostly complete schemas and descriptions. Naming follows verb_noun convention (get_*, check_*, request_*). Descriptions are detailed and context-aware (avg ~250 chars), exceeding the 194-char baseline. However, several tools lack explicit input parameter descriptions in their schemas, and error handling guidance is minimal. The `request_review` tool description is truncated mid-sentence. Output schemas are not formally documented. Tool composition is sound (each does one thing), but parameter validation and recovery guidance are weak.
Audit every left/right NAME in the model against the actual geometry. Catches the classic failures: a bone called arm_right sitting on the model's left, a mirrored pair that ended up on the same side, and limbs with no counterpart. Run it after building or mirroring anything symmetric, and again before you tell the user a left/right request is done.
Return a playbook. Pass `topic`: 'modeling' (default — proportions, detail, rotation), 'detailing' (the cube budgets and the 4-layer doctrine that stop models coming out as 15 boxes — read it before building anything with a costume, armour or cloth), 'orientation' (which side is the model's LEFT — read before anything with a left and a right), 'rigging' (bone hierarchy, joint origins, why 2-bone limbs animate like cardboard), 'texturing' (the smooth @volmur/Hytale look), 'vfx' (pixelated flames/energy/projectiles), 'animation' (axis signs, gaits, easing, the measure-then-review loop), 'review' (how to get the user to confirm work instead of declaring it good yourself), or 'reference' (how to ACTUALLY match a reference image). READ the relevant topic BEFORE building/rigging/texturing/animating — it dramatically improves results.
THE left/right authority for this model — call it before rigging, mirroring, attaching an item to a hand, or interpreting any render. Returns which way the model faces and which world axis is the model's OWN right and left (Minecraft models face -Z, so the model's right is +X), plus the trap that causes most mistakes: a front-view render shows the model MIRRORED (its right hand appears on the LEFT of the image), exactly like facing a person. Also returns the rotation-sign cheat sheet (+X swings a hanging limb FORWARD, tips an upright torso BACKWARD; +Y turns the model to its own left).
request_review description is truncated mid-sentence ('Call it after every user-visible milestone: the bloc'), making it incomplete and unhelpful for LLM tool selection.
No output schemas documented. Tools return JSON via callBlockbench() but LLMs cannot see what fields to expect (e.g., does get_status return {cubes: N, groups: N, ...}?). This forces LLMs to guess field names for downstream reasoning.
Parameter descriptions missing or minimal. The 'element' param in which_side says 'uuid or name of the cube/bone' but does not explain what happens if the element is not found, or what format the response uses.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Get the current Blockbench state: open project, format, counts of cubes/groups/textures/animations, and edit mode. Call this first to understand the workspace. If you are about to BUILD or TEXTURE a model, call get_guide first. If the user is matching a REFERENCE image (they may have dropped one into the MCP Copilot panel), call get_reference to see it, build, then call compare_reference every pass until match_percent is high — do not judge the match by eye.
SHOW THE USER and WAIT for their verdict — the honest alternative to looking at your own screenshot and declaring it good. Renders labelled views (or animation poses) and posts them as a card in the MCP Copilot panel inside Blockbench, then waits a SHORT window for the user to press 'Looks right' / 'Needs changes' and optionally type a comment. If they haven't answered yet it returns `pending: true` with a `review_id` — the card stays open, so call wait_review with that id to keep waiting (that loop is how a minutes-long human review fits inside an MCP client's per-request timeout). Call it after every user-visible milestone: the bloc
Answer 'is this bone the model's left or right?' for one element, from its coordinates rather than from a picture. Use it before parenting a sword/shield/prop to a hand, or whenever the user says left/right. Returns the side, the signed coordinate, and whether the element's NAME agrees with where it actually is.
No error handling guidance. Tools do not document what errors are possible (e.g., 'element not found', 'no project open'), how to recover, or whether errors are retryable. LLMs cannot self-correct.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are not present in tool definitions. All tools are marked READ_ONLY in comments but not in schema metadata, so clients cannot programmatically detect safety properties.