Agents and MCP · ignifx editor

The editor serves the project it has open to coding agents over the Model Context Protocol (MCP). An agent can read the scene, edit it, look at it, play the game, write scripts and build, and every edit it makes lands on the same undo history as yours, in front of you. The editor is a preview; the MCP shim agents run is published as @ignifx/editor-mcp 0.1.1.

Agents can also work on an ignifx project with no editor at all: scenes, prefabs, materials and settings are JSON, scripts are TypeScript, and the engine ships an Agent Skill. MCP adds what files cannot give: eyes on the scene, play mode, the console, undo and builds.

Set up agents#

Open the project in the editor.
File → Set Up Agents… shows one checkbox per client and previews the file each one gets:

Client File it writes
Claude Code .mcp.json
Cursor .cursor/mcp.json
VS Code .vscode/mcp.json
Codex CLI .codex/config.toml
Gemini CLI .gemini/settings.json
Apply. The editor writes an ignifx server entry that runs npx -y @ignifx/editor-mcp, installs the engine's skill to .claude/skills/ignifx and the editor's own skill to .claude/skills/ignifx-editor, and switches the project's MCP server on. Other entries in those files are kept.
Approve the server in your client. The editor never writes approval settings: Claude Code keeps a new project server pending until you approve it, and Codex reads a project's config only once you trust the folder. The dialog says what to do for each client.

Client	File it writes
Claude Code	`.mcp.json`
Cursor	`.cursor/mcp.json`
VS Code	`.vscode/mcp.json`
Codex CLI	`.codex/config.toml`
Gemini CLI	`.gemini/settings.json`

The config holds no secret, so it is safe to commit. The shim finds the running editor through .ignifx/mcp.json (the port, a token and the editor's process id), which git ignores. Because of the shim, an agent keeps working across editor restarts; while the editor is closed, every call answers with the cause and the fix.

Switching the server on and off#

The MCP server is off by default for every project and is switched per project with File → MCP Server or the MCP chip in the status bar. The choice is kept in the editor's own data, never in the project, so cloning a repository never switches it on. The server listens on 127.0.0.1 only, on a random port, behind a random token, and refuses any request from a browser page.

The tools#

Thirty tools, all prefixed ignifx_:

Family	Tools
Project	`project_info`, `read_console`
Scene	`scene_outline`, `get_entity`, `list_components`, `create_entity`, `set_props`, `add_component`, `remove_component`, `instantiate_prefab`, `apply_ops`, `open_scene`, `save_scene`
View	`screenshot`, `frame_entity`, `pick`
Play	`play`, `pause`, `step`, `stop`, `query_runtime`, `send_input`
Scripts	`create_script`, `typecheck`
Build	`build_start`, `build_status`, `publish`
History	`undo`, `redo`, `history`

Every scene edit is one named step on the shared undo history and shows in the Hierarchy and the Inspector as it lands. Nothing reaches the scene file until ignifx_save_scene. Results are capped at about 40,000 characters, with cursors to page and hints to narrow; screenshots are capped in size. There is no tool that runs arbitrary code.

Not yet: asset import tools and 2D tools (tile painting, atlas packing, sprite animation). Agents edit those files directly for now.

The confirmation gate#

The editor, not the agent, decides which calls need your yes. A tool that may discard work or reaches outside the project asks first: ignifx_apply_ops, ignifx_undo, ignifx_remove_component, ignifx_open_scene and ignifx_publish. The editor shows the request with Allow once, Allow for this project and Deny. No answer within 20 seconds is a denial, and a denied call changes nothing.

Trust agents in this project (in the status bar, or by answering Allow for this project) stops the questions, except for ignifx_publish, which asks every time and names the target and the address.
Read-only makes the project read-only for agents: every tool that changes something refuses, and reads, screenshots and runtime queries still work.

Tools never take credentials. Publish targets are set up by you, in the Build panel.

The audit log#

Every tool call, and every change to trust or read-only, is written to .ignifx/logs/mcp-YYYY-MM-DD.jsonl (one file per UTC day; the newest 14 are kept). A line holds the time, the tool, the client's name when it sent one, the outcome (ran, failed, refused by read-only, denied), the duration and a short summary of the arguments with secrets and file contents left out. The log stays in the project's private .ignifx/ folder.

The editor skill#

The ignifx-editor skill tells an agent how to work with the editor: read first, write with the narrowest tool and the scene's epoch so an edit lands only on the scene it read, check by screenshot, save on purpose, use files for scripts and assets and tools for the open scene, undo only its own steps, never retry a denied or read-only call, and ask before publishing. It also lists every refusal code and what to do about it. Set Up Agents installs it beside the engine's ignifx skill, which covers the engine's APIs and file formats.

The evaluation suite#

The editor's repository carries an evaluation suite of ten realistic tasks an agent does through the MCP server: a light placed and checked by screenshot, a scene built from a prompt, a new script type-checked, a type error fixed, a tilemap edited, a game played and measured, an undo that must not touch your steps, a web build, a destructive edit declined at the gate, and a read-only project. Each run is scored mechanically against the project's final state and by a person against a rubric: correctness, tool choice, undo hygiene, verification, and refusal handling. Claude Code is the reference client; Codex CLI, Cursor, Gemini CLI and VS Code follow. Preview: the suite and its harness exist; scored runs with real clients have not been published yet.