| name | minecraft-dev-loop |
| description | Test Minecraft mod changes in the running game - rebuild the mod, deploy the jar, restart the client via DebugBridge, and rejoin a server. Use when asked to "test this in game", restart Minecraft after a build, or run the build-deploy-relaunch-rejoin loop. Requires the mcdev-mcp MCP server and the DebugBridge mod with session_control_enabled. |
Minecraft mod dev loop
The full procedure lives in the mcdev-mcp server's mcdev://guides/dev-loop
resource — read it first (via your MCP resource access, or as
resources/dev-loop.md in the mcdev-mcp package). It is the single source of
truth; this file is just the trigger and the outline.
The loop, in short:
- Check capability:
mc_connect must show Session control: enabled;
otherwise relay the enable instructions it gives and stop.
- Discover once per machine (while the client runs):
gameDir from
mc_connect gives the deploy target (<gameDir>/mods/), the instance
name, and the launcher. Persist the launch command you compose in the
project's CLAUDE.md.
- Build & deploy with the mod repo's build system (your shell).
- Quit with
mc_quit_client (waits for the process to be really gone).
- Launch detached from your shell (
setsid … & / open -a / start),
or ask the user to click the launcher if no CLI launch works here.
- Reconnect with
mc_wait_for_bridge, rejoin with mc_join_server,
then verify the change with the runtime tools.
Cautions that always apply: this tears down the user's play session — only
run it when asked. Authentication belongs to the launcher (user logs in once;
never handle tokens). Prefer a local throwaway server (online-mode=false)
over live community servers for automated runs.
