The mif_roadmap tool turns a goal such as "an enemy that chases the player" into an ordered list of steps, and tells you which of those steps will actually work on your engine version, in your project, in your editor right now. This page is about that tool. It is not a schedule of upcoming releases.

What it is for

Any language model can write a plausible plan for a mod. Checking that the tool names in it exist adds little, because a name existing says nothing about whether the call works on the engine, project and editor in front of you. A plan that says "register your landscape layer" to someone whose engine takes another branch there, or "save the map" to someone whose bridge is in scratch mode, walks a newcomer into a failure they cannot tell from their own mistake.

So mif_roadmap is a lookup, not a planner. It calls no model. The assistant is the planner, and the tool is the grounding the assistant cannot invent. Nothing about whether a step works is typed by hand. A catalog says which calls a step is made of and why. Every claim about whether those calls work is derived at the time of the call from the plugin's source, its shipped data and the live editor, and each claim names where it came from.

It only reads. It never writes anything, so the safety gate never sees it.

Calling it

mif_roadmap(goal="", steps=None, engine="", live=True, blender="")

Input	What it does
`goal`	free text. It is matched by words against the catalog's goals, and the best match's steps are grounded. No match is still an answer: the closest goals, the tools whose descriptions hold your words, and an instruction to write the steps and send them back as `steps`. An empty `goal` with no `steps` lists the catalog
`steps`	a plan someone wrote: a list of `{say, tools: [...]}` or of bare tool names. It is grounded exactly as a catalog plan is, so a plan written by a model gets checked line by line
`engine`	`5.3` to `5.8`. The default is the connected editor's own. It lets you check a plan for an engine that is not running
`blender`	a Blender version such as `4.2`. The default is the version the running Blender reports
`live`	read the connected editor, and Blender for `bl_*` steps. With `live=False` the answer comes from the source and shipped data alone and says what it could not check

The catalog

The catalog ships with the MCP server. It holds goals, each an ordered list of steps made of this bridge's own tools:

Goal	Kind
Change a game's values (prices, stats, rates) in its DataTables	mod
Change what a cooked Blueprint does (its logic, events and functions)	mod
An enemy that sees, chases and attacks the player	game
An outdoor level: terrain, painted ground, foliage, sun, sky and air	game
A prop modeled in Blender and placed in Unreal with collision and a material	both
A HUD or menu widget shown on screen in play	both
A visual effect: fire, smoke, sparks, magic	both
Package a standalone build of the game	game

A step may carry a read-only check, such as "a landscape is in the open map" or "a Behavior Tree exists under the folder". A check marks the step done, and the answer names the first step that is not done (nextStep). This is stateless on purpose: it works out where you are from the project itself, so it cannot disagree with it. A step can also be manual, with the reason the bridge cannot do it and what to do instead.

Checks come from a fixed allowlist of read-only calls. A check may only name a call on that list. "Records no undo step" is not enough to qualify, because that group includes saves and console commands.

The answer

Field	Holds
`project`	what was read from the editor: engine, write mode, change cap, enabled plugins, whether content is cooked, the generative setting, and whether the plugin binary is older than its source
`steps[]`	each step with a `status` and its `tools[]`, each tool with its derived facts
`cannot[]`	the steps the bridge cannot do, with why and what to do instead
`notChecked[]`	what this run could not establish, and why
`sources`	which inputs were present

Step status

Every step has exactly one of six statuses:

Status	Meaning	Derived from
`done`	the project already has it	the step's read-only check, run live
`ready`	every tool is registered and nothing below applies	everything below came back clean
`caution`	it will run, and something about this engine or project changes what it does	a refusal of some calls on this engine (an option or input the engine lacks, quoted in the answer), cooked-content handling when the project has cooked content, or a plugin needed for part of what it does and not enabled
`blocked`	it will be refused here as things stand, and the reason names who can change that	a tool that is not registered, an endpoint missing from the live editor (an older plugin, or the provider plugin of an external endpoint not installed), a refusal of every call on this engine, a plugin every call needs that is not enabled, a write-gated step in a lower write mode, a generative tool in a non-generative project, or Blender not answering
`manual`	the bridge cannot do this step at all	the catalog's explanation
`unknown`	it could not be checked (offline, or the check call failed)	`notChecked` says which

blocked can be lifted by the right person. A write-gated step is blocked until you raise the write mode, and the answer says so. The tool never suggests a route around the gate.

A plain engine guard in the source is information and does not change the status. Most are the same behavior through a renamed engine function, and listing all of them as cautions would make cautions noise on older engines. They appear under engineBranches. What changes the status is a branch that refuses. If the refusal message begins with its own endpoint's name ("reimport_scene needs Unreal 5.4 or later") it refuses every call, so the step is blocked. Any other refusal ("dependencies:false needs UE 5.4") refuses only the calls that ask for that option, so the step is caution with the message quoted, so the assistant can tell whether its call is one of them.

What it reads, and where each fact comes from

Fact	Read from
goals and their steps	the catalog that ships with the server
which tools exist	the server's own registered tools
which endpoints a tool reaches	the tool's own body, every endpoint or op it calls
engine guards, plugin requirements, cooked-content handling, and refusals that name a crash	the plugin's source
write gate and undo bucket	the live `self_audit`, never a copy of a list
write mode, change cap, engine, project	the running editor, through `self_audit`
enabled plugins	the running editor, through `list_project_plugins`
cooked content in the project	the running editor, through `list_blueprints`
the generative setting	the project's `MifBridgeProject.json`
per-engine and per-Blender results of the shipped test suites	a snapshot of verdicts that ships with the server, with its age in `sources.evidenceSnapshot.age`
Blender version gates per op	the add-on's ops, judged at the Blender version you name or the one that is running

A cooked-content refusal is reported as "it checks for cooked targets", not "it refuses". The branch may read differently, refuse or note, and the answer does not claim more than the source shows.

The Blender half

bl_* steps are grounded by Blender version. The answer carries:

Field	Meaning
`blenderVersionGates[]`	each version-shaped refusal in an op: the op, its message, where it is, the condition, and whether it applies here (true, false, or null when it depends on the call). A gate judged false on your version is left out
`blenderVersionDiffers`	ops that succeed on every tested Blender version but whose result fields read differently by version. This is information, never a block
`blenderEvidence`	the shipped test verdict for the op on this Blender version

A static version check is one the source can judge. Many differences in the add-on are discovered at run time, for example an enum's items. Those are listed with the Blender version that was running when the op refused, and not judged ahead of time. A refusal in a helper that an op calls is not seen.

What a store package has

A package from the store ships the server, the catalog, the tool packs and the plugin's source. It does not ship the development test results beyond the verdict snapshot. So the roadmap in a package carries engine guards, plugin requirements, cooked handling, crash refusals and live project facts, and says in notChecked which evidence is not in the package. It never reports missing evidence as "no problems found".

How it fits with the rest of the bridge

Mechanism	The roadmap's relation to it
safety gate and write modes	it never writes. It reads the mode and each endpoint's `writeGated` flag, and a write-gated step in a lower mode is `blocked` with "ask the user to raise the write mode"
change cap	read from `self_audit`. A step whose tools take the preview path (`spawn_many`, `write_datatable_rows`, `delete_datatable_rows`, `snap_actors_to_ground`, `batch`) says the call will answer a bulk preview to commit when the cap is on
`batch`	a step is not a batch. The answer says which steps' tools are transacted and which are not, and does not promise that a step is atomic. `batch` runs every op even after a failure
undo	per tool, the live bucket: `transacted` (Ctrl+Z reverts it), `selfManaged` or `readOnly` (not a transaction: saves, compiles, Play-In-Editor, the console, cooks). A step with untransacted writes says it cannot be undone from the editor
templates	a goal may name a conversation template, and the answer points at it with `mif_help`. The roadmap grounds, and the template converses
tool packs	each tool's pack is reported, with the `mif_enable_pack` or `mif_call` route to reach it when it is not loaded

To run a plan with rollback and a dry run, hand its steps to a workflow.

When something is missing

Situation	What happens
no editor answers	live facts are `unknown` and `notChecked` names them. Source and shipped facts still apply. A step whose readiness depends on a live fact (a plugin, the write gate) is `unknown`, never `ready`
the goal matches nothing	the closest goals with scores, the tools whose descriptions hold your words, and the instruction to write `steps`. The answer is `ok:true` with `matched:false`
a step names a tool that does not exist	`blocked`, with `didYouMean` suggestions from the registry
no plugin source beside the server	engine guard, plugin, cooked and crash facts are absent and `notChecked` says so. Nothing is inferred
a catalog check errors	that step is `unknown` and the error is quoted. A failed check is never read as "not done"
an engine version no guard data covers	guards are still evaluated by version arithmetic, and the evidence says "no results on this engine" instead of "fine"

An empty result fails: steps=[] with no goal, or a plan whose every tool is unknown, answers ok:false with the reason.

What each kind of grounding gives you

Per engine. Guards with direction, refusals that name a crash, and the shipped test verdicts for that engine. engine can ask about an engine that is not running.
Per project. The engine actually running, the write mode, the change cap, enabled plugins, cooked or editable content, the generative setting, and a binary older than its source. A cooked project turns every tool that handles cooked content into a caution.
Per workflow. The catalog's read-only checks mark steps done and name the first step that is not.

Plan with mif_roadmap