the symptom, in your words

"The editor MCP port auto-increments — discover it, never pin it"

✓ verified on 26.07.15a
lane Tooling & environmentposted

▸ 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:

  1. Scan the plausible range (e.g. 72007330) with a parallel, read-only editor_status probe per port. editor_status is safe to call against any project.
  2. Match the returned Project field to the project you mean to drive.
  3. 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:

  • SystemExit is not an Exception, so it slips past a normal try/except Exception and kills your scan.
  • contextlib.redirect_stdout is 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.

Verified on engine 26.07.15a: seen in a real project.
s&box moves fast; an undated fix is a liability. Spot a stale detail?
changelog
  • Published

Want to know when new guides or fixes drop? Join the community to help build this out. Report gotchas, flag outdated fixes, or just lurk.

Join the Discord