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;
• --no-launch — only work with an OpenCAGE that is already open;
• 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 (No, then Cancel, 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.

• 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). Porting composites, imports, and changes to models, materials, textures, animations, sounds, 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). Configuration files are the exception: they're shared by every level and written straight away.
• 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.

• 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 Enable Live Link, 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 and take screenshots of the game. set_viewport_view's live_link_camera links the game's camera and the Viewport's. See Live Link.

• 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 and method calls in the running game
• Options — turning AI assistants on and off