Why it exists

In Bedrock, a field name recalled slightly wrong produces output that silently does not work. No error message, no red line. Everything looks fine until the pack is loaded into the game.

A real example — both lines pass the schema, one of them never loads:

  "modules": [
-   { "type": "javascript", "entry": "scripts/main.js" }
+   { "type": "script", "language": "javascript", "entry": "scripts/main.js" }
  ]

With the top line the pack did not appear in the behavior pack list at all. It did not even raise an error. The javascript type is left over from before 1.16 and the schemas keep it for backward compatibility, but it does not load with @minecraft/server 2.x. The schema says "valid type", the game says "I cannot load this type".

That one line was measured in the real game (30-08-2026). There are seven more classes like it, all in docs/VALIDATION-LIMITS.md with ContentLog evidence.

CodeCraft closes that gap: values are read from version-pinned data, and output is validated against the official schema and against a real tsc.

Nine tools

All nine are read-only. The server writes nothing, sends data nowhere, and keeps no user data.

The order is not alphabetical, it is the order of use — and tools/list preserves it.

Setup

In Claude, open Customize → Connectors (not Settings; older guides point there, and there is no custom connector field on that screen):

1. Customize → Connectors → add a custom connector
2. Paste the endpoint address
3. Save

Three things you should see once it connects — a single "it worked" is not enough:

• The tool count is 9, complete
• The client classifies them as "read only tools" — a separate permission class
• Our own titles are visible, e.g. "Can Bedrock do this" — the tool surface is English

More: docs/MCP.md

Where validation ends

This table is not advertising, it is a statement of limits. "Passed validation" and "works in the game" are not the same thing — eight classes of error get through validation and break in the game, and every one of them was measured in a real game.

F and G are worth reading twice. The game rejects both exactly as hard — the whole block definition is dropped. F was raised to error and G was not, because our own component index has a measured gap of 126 names. What decides severity is not only "what does the game do" but "how complete is our list" — two separate questions, and neither is answered without measuring.

The tools find and report, they do not write — the endpoint is read-only, fixing is the caller's job. The half that is still open is written down too: docs/VALIDATION-LIMITS.md

Bedrock has five separate version numbers

This is where the confusion hurts most, and it is half the reason the tool exists:

format_version is an axis of its own and has nothing to do with the game version: it is the schema version of that file type. Block 1.21.100, feature rule 1.13.0, spawn rule 1.8.0, manifest 2. It does not change when the game version changes.

The module version is a trap of its own — the game version arrives embedded inside the prerelease tag:

2.9.0                              stable module version (npm "latest")
2.11.0-beta.1.26.50-preview.27     module 2.11.0, game 1.26.50-preview.27

Correct values are not recalled, they are read from the schema — which is exactly what get_schema and get_version_info are for.

Architecture

flowchart LR
    C["Claude<br/>you bring the model"] -->|MCP / HTTP| M["packages/mcp<br/>9 read-only tools"]
    M --> V["packages/validator<br/>ajv · tsc · commands · python"]
    V --> K["packages/knowledge<br/>lookup · version resolution"]
    K --> D[("data/<br/>indexes per version")]
    P["pipeline/<br/>daily cron"] -->|produces| D
    U["Mojang · Blockception<br/>npm · MicrosoftDocs"] -->|fetches| P

Dependencies point one way: mcp → validator → knowledge → data. Nothing imports backwards.

There is no build step. Node runs the .ts files directly; tsc is used only for type checking and, as a subprocess, for validate_script.

Data

data/ is not a database — it is a set of indexes that live in git and are versioned there. Eight collectors produce it from four upstream sources.

A scheduled GitHub Action refreshes it, and a freshness check reports when the data goes stale. The cron is set to 05:00 UTC — but it does not run then. All five scheduled runs measured on 03-09-2026 started late, the earliest by 4h24m, ~5h on average; GitHub queues scheduled jobs and delays them under load. So the indexes can be up to 1 day + ~5 hours old.

Raw upstream data never enters the repo. Only derived facts are indexed: whether an identifier exists, the name of a field, a version number. Reasoning and measurements: docs/SOURCES.md

Invariants

1. The validation layer never calls an LLM. No package in this repo depends on an LLM SDK. The rule is not a sentence, it is a measurement: packages/mcp/test/no-llm.test.ts
2. The endpoint is read-only. All nine tools carry readOnlyHint
3. data/ lives in git. No database
4. The free tier is a requirement, not a constraint
5. Raw upstream data never enters the repo

How measurement is written down

In this repo, "it works" and "it was measured" are different things. A claim is written only once it has been measured, and how it was measured is written next to it — with the date. A measurement that turns out wrong is not deleted; it is struck through and where it went is written down.

That is what the "measured (date)" comments in the code are: each one is the record of something that really did break, once.