Scripting API Modules Reference

The Bedrock Scripting API is not a single monolithic library. Instead, it is divided into scoped packages under the @minecraft namespace. Each module serves a distinct architectural purpose: one handles world manipulation and entity logic, another builds user interfaces, and others exist specifically for dedicated server environments.

To use any module, you must perform two steps. First, you declare the module's name and exact version under the dependencies array in your behavior pack's manifest.json. Second, you import the classes, interfaces, or objects you need at the top of your JavaScript file using standard ES6 import syntax. The game's QuickJS engine resolves these imports internally at runtime; you do not bundle the @minecraft packages into your pack's files.

Most add-ons rely on a combination of five primary modules. While @minecraft/server and @minecraft/server-ui are used in regular worlds, realms, and servers alike, the remaining modules are restricted to specific environments like Bedrock Dedicated Server (BDS) or automated testing frameworks.

When choosing a module version, you must decide between stable release strings (such as 1.11.0) and beta strings (such as 1.12.0-beta). Stable versions never break backward compatibility. If Mojang changes how a method works in a future update, a pack requesting an older stable version will continue to receive the old behavior. Beta versions, on the other hand, give you access to the newest experimental classes and methods, but they require the Beta APIs world toggle and will break every time the game updates to a new minor version.

Before your script can import a module, the behavior pack's manifest.json must request it. You need a script module entry in the modules array to tell the game where your entry point file is, and one entry per API module in the dependencies array.

Notice that API module dependencies use the module_name key, unlike pack-to-pack dependencies which use a uuid key. The version field takes a semantic version string rather than a three-number array, which is especially important if you need to append the -beta suffix.

{
  "format_version": 2,
  "header": {
    "name": "Module Demo Pack",
    "description": "Demonstrates declaring script dependencies.",
    "uuid": "a1b2c3d4-e5f6-4a5b-8c9d-0e1f2a3b4c5d",
    "version": [1, 0, 0],
    "min_engine_version": [1, 20, 80]
  },
  "modules": [
    {
      "description": "Script Entry Module",
      "type": "script",
      "language": "javascript",
      "uuid": "f6e5d4c3-b2a1-4f5e-9d8c-7b6a5f4e3d2c",
      "version": [1, 0, 0],
      "entry": "scripts/main.js"
    }
  ],
  "dependencies": [
    {
      "module_name": "@minecraft/server",
      "version": "1.10.0"
    },
    {
      "module_name": "@minecraft/server-ui",
      "version": "1.2.0"
    }
  ]
}

Once your manifest is configured, you can import objects from those modules inside your entry file or any auxiliary script files it imports. Using the world and system objects from @minecraft/server is the standard starting point for listening to events or running repeating tick intervals.

In the example below, we combine @minecraft/server and @minecraft/server-ui. We listen for the after-event triggered when a player uses an item, check if that item is a compass, and then construct and display a simple UI form to that specific player.

import { world, system } from "@minecraft/server";
import { ActionFormData } from "@minecraft/server-ui";

world.afterEvents.itemUse.subscribe((event) => {
  const player = event.source;
  const item = event.itemStack;

  if (item.typeId === "minecraft:compass") {
    showNavigationMenu(player);
  }
});

function showNavigationMenu(player) {
  const form = new ActionFormData()
    .title("Quick Travel")
    .body("Select a destination:")
    .button("Spawn Point");

  form.show(player).then((response) => {
    if (response.canceled) return;

    if (response.selection === 0) {
      system.run(() => {
        player.sendMessage("Teleporting to spawn...");
      });
    }
  });
}

While the game executes the @minecraft modules internally, your code editor does not know they exist by default. To get autocomplete, type checking, and inline documentation in editors like Visual Studio Code, you can install the official type definitions from the public NPM registry on your development machine.

Running npm install @minecraft/server --save-dev in your project root downloads the .d.ts files that match the game's internal API. Make sure the version you install via NPM matches the version string declared in your manifest.json. In addition to the built-in runtime modules, Mojang also publishes standalone helper packages on NPM, such as @minecraft/math and @minecraft/vanilla-data. Unlike @minecraft/server, the game engine does not have these helper packages built in. If you use them, you must use a bundler like esbuild or Webpack to compile their code directly into your pack's final JavaScript files, and you must not list them in your manifest.json dependencies.

Applies to Bedrock Edition 1.19.50 and newer. Stable module versions work in any world without experimental toggles. Using any version string ending in -beta, or using @minecraft/server-gametest, requires the 'Beta APIs' experimental toggle to be enabled in the world settings.

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