How the Agent Connects

The chain

   ┌──────────────────────────┐
   │      Unreal Editor       │
   │                          │
   │  ┌────────────────────┐  │
   │  │ Conductor Terminal │  │   ← you type here
   │  │   ┌────────────┐   │  │
   │  │   │ your agent │◄──┼──┼── runs as a normal CLI
   │  │   │    CLI     │   │  │   process in a real PTY
   │  │   └─────┬──────┘   │  │
   │  └─────────┼──────────┘  │
   │            │ MCP over HTTP
   │            ▼             │
   │  ┌────────────────────┐  │
   │  │ ModelContextProto- │  │   ← Epic's local MCP server
   │  │ col server :8000   │  │      (UE 5.8+)
   │  └─────────┬──────────┘  │
   │            ▼             │
   │  ┌────────────────────┐  │
   │  │  ToolsetRegistry   │  │
   │  │  ├ Epic toolsets   │  │   ← actors, assets, blueprints…
   │  │  └ Cndctr Terminal │  │   ← this plugin's 12 tools
   │  └────────────────────┘  │
   └──────────────────────────┘

Three things are worth pulling out of that diagram.

Your agent is just a process. It runs in the terminal like any other command-line program, in a real ConPTY. Conductor Terminal does not wrap it, proxy it, or sit between it and its model. Your API keys, your config, your usage — all of it stays exactly where it already was.

The connection is plain HTTP MCP. The agent dials http://127.0.0.1:8000/mcp (or whatever port and path your MCP settings specify) like it would any other remote MCP server. There is no bespoke protocol here.

The editor surface comes from Epic. Reading assets, moving actors, compiling blueprints — those are Epic’s toolsets, published through their ToolsetRegistry. Conductor Terminal adds its own toolset alongside them, covering the terminal itself.

What this plugin adds

UConductorTerminalToolset publishes twelve tools, plus an Agent Skill (UConductorTerminalSkill) — a playbook the agent receives that explains how the terminal works, which tools to call in what order, and what the return values mean.

The skill also injects live state on each turn: whether the subsystem is up, a debug summary of Terminal 0, and whether psmux was detected. An agent that starts a turn already knowing psmux is missing does not waste a tool call finding out.

The rule about which tools exist

There is a design rule behind the tool list, and it explains a conspicuous absence.

A tool belongs here if it improves the dialogue between the human and the agent.

The agent already runs commands through its own tooling and already sees its own output and exit codes. So a RunCommand tool — “make the terminal execute this and report the result” — is redundant, and is deliberately not built. It was designed in detail, along with the OSC-133 command-span reader that would have supported it, and then dropped: it solved a problem this product does not have.

The tools that are built are the ones that let the agent take part in the surface you are both looking at:

• ReadTerminalOutput / GrepTerminalOutput — see what is on screen, including what you typed
• ListTerminals — enumerate the panes you share
• NotifyUser — get your attention without stealing focus
• the split/session/settings tools — arrange the shared workspace

If you find yourself wanting a tool, the useful question is not “would this be handy?” but “does this make the conversation better?” That is the bar.

Editor context

By default each agent turn is prefixed with a short snapshot of editor state — the current level, your selected actors, recent errors — so the agent knows what you are looking at without asking.

It is bounded, but it is not free: it goes into the prompt on every turn and therefore into your token cost. See Notifications & Editor Context for how to turn it off.