# MCP-Reborn is four Gradle files that decompile Minecraft, and a JSON you edit by hand > The repository holds no application code: it is a build configuration on top of MCPConfig and ForgeGradle, and almost everything a user does with it happens in IntelliJ, in a version JSON, or in a JAR they assemble by copying four files across. **Hexeption/MCP-Reborn** — MCP-Reborn is an MCP (Mod Coder Pack) for Minecraft for making modded clients and researching its code. (1.13-26.2) - Repository: https://github.com/Hexeption/MCP-Reborn - Stars: 1,559 · Forks: 200 - Language: Unknown - License: NOASSERTION - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/hexeption-mcp-reborn ## The first thing the README says is that you may not publish the output Before any usage text, a warning states that you cannot publish any code generated by this tool, and the top level of the repository carries a file named MCP-License that backs the prohibition. The rest of the attribution lines up with that: the tool is based on MCPConfig and ForgeGradle by the MinecraftForge team, and the special thanks go to that team for making the tool possible. The two named creators are Hexeption and kingdevnl. So the decompiled source you produce inside the src folder is something you may read, modify and run locally while developing, and something you are told not to redistribute. That boundary is worth holding precisely, because the whole point of the workflow is that the generated source becomes readable and editable in front of you. ## The root is a build configuration and no language is recorded at all There is no application code in this repository. The top level is .github, .gitignore, MCP-License, README.md, build.gradle, gradle.properties, the gradle folder, gradlew, gradlew.bat and settings.gradle, and no primary language is recorded for it, which is consistent with a repository whose entire payload is Gradle configuration. Everything the tool does is expressed as build tasks that pull in decompilation and code generation machinery and run it. That has a practical effect on how you read the project: there is no module to study, no API surface to learn and no version history in the code, so the questions worth asking are which branch you are on, which JDK that branch wants and what the build tasks are named. ## Supported versions stop at 26.1 while the default branch is 26.2 Version selection happens by branch, and the numbers do not line up. The README states supported versions as 1.13 to 26.1. The default branch is named 26.2, which is outside the range the documentation claims to cover. The release list explains itself in the other direction: the newest release carries the title Just use the branch, dated at the same moment as the last push, while the two older official tags are 1.21.4-official from February 2025 and 1.20.2-official from November 2023. In other words the tag list is a historical trail left behind by two older naming conventions, and the current instruction is to pick a branch. Anyone reading the supported versions line will conclude they are being told the wrong thing about the newest line of the tool. ## The JDK table has holes where the oldest versions are Four version thresholds are given, and they are written with two different comparison signs. The line for 1.17 and below reads that it needs JDK 16, using a less-than sign, so exactly 1.17 is not clearly assigned. The line for 1.18 and above reads JDK 17 with a greater-than sign, the line for 1.21 and above reads JDK 21, and the line for 26.1 and above reads JDK 25. Between those four lines there are gaps: nothing states a JDK for 1.13 through 1.16, and nothing separates the intermediate versions inside each band, so a reader has to infer. The newest supported line asks for the newest JDK, which means the toolchain your build machine needs moves as you move up versions. ## The setup task is the decompiler, and it only runs from inside IntelliJ The mechanism is a Gradle task rather than a command. You import build.gradle into IntelliJ, then run the setup task in the mcp folder from the Gradle tool window, which the README tells you may require View, Tool Windows, Gradle to be reachable at all. That task generates the decompiled source, which then appears in the src folder of the project. After editing, the runclient task compiles the modified game and launches it so you can test, and an autogenerated run configuration named Minecraft does the same thing. For producing something loadable, the build task writes an executable JAR into build/libs/. Three task names do all the work, and none of them is offered as a command line you could run from a terminal. ## Installing it means deleting the downloads block out of a version JSON The fragile step is not the Gradle side. Once the JAR exists, the instructions have you duplicate the Minecraft version folder, on Linux under ~/.minecraft/versions and on Windows under AppData/Roaming/.minecraft/versions, delete the original Minecraft JAR inside it, and rename the JSON so its name matches the folder. Then the JSON is edited by hand: you find the first instance of downloads, which tells Minecraft where to fetch the game JAR, and delete everything from there through the client, server and server_mappings headers, which finally end at a specific terminator string. What should remain is this fragment, and then the id field is changed to match the folder and file name. ``` "assets": "1.16", "complianceLevel": 1, "id": "1.16.4" "id":"1.16.4_villager_mod" ``` Two things about that fragment are worth noticing. Every literal value in it belongs to the 1.16 era even though the tool claims coverage up to 26.1, and the end of the deleted region is identified by an exact string, so a version whose JSON is shaped differently would need that boundary re-established by hand. ## Four files are copied out of the base JAR and META-INF is thrown away Assembly is done in an archive manager, with 7-Zip named for Windows users. You open the base version JAR and your own JAR side by side and copy four entries from the base into yours. ``` assets data pack.png pack.mcmeta ``` Then the META-INF folder is deleted from your JAR, and the finished file is renamed to the same name as the version folder. The deletion is the part with a reason attached: the base JAR's signature data does not belong in a rebuilt archive. Everything here is manual file surgery inside the Minecraft versions directory, and the launcher step that follows is to reopen the launcher, create a new installation under Installations, pick the version you just built, and select it from the lower left before starting the game. ## OptiFine support is one video link and no written steps The whole OptiFine section consists of a single link, whose own title attribute reads How to add Optifine to MCP Reborn. There is no text, no version note, no compatibility statement and no instruction of any kind. That stands in contrast to the main flow, where the version folder, the JSON edit, the four copied files, the META-INF deletion and the launcher steps are all written out one by one. So the third-party rendering mod that people most often pair with a modded client is the one part of the documented path that exists only as a video. Anyone planning a setup around OptiFine should treat the integration as undocumented rather than as described. ## Conclusion MCP-Reborn is a build script rather than a codebase, and that shape decides how you should treat it: choose a branch, read the JDK row that belongs to it, and expect the version JSON edit to be the step you verify by hand rather than a step anything automates for you. The publishing prohibition is not decoration, since an MCP-License file sits at the root and the whole toolchain descends from MCPConfig and ForgeGradle, so keep decompiled output out of anything you distribute. Two gaps are worth planning around before you commit an afternoon to it: the version list stops at 26.1 while the default branch is 26.2, and the JDK table says nothing at all about 1.13 to 1.16. The OptiFine route is a single video link with no written steps behind it, so treat that part as unsupported. ## FAQ ### What is MCP-Reborn? An MCP, a Mod Coder Pack for Minecraft, used to make modded clients and to research the game's code. It is based on MCPConfig and ForgeGradle by the MinecraftForge team, and the README states support from 1.13 to 26.1. ### How do I use MCP-Reborn to build a modded client? Import build.gradle into IntelliJ, run the setup task in the mcp folder so the decompiled source appears in src, edit it, then run the runclient task to launch a modified game or the build task to write a JAR into build/libs. ### Can I publish code generated with MCP-Reborn? No. A warning at the top of the README says you cannot publish any code generated by this tool, and a file named MCP-License sits at the repository root. The tool is built on MCPConfig and ForgeGradle from the MinecraftForge team. ### Which Java version does MCP-Reborn need? Four thresholds are given: 1.17 and below need JDK 16, 1.18 and above need JDK 17, 1.21 and above need JDK 21, and 26.1 and above need JDK 25. Nothing is stated for 1.13 through 1.16. ### Which Minecraft version does MCP-Reborn support? The README states 1.13 to 26.1, while the default branch is named 26.2 and the newest release is titled Just use the branch. The two older official tags are 1.20.2-official from November 2023 and 1.21.4-official from February 2025. ### What happens to the JSON file after MCP-Reborn builds a JAR? The downloads section is deleted by hand so Minecraft does not fetch the vanilla JAR, and the id field is changed to match the new folder and file names. Then assets, data, pack.png and pack.mcmeta are copied from the base JAR and META-INF is deleted from the new one. ## Sources - [Hexeption/MCP-Reborn on GitHub](https://github.com/Hexeption/MCP-Reborn) - [Issues](https://github.com/Hexeption/MCP-Reborn/issues) - [README](https://github.com/Hexeption/MCP-Reborn/blob/26.2/README.md) - [Releases](https://github.com/Hexeption/MCP-Reborn/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hexeption-mcp-reborn