What Marketplace Submission Asks For

Before packaging your files, you need to know which product category you are building for, as each has different structural rules. Historically, most gameplay submissions were World Templates (`.mctemplate`), which lock your Behavior Pack and Resource Pack to a single pre-built world folder. More recently, standalone Add-Ons have become a major category, allowing players to apply your Behavior Pack and Resource Pack to their own existing or new worlds.

Regardless of the category, the submission system expects clean directory structures without nested parent folders or leftover development clutter. Tools like Git leave behind `.git` directories, macOS generates `.DS_Store` files, and image editors often drop `.bak` or `.psd` files alongside your textures. Automated validation rejects archives containing unrecognized file extensions or hidden system files.

File paths across your entire project are subject to strict length and character limits because the content must run on consoles and mobile file systems with tight path restrictions. Keep all folder and file names strictly lowercase, use only alphanumeric characters and underscores, and avoid deeply nested directories. A texture path that works fine on a Windows PC can silently fail to load on a console if the total path length exceeds platform limits or relies on uppercase characters that break on case-sensitive systems.

A `manifest.json` file that works in your local `development_behavior_packs` folder will often fail commercial validation. For a submission, every manifest must use `format_version` 2, and every single `uuid` field—in the header, in each module, and in the capabilities or dependencies blocks—must be a newly generated, valid Version 4 UUID. Reusing UUIDs from templates or sample packs causes immediate conflicts in the catalog.

Instead of hardcoding plain English strings directly into the `name` and `description` fields of your manifest, submission guidelines require you to use localization keys such as `pack.name` and `pack.description`. The game resolves these keys by looking up the `texts/en_US.lang` file inside the same pack. This ensures your pack title and description can be translated cleanly by the localization pipeline.

You must also include a `metadata` block declaring the authors and any tooling used, alongside a `dependencies` array if your Behavior Pack requires a companion Resource Pack to display its custom entities, blocks, or items. Linking the packs via dependencies ensures that when a player activates the Behavior Pack, the corresponding Resource Pack is automatically applied and cannot be accidentally left behind.

{
  "format_version": 2,
  "header": {
    "name": "pack.name",
    "description": "pack.description",
    "uuid": "a4b8c9d0-1234-4ef5-89ab-cdef01234567",
    "version": [1, 0, 0],
    "min_engine_version": [1, 20, 80]
  },
  "modules": [
    {
      "type": "data",
      "uuid": "b5c9d0e1-2345-4fa6-9abc-def012345678",
      "version": [1, 0, 0]
    },
    {
      "type": "script",
      "language": "javascript",
      "uuid": "c6d0e1f2-3456-4ab7-abcd-ef0123456789",
      "entry": "scripts/main.js",
      "version": [1, 0, 0]
    }
  ],
  "dependencies": [
    {
      "uuid": "d7e1f2a3-4567-4bc8-bcde-f01234567890",
      "version": [1, 0, 0]
    },
    {
      "module_name": "@minecraft/server",
      "version": "1.11.0"
    }
  ],
  "metadata": {
    "authors": [
      "Studio Name"
    ]
  }
}

Every custom identifier in your pack—covering entities, blocks, items, particles, sound definitions, loot tables, and spawn rules—must use a studio-specific namespace followed by an underscore and the project acronym, such as `studio_proj:custom_chair`. You are never allowed to use the `minecraft:` namespace for custom definitions, and generic namespaces like `custom:` or `addon:` will be rejected because they risk colliding with other creators' packs when a player stacks multiple Add-Ons in a single world.

For standalone Add-Ons in particular, you cannot override or modify base game files unless explicitly permitted by the current specification. That means you should not drop a modified `player.json` into `BP/entities/player.json` to attach mechanics to the player. Doing so breaks compatibility with every other Add-On that tries to do the same thing. Instead, use the Script API (`@minecraft/server`) to listen for player events, manage dynamic properties, and apply effects without touching vanilla entity definitions.

This namespace discipline extends to geometry and texture short names as well. A geometry identifier in your model file should read `geometry.studio_proj.custom_chair` rather than `geometry.custom_chair`. If two different Add-Ons define `geometry.chair`, whichever Resource Pack sits higher in the world's load order will overwrite the other's model, resulting in broken visuals for the player.

No user-facing text should ever be hardcoded inside a JSON component, dialogue file, or script call. Whether it is the display name of an item in `minecraft:display_name`, an actionbar prompt triggered by a script, or a chat message from an NPC, the string in your code must be a translation key that points to `texts/en_US.lang`. You also need a `texts/languages.json` file that lists every language file present in your `texts/` directory.

Notice the comment symbols (`##`) at the end of lines in standard `.lang` files. While optional for local play, commercial pipelines use automated translation tools that often rely on clean key-value formatting and context comments to translate your pack into other languages accurately. Make sure your `.lang` files are saved with UTF-8 encoding without a Byte Order Mark (BOM), as a BOM at the start of the file will cause the game to misread the very first translation key.

pack.name=Mechanical Contraptions Add-On	##
pack.description=Build automated factories with custom gears and conveyors.	##

tile.studio_mech:brass_gearbox.name=Brass Gearbox	##
item.studio_mech:wrench_tool=Engineer's Wrench	##
entity.studio_mech:copper_drone.name=Copper Drone	##

action.hint.exit.studio_mech:copper_drone=Tap sneak to dismount the drone	##
message.studio_mech.overheat_warning=The gearbox is overheating!	##

Quality assurance teams test submissions against minimum-spec devices, including older tablets, smartphones, and handheld consoles with limited RAM. A pack that runs at a smooth 60 frames per second on a desktop PC can easily crash a mobile device if textures and geometry are unoptimized. Keep individual entity and block textures at 16x16 or 32x32 resolution unless the entity is massive, and avoid stuffing high-resolution UI textures into your Resource Pack.

Entity counts and script execution budgets are monitored closely during review. If your custom spawn rules flood caves with hundreds of ambient mobs, or if an entity behavior leaves behind invisible marker entities that never despawn, world performance will degrade over time. In scripts, avoid running heavy calculations or large `dimension.getEntities()` queries inside a `system.runInterval` loop that ticks every frame. Spread work across multiple ticks or trigger logic via specific event listeners instead.

Content must also adhere strictly to brand and age-rating guidelines. Realistic firearms, gore, depiction of controlled substances, copyrighted third-party intellectual property, and political or religious themes are not permitted. Even seemingly harmless mechanics—like naming a healing potion after a real-world medication or using a trademarked brand name for a food item—will trigger a rejection during content review.

alongside your technical `.mcaddon` or `.mctemplate` archive, the submission portal asks for a full suite of marketing art and storefront metadata. You cannot simply upload a random screenshot as your pack icon. Storefront art must be delivered at exact pixel dimensions, in specific file formats (often uncompressed PNGs or specific JPEG baselines depending on the slot), and must follow strict composition rules.

Key art and thumbnail images represent your product in the in-game store carousel. These images generally must not contain text, version numbers, fake UI elements, or third-party logos, except where a title logo is explicitly requested for a designated banner slot. Screenshots must be captured cleanly in-game without the player HUD, chat messages, or debug overlays visible, and they must accurately represent what the customer actually gets inside the pack without misleading external shader effects.

Applies to current commercial Bedrock releases (1.20.x and 1.21.x). Experimental toggles (such as Beta APIs or upcoming creator features) are strictly prohibited in Marketplace submissions; all JSON schemas and script modules must use stable, non-beta versions.

Read out of the game itself, so the ids match the version you are building for.