OpenCAGE can be driven by an AI assistant, such as Claude, through the Model Context Protocol (MCP). You describe what you want — "create a new level which spawns the player in a corridor built from SCI_AndroidLab's pieces" — and the assistant does it in OpenCAGE:

• creates the level;
• finds the player spawner and the corridor pieces in SCI_AndroidLab and ports them in;
• places them;
• sets the spawn up;
• saves and builds the level.

The assistant works in the OpenCAGE window you have open, through the same code the editor's own menus and dialogs use. Everything it does appears in the editor and the Viewport as it happens. Script changes land on the editor's undo history, and nothing is written to the game until it (or you) saves.

OpenCAGE ships a small program for this, OpenCAGE.MCP.exe, in the folder OpenCAGE is installed in, beside OpenCAGE.exe. On Steam, find that folder with right-click OpenCAGE → Manage → Browse local files. Your AI app runs that program. If OpenCAGE isn't open, the program starts it the first time the assistant uses it.

Claude Desktop: open Settings → Developer → Edit Config and add OpenCAGE to claude_desktop_config.json, using the path to your OpenCAGE folder (backslashes doubled), then restart Claude Desktop:

{
  "mcpServers": {
    "opencage": {
      "command": "C:\\Path\\To\\OpenCAGE\\OpenCAGE.MCP.exe"
    }
  }
}

Claude Code: add it once from a terminal:

claude mcp add opencage -- "C:\Path\To\OpenCAGE\OpenCAGE.MCP.exe"

Other MCP apps: any app that can run a local ("stdio") MCP server works the same way: give it the path to OpenCAGE.MCP.exe. The program also takes these optional arguments:

• --editor <path> — the OpenCAGE.exe to start, if not the one beside it (setting the OPENCAGE_EXE environment variable to its path does the same);
• --no-launch — only work with an OpenCAGE that is already open;
• --launch-at-start — start OpenCAGE as soon as the app connects, rather than on the assistant's first request;
• --toolsets <names> — offer the assistant only some groups of tools at first, for apps that struggle with long tool lists (for example --toolsets core,script,world,cameras). The assistant can ask for the rest when it needs them. The groups are core, script, flowgraph, zones, viewport, world, cameras, characters, lights, sound, animation, assets, porting, gamedata and game (all offers every group);
• anything after -- — passed to OpenCAGE when the program starts it, for example -- -disable_viewport.

Assistants can only reach OpenCAGE while Options → Misc → Allow AI Assistants (MCP) is ticked. It is on by default. Untick it and nothing can drive the editor: an assistant that tries, even one that started OpenCAGE itself, is told to turn the option back on.

• One editor, the one you're using. OpenCAGE.MCP.exe passes the assistant's requests to the open OpenCAGE over a local connection. Only programs running as you, on your PC, can use it. With more than one OpenCAGE open, the first one opened takes the requests.
• One thing at a time. The assistant's requests run one after another, in the editor, just as if you'd used the menus. You can keep working in OpenCAGE between them. Loading or saving a level and porting composites take as long as they do from the menus.
• Message boxes. The assistant can't click OpenCAGE's message boxes. Any that appear while it's working are answered with the most cautious button (Cancel, then No, then OK), and what they said is passed back to the assistant. Questions put to you, such as the one when you close OpenCAGE mid-task, are left for you to answer.
• Seeing the level. The assistant can take a picture of the Viewport (with the camera moved to what it wants to look at) to check what it has built.

While It Works

While the assistant is running one of OpenCAGE's tools, the left end of the status bar, along the bottom of the OpenCAGE window, shows a blue label: AI assistant working: tool..., naming the tool, such as AI assistant working: Open level... or AI assistant working: Find composites.... OpenCAGE's usual status messages (loading, saving, undo) appear beside it. The label stays for about three seconds after each call, so an assistant making several calls in a row shows one steady label, and it goes once the assistant stops. While it's up, let the assistant finish before you edit or close OpenCAGE.

Closing OpenCAGE while a tool is running asks first, in a box titled Close OpenCAGE?: An AI assistant is in the middle of a task in OpenCAGE (tool). Closing OpenCAGE now stops it part-way through. Close OpenCAGE anyway?

• No, the default, keeps OpenCAGE open, and the assistant's task carries on.
• Yes closes OpenCAGE, and the task stops part-way. If Prompt to Save on Close is on and the level has changes, Save level? comes next, as usual. The assistant is told OpenCAGE closed, and OpenCAGE is started again on its next request, as it is when it isn't open.

While the question is up, the assistant waits for you: anything new it asks OpenCAGE for is turned away until you've answered, and a level that's loading carries on loading but doesn't open its panels until then. The question only comes up while a tool is actually running. Between calls, even while the label is still showing, OpenCAGE closes as it always does.

These are the tools the assistant is given. You don't call them yourself — describe what you want and the assistant picks them — but knowing them helps you ask for what's possible.

