Skip to main content
skill CX Codex

blockbench-use — Claude Code skill: Blockbench MCP routing

Tells your agent how to create, edit and export Blockbench content over MCP. Useful once the model is wired to the editor and format guessing starts costing you.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add jasonjgardner/blockbench-mcp-project --skill blockbench-use -a claude-code
Open on GitHub

What blockbench-use does

Load this skill before any Blockbench MCP call that creates, modifies or exports content. The agent starts with get_capabilities: include_tools=true. That call works with no project open and returns host and plugin identity, the current project or null, registered formats and which tools are enabled. So it works against the bundle that is actually running instead of assuming everything described in the source skills is installed.

From there it routes by domain: modeling, UV and texturing, animation, particles, PBR materials, Hytale formats. A small edit does not pull in every section. Before touching content the agent inspects list_outline, list_textures and targeted queries, and prefers UUIDs when names collide. Mesh component keys get checked with get_mesh_info first.

One thing to know up front: before a new model or a real geometry redesign, the skill asks whether you want appearance, performance or a balance. It will not move on to detailed geometry and textures until you answer, because switching shading model or texel density later invalidates UVs. New assets get silhouette and proportions first, detail after. Verification follows the change too — UV values and a mapped checker for unwrap edits, several previews plus the loop seam for animation, not a single rest-pose frame.

What it helps with

  • find out which Blockbench tools are actually enabled right now
  • pick the exact format_id for a target instead of guessing
  • split work across modeling, texturing, animation and particles
  • check UVs and pixel density after an unwrap edit
  • set a geometry budget for appearance or performance

Example prompts for the agent

  • Load the blockbench-use skill and list the tools that are available
  • Start a Bedrock block model — ask me first whether looks or poly count matters more
  • Verify the UVs after that texture edit and show me the checker

How to install blockbench-use

1Skills CLI (Vercel)

npx skills add jasonjgardner/blockbench-mcp-project --skill blockbench-use -a claude-code

2Manually: put the files in place

~/.claude/skills/blockbench-use/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/blockbench-use/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about blockbench-use

How do I install blockbench-use in Claude?

Run npx skills add jasonjgardner/blockbench-mcp-project --skill blockbench-use -a claude-code. The skill lands at ~/.claude/skills/blockbench-use/SKILL.md.

What does blockbench-use do?

It prepares the agent for Blockbench MCP calls: discovers the active format and available tools, routes to modeling, UV/texturing, animation, particle, PBR or Hytale guidance, and verifies the requested result.

When should I load it?

Before calls that create, modify or export content. Capability questions belong to blockbench-mcp-overview, and plugin development to blockbench-plugins.

Source text

SKILL.md · Apache-2.0
---
name: blockbench-use
description: "Load before Blockbench MCP calls that create, modify, or export content. Discover the active format and tools, route to modeling, UV/texturing, animation, particle, PBR, or Hytale guidance, and verify the requested result."
---

# Blockbench Use

Load this skill before creating, modifying, or exporting Blockbench content. For capability questions, use [MCP overview](../blockbench-mcp-overview/SKILL.md); plugin development uses [blockbench-plugins](../blockbench-development/SKILL.md).

## Discover and Route

1. Call `get_capabilities: include_tools=true`. It works without an open project and returns host/plugin identity, `project` (or `null`), registered formats, and current tool enabled states. Discover the running bundle rather than assuming every tool described in these source skills is installed.
2. Preserve the intended project. Use its `project.format_id`; for a new project, choose an exact returned format ID for the user's target. `get_capabilities: format_id="<ID>"` inspects a format without switching projects. Generic Model is normally `free`, not `generic`. Hytale requires its registered Hytale format, not Bedrock. Read [format and delivery guidance](references/formats-and-delivery.md) when choosing a target or preparing an export.
3. Load relevant domain skills using the available skill-reading mechanism. Load additional guidance when the workflow reaches that domain; a simple edit does not need every skill.
4. Inspect affected content with `list_outline`, `list_textures`, and targeted queries. Prefer UUIDs when names overlap. Inspect runtime mesh component keys with `get_mesh_info` before component edits.
5. Check mode/selection when required. `list_modes` and `set_mode` navigate supported editor modes. Enabled tools can still require a compatible format, target, or selection. A feature value of `null` means unknown; compact `supported_features` lists true flags and `unknown_features` lists unknown flags.

| Intent | Guidance |
|---|---|
| Cubes, meshes, groups, silhouette, topology | [Modeling](../blockbench-modeling/SKILL.md) |
| Bedrock poles, cylinders, tubes, rings, and faceted round shapes | [Modeling](../blockbench-modeling/SKILL.md), then [Bedrock primitives](../blockbench-modeling/references/bedrock-primitives.md) |
| UVs, pixel density, painting, layers | [Texturing](../blockbench-texturing/SKILL.md) |
| Vanilla/default Minecraft textures, or a named Minecraft block or material (bricks, oak logs, stone bricks) | [Vanilla textures](../blockbench-vanilla-textures/SKILL.md), then [Texturing](../blockbench-texturing/SKILL.md) for UVs |
| Animated textures, sprite sheets, vertical flipbooks | [Flipbook textures](../blockbench-flipbook-textures/SKILL.md), which requires [GPT Image textures](../blockbench-gpt-image-textures/SKILL.md) for generated artwork |
| Pivots, keyframes, timing, animation export | [Animation](../blockbench-animation/SKILL.md) |
| Particle effects, VFX, locators, particle keyframes, Snowstorm/Bedrock particle files | [Particles](../blockbench-particles/SKILL.md), with [Animation](../blockbench-animation/SKILL.md) for the clip |
| Normal/height/MER materials | [PBR materials](../blockbench-pbr-materials/SKILL.md) |
| Normal, height or MER maps derived from an existing color texture | [Albedo to normal](../blockbench-albedo-to-normal/SKILL.md), then [PBR materials](../blockbench-pbr-materials/SKILL.md) to assign them |
| Hytale formats, attachments, stretch, visibility | [Hytale](../blockbench-hytale/SKILL.md), then applicable shared domains |
| Armature deformation, display slots, Bedrock material instances | [MCP overview](../blockbench-mcp-overview/SKILL.md) and live schemas |

## Work at the Scale of the Request

Before creating a new model or substantially redesigning its geometry, ask where the user's preference lies: **appearance/accuracy**, **performance (fewer elements/faces)**, or **a balance**. Ask for the destination when unknown, including Minecraft edition and block versus entity. Reuse an explicit preference already given; "high quality" or "HD textures" alone does not choose a geometry budget. Continue discovery and inspection while awaiting the answer, but settle the preference before detailed geometry or texture generation. Routine edits that preserve an established design do not need this question again.

Use [appearance and performance planning](references/appearance-and-performance.md) to translate the answer into a working budget, choose geometry versus texture/PBR detail, and measure the result. Read it before multiplying repeated parts, optimizing a slow model, or adding hardware details such as screws, bolts, rivets, and other fasteners, which normally belong in albedo and supported PBR channels rather than in geometry. For Bedrock custom blocks using multiple materials or cutout panels, also read [material instances and texture delivery](references/bedrock-material-instances.md).

For a new model, also answer the real-time planning questions in [real-time asset planning](references/real-time-asset-planning.md) and record them in its plan template: target device, shading model, special materials, triangle budget, texel density and texture size, tiled versus atlas UVs, and animation type. Settle the shading model and texel density during blockout, because changing them later invalidates UVs and textures.

For a new asset, establish proportions and silhouette before detailed geometry, UVs, texture detail, and final animation. For an existing asset, inspect and change the requested area without rebuilding successful work. Use reference images to identify shape, palette, material and intended viewing distance. Treat Minecraft and Hytale art direction as target-specific guidance, not universal restrictions on every Blockbench format.

Before assigning detailed materials or repeating mapped geometry, follow [UV scale and distortion guidance](../blockbench-texturing/references/uv-scale-and-distortion.md). Preserve face proportions and consistent material feature scale across different face sizes; do not stretch the same full atlas swatch over every face by default. Allow deliberate exceptions for uniform materials or designed effects, considering all PBR channels.

Choose verification that observes the changed behavior: inspect UV values, effective pixels per model unit in both directions, and a mapped checker for UV edits; inspect a texture image and the rendered model after painting; preview several times and the loop seam for animation. A screenshot of the rest pose alone cannot verify a walk cycle. See the delivery reference for format-specific checks.

## Recovery and Delivery

- Use `save_checkpoint` before exploratory or substantial edits when a history marker helps recovery. It is an undo-history marker, not a saved `.bbmodel` or a snapshot of unrecorded changes. It can clear a redo branch because it adds a history entry. Inspect `get_undo_stack` before recovery; count actual history entries rather than assuming one entry per tool call. Preserve intervening user edits.
- Use dedicated `undo` / `redo` tools instead of triggering generic undo actions. Direct scripts must create their own correct native undo transaction. A marker cannot make an unrecorded edit reversible.
- Prefer dedicated tools. If the task requires a feature absent from the live tools, use a supported native UI workflow or explain the specific limitation. Follow existing authorization and repository instructions for `risky_eval`; do not invent an unavailable wrapper or silently substitute a lossy format.
- For a requested file, discover `list_export_formats`, choose an available codec with compile support, and use `export_model`. Save an editable `.bbmodel` alongside a runtime export when the requested handoff calls for an editable source. A compiled model does not establish that textures, animations, materials, controllers, or engine configuration have also been delivered.
- Inspect returned export metadata and verify the actual destination/content. Truncated response text is a preview, not a complete file. When target-app access is unavailable, report the validation completed and the remaining integration check accurately.

© jasonjgardner · Apache-2.0 · jasonjgardner/blockbench-mcp-project

Similar skills

Everything for Game dev and 3D: Unity, Unreal, Godot, Blender →

From the same set6

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor