"The editor MCP port auto-increments — discover it, never pin it"
▸ SYMPTOM
An MCP tool call that worked yesterday now hits the wrong editor, or times out. A port you hardcoded (or remembered from a previous session) either answers with a different project's editor or nothing at all. Mutating calls — anything that changes a scene or asset — are the dangerous case: they land against whichever project happens to hold that port right now.
▸ CAUSE
The editor MCP port cannot be pinned per project. It is a single engine-global preference (McpServerPort in the engine's config/tools.json). When the configured port is already bound by another open project editor, the editor auto-increments to the next free port. So with several editors open, each project ends up on a launch-order-dependent port.
Verified with four editors live: the config said 7271; the first editor to launch held 7271 and the other three had bumped to neighbouring ports. Consequences:
- Any hardcoded or remembered port goes stale on every restart or launch-order change.
- A port that answered yesterday can be a different project today — the silent, dangerous failure, because a mutating call succeeds against the wrong editor.
▸ FIX
Stop pinning. Discover the port at run time:
- Scan the plausible range (e.g.
7200–7330) with a parallel, read-onlyeditor_statusprobe per port.editor_statusis safe to call against any project. - Match the returned
Projectfield to the project you mean to drive. - Feed the found URL to all tooling via an env var, so every call targets the confirmed editor.
A ~130-port threaded scan completes in about a second.
Implementation caveats
Write the probe as a self-contained raw JSON-RPC POST (e.g. urllib). Do not reuse an interactive MCP client helper that prints guidance and calls sys.exit() on an unreachable port:
SystemExitis not anException, so it slips past a normaltry/except Exceptionand kills your scan.contextlib.redirect_stdoutis process-global and not thread-safe, so it corrupts output under a parallel scan.
A minimal per-port probe that opens a socket, POSTs an editor_status request, reads the Project, and returns the URL is all you need.
▸ WHY IT WORKS
Because the port is assigned by launch order and not by project, the only reliable identifier is the Project field the editor reports about itself. Scanning and matching that field targets the editor by identity instead of by a number that drifts — so tooling always talks to the intended project, and a mutating call can never silently land on the wrong one.
- Published