Asked for "a new level which spawns the player in a corridor built from SCI_AndroidLab", an assistant works through something like this:

1. create_level makes and opens a new level, as File → Create Level does.
2. search_level on PRODUCTION/SCI_ANDROIDLAB finds Archetypes\Script\Mission\SpawnPositionSelect, the composite that holds the player's Character. It also finds the corridor pieces under AYZ\Science\...\Corridor_Elements, and where the level places them.
3. port_composites brings them in, with their models, materials, textures and collision. The player's display models (DisplayModel:RIPLEY_FP and the suit variants) come along automatically.
4. create_entities places the floor, wall and arch pieces in the new level's root composite, spaced by their sizes. It also places a SpawnPositionSelect instance on the floor, with spawn_on_reset set to true so the player spawns there when the level starts.
5. create_composite can add some script as well. For example, a light that a ThinkOnce switches on at the start. Its flowgraph page is laid out automatically.
6. capture_viewport lets it look at the result, and save_level with Save & Build writes the level and builds its navmesh, lighting and the rest. Then it's ready for Launch Game.

Asked to "make a CAGEAnimation that moves a camera round the room called Canteen", an assistant works through something like this:

1. find_places finds the room by its name (forgiving misspellings): on Torrens, the Canteen composite and the Zone_Canteen zone that streams it.
2. sample_space picks points round the room at eye height, clear of the walls and furniture, by casting rays against the room's collision as it stands in the editor (your unsaved changes included). Each leg between points is checked for line of sight.
3. create_camera_animation does the rest as one undo step: a CameraResource, a CAGEAnimation that moves it smoothly along those points at a steady speed (looping, if asked), and the links that switch the camera on, start the animation when the room loads, and hand the view back at the end.
4. check_cage_animation confirms nothing is missing for it to play in game, and preview_cage_animation shows a few frames through the camera in the Viewport, or a frame from the running game over Live Link. Then save_level.

MCP apps that support prompts also list a few ready-made tasks, such as a camera fly-through, zoning a level, and porting and placing content from another level.

• Undo. Every scripting change the assistant makes is one step on the editor's undo history, named with an AI: prefix ("AI: Add 17 entities"). Edit → Undo (or asking the assistant to undo) takes it back. This covers everything in the level's script: entities, parameters, links, trigger sequences, CAGEAnimations, entity resources (models, collision, physics), flowgraph pages and nodes, and composites (new, renamed, moved, deleted, De-instance, Create Composite). It also covers changes to the level's materials, material mappings and textures. A task that takes several requests can be made one step, so a single undo takes the whole task back. The assistant won't undo a change you made unless you ask it to. Porting composites, imports, and changes to animations, sounds, behaviour trees, the user interface (UI.PAK), configuration files and text can't be undone, as when you make them yourself; the tools that change files every level shares can do a dry run first.
• Saving. Nothing reaches the game until the level is saved, unless the game is running with Live Link, which takes script edits as they're made. The assistant saves only when asked (or when its task says to). Script changes need only a save (a Save and Build is for physical changes: added or moved geometry and models). Files every level shares are the exception: changes to configuration files, text, sounds, animations, behaviour trees and the user interface are written straight away, as are which text databases a level loads and the mods the assistant installs or removes.
• Flowgraphs stay drawn. When the assistant adds links to a composite shown as flowgraph pages, the new links are drawn on its pages, next to what they connect, so they survive the next save. A new composite gets pages laid out for it, the same way Arrange Page lays out a page, and the assistant can tidy a page that's got tangled by arranging it. A link the flowgraph editor has no way to draw is refused with an explanation (usually it runs the wrong way), rather than made and lost later. Composites shown as a plain link list are left as they are, unless the assistant is asked to lay them out.

An assistant can choose what the game is started with (launch_options), start it (launch_game), and, while it runs with Live Link, work with it through runtime_utils. Its script edits reach the game as they're made, as yours do, and it can call methods on entities, take screenshots of the game, change its live settings, and use the game's Debug Menu and OpenCAGE's script debugger.

Launch Options

launch_options reads and sets the options in the Launch Game window, by name; given none, it reports them all. Those for OpenCAGE's runtime utils in the game are:

• live_link (the Live Link box), hot_reload and debug_entities, from the Debug tools group, and unlock_mouse and cap_fps, from Game options, with hot_reload_key, unlock_mouse_key and cap_fps_rate. debug_entities is the one Debug entities box; the old names debug_text, debug_text_stacking, debug_environment_marker and debug_position_marker are still taken for it: any of them true turns it on and all of those given false turn it off, unless debug_entities is given too, which decides.
• possess_characters and possess_key.
• debug_menu, the Debug Menu box, and debug_menu_key, the key that opens it.
• dont_write_saves, Don't write saves. It's part of the Debug Menu, so it only works with debug_menu on: with it off, the assistant is told that the game will write its saves as usual.
• cinematic_tools is still taken, though Cinematic Tools are part of the Debug Menu now, in its Cinematic group. true is taken as debug_menu: true, unless debug_menu is given too, and false changes nothing. The assistant is told so each time it's used.

