When to use Bedrock CLI vs mct vs Regolith

There are three tools worth knowing in the Bedrock scripting space, and they don't really compete: they occupy three different bands. This page is the honest version of the decision: which one fits where, and why Bedrock CLI is the approachable middle.

If you're starting a new add-on and want to ship it, Bedrock CLI is the default.

The three bands

The market splits into those three bands and the middle is where most people actually live: past the first tutorial, not yet running a filter pipeline. That is the band Bedrock CLI is built for.

mct (Microsoft)

The official toolchain. Best when you're learning the raw @minecraft/server API the way Microsoft demos it, working through a Microsoft tutorial, or using the in-browser editor and the level-graded lessons.

Pick this when:

• You're learning the API surface and want the official, documented path.
• You're following a Microsoft tutorial and want the exact files it references.
• You want a workspace that other readers of the official docs will recognize at a glance.

Reach for Bedrock CLI instead when:

• You want one command to scaffold a project, generators that write every linked file for a feature, hot reload to com.mojang, and .mcaddon packaging out of the box.

Bedrock CLI (the approachable middle)

A scaffolder (create-mc-bedrock) plus a compiler (@keyyard/bedrock-build). You run the scaffolder once to lay down a single opinionated starter, then live in the create:* generators: create:weapon, create:block, create:entity, and the rest each scaffold a fully wired feature (behavior JSON + resource JSON + texture and lang registration) in one command.

Pick this when:

• You're starting a new add-on and want to ship it, not just learn the API.
• You want generators that write every linked file for a feature instead of hand-wiring items, attachables, textures, and lang lines.
• You want hot reload to com.mojang on every save and a one-command .mcaddon.
• You want a clear split between source (src/) and built output (dist/).

What you get:

• A single scaffolded workspace following the workspace layout.
• The create generator family as the day-2 loop.
• config.json pre-filled with sensible defaults. See the config schema.
• Freshly generated manifest UUIDs, committed to git.
• Plain standard packs in and out. No lock-in: the output is exactly what Minecraft, mct, and Regolith all consume.

This is the gap 3.0 occupies: a terminal-native, idempotent, flag-or-interactive, in-project generator that writes every linked file for a feature in one shot, emits plain standard packs, validates the identifier before writing, previews with --dry-run, and is safe to re-run.

Regolith (Bedrock-OSS)

A multi-pack build system built around filters: compile-time transforms that run over your packs. Powerful for large projects with custom code generation, asset processing, or templating pipelines.

Pick this when:

• You're running a large multi-pack project with custom transforms.
• You want a filter pipeline (templating, asset processing, custom codegen) as a first-class part of your build.
• You're comfortable with a heavier toolchain in exchange for that power.

Reach for Bedrock CLI instead when:

• You want the shortest path from idea to in-game without configuring a pipeline, and you don't need compile-time filters.

Bedrock CLI is the complement, not the replacement: it emits plain standard packs, so a project can outgrow into Regolith later without a rewrite. Generation in Bedrock CLI is a one-shot scaffold of standard files; generation in Regolith is a compile-time transform.

Quick decision

These tools are not ranked against each other. They fit different bands. Bedrock CLI is built for the middle, and it stays out of the way of the other two by emitting plain standard packs.

Related

• CLI: create generators for the create:* family.
• Getting Started for the day-one walkthrough.
• Workspace Layout for the starter tree.