The window's other options are there too: render_constant_ambient, no_ui (No HUD) and patch_current_gen_optimisations (Current-gen script fixes), written to the game executable straight away, and the UI tweaks quit_to_menu_on_death and debug_loadscreen. Options Launch Game no longer has are still taken, and change nothing: skip_frontend is ignored, as skipping the title screen goes with the level (a launch into a level always skips it, one at the main menu never does), and ui_memory_overlay, memory_logging, debug_checkpoints and level_selection come with a note saying where each went (the Debug Menu's Performance > Memory, Game > Tools and Game > Game flow; memory logging is gone).

The runtime utils options take effect the next time the game is started. launch_game puts the runtime utils in the game folder, or takes them out, as they say, writes the game executable's patches and sets up the UI tweaks as the Launch Game window does, and its answer says whether this run has the runtime utils options, Possess characters, the Debug Menu and Don't write saves. A level given to launch_game (the open level when none is given) always starts past the title screen, and menu starts it at the main menu, so its own skip_frontend is ignored too.

The Debug Menu

With the game started with both Live Link and the Debug Menu, runtime_utils with action debug_menu works the menu, as The Debug Menu Over Live Link describes. menu says what to do:

• report (the default): whether the window is open, the group and tab in front, the selected character, the groups, tabs and commands, every value with its number, and every switch with whether it's on.
• open and close: the window.
• tab: brings the tab named by name to the front (or a group, by its name).
• select: selects the character whose name, or failing that whose class, contains name.
• set: turns the switch name on or off, as value says.
• value: sets the value name to number, kept within its range.
• run: runs the command name with argument, and gives back what it answers, line by line. The command help lists them all, with what each takes.

A tab or character picked this way is taken up at the window's next frame, so report again to see it. The window, and what the menu draws over the game, are in the game's picture, so runtime_utils' screenshot shows them.

The Script Debugger

runtime_utils with action debugger uses the script debugger, which also needs the game started with both Live Link and the Debug Menu. debugger says what to do:

• state (the default): whether the level's scripts are held, and whether at a breakpoint; the last breakpoint hit, with its method and entity, the composite and instance path it's in, the time on the scripts' clock, the steps made since, and the calls that led to it; and the breakpoints.
• set: a breakpoint on entity in composite (the open composite unless it's given), stopping on all its methods, or only on method. It's set in the instance at instance_path; without one, in the instance the open composite was reached through from the level's root, or in every running instance if the composite isn't open, or was opened on its own. every_instance sets it in every one.
• remove: takes that breakpoint away, or with method, only that method.
• list: the breakpoints, each with its methods, whether it's stopping the game, the running instances it's in, its hits and any problem. clear takes them all away.
• continue; step, one round of calls; step_frame, one whole frame of the game; and pause, which holds the scripts now.
• pick: the entity under the game's crosshair (with the crosshair inspector on, on the Debug Menu's World > Inspect tab), found in the level open in OpenCAGE and selected there unless select is false, as Select Entity Under Game Crosshair does.
• states: the state of each entity of composite in one running instance (started, enabled, locked...), up to limit of them (200 unless given). The instance is picked as for set; if that leaves more than one running, it says so instead.

The breakpoints are the same ones the flowgraphs draw: one the assistant sets shows on its node, and the ones you set are in its list. A breakpoint stops the whole game until something lets it go on, so if an assistant leaves the game held, press Continue on the composite toolbar, or F8 on a flowgraph. Breakpoints aren't part of the level: they aren't on the undo history, and aren't saved.

• Be specific about where things come from. The assistant finds its way around faster if you name a level to borrow from, and the kind of content you want.
• Back up first. Ask for a backup (or make one with the Backup Manager) before letting an assistant loose on a level you care about. Saving is always a separate, explicit step.
• Level design still takes looking at. The assistant places pieces by the numbers: their positions, sizes and how the shipped levels arrange them. Check the result in the Viewport, and ask for fixes.
• Launching the game kills a running copy. So does saving, as usual.
• Try changes in the running game. With the game started with Live Link ticked, the assistant's script edits reach it as they're made, as yours do, and runtime_utils lets it check what the game is running, call methods on entities, take screenshots of the game, work the Debug Menu and stop the scripts at breakpoints (see In the Running Game). set_viewport_view's live_link_camera links the game's camera and the Viewport's. See Live Link.
• Keep testing out of your saves. Ask for launch_options dont_write_saves (with debug_menu), and the game writes nothing to your saved games while the assistant tests.

• Cathode Scripting Introduction — composites, entities, links and parameters
• Create Level — what a new level contains
• Composite Porting — bringing content in from other levels
• Save and Build — building a level so it runs in game
• Viewport — seeing the level in 3D
• Live Link — script edits, method calls and the script debugger in the running game
• Debug Menu — the in-game debug menu an assistant can work
• Options — turning AI assistants on and off