Skip to content

Setup & Connecting an Agent ProOnly

This page covers installing Logic Driver Assist, building it, confirming the operation registry is live, and wiring a transport so a client can reach it. The transports themselves, with their per-provider ports and call mechanics, live on Transports & Bridges. For what the plugin is and how it fits together, start with the Overview.

Requirements

  • Logic Driver Pro 2.11+ installed in the project.
  • A C++ project (or at least one C++ module). Assist is a C++ editor plugin and must be compiled; it is not a Marketplace/binary install.
  • For the ToolsetRegistry transport only: Unreal Engine 5.8 or newer with the engine's experimental ToolsetRegistry and ModelContextProtocol plugins.

1. Place the plugins

Assist is a companion plugin, dropped into the host project's Plugins/ folder alongside Logic Driver. Download it from its GitHub repository, Recursoft/LogicDriver-Assist. Logic Driver Pro itself comes from the private Pro repository. See GitHub Access for how to obtain it. Place both plugins under Plugins/:

  • Plugins/LogicDriver/: Logic Driver Pro.
  • Plugins/LogicDriver-Assist/: this plugin, from GitHub.
  • Plugins/Monolith/: optional, only if you want the Monolith MCP bridge.

2. Enable and build

Enable SMAssist in the host .uproject. You do not need to separately enable Logic Driver or the transport plugins; SMAssist's descriptor already pulls them in, including the optional transports when present. Then build the Development Editor target normally.

The optional transport modules light up automatically based on what is present: the Monolith bridge compiles when Plugins/Monolith/ exists in the project, and the ToolsetRegistry adapter compiles when the engine ships ToolsetRegistry. Nothing needs to be toggled by hand.

3. Confirm the operations are live

Launch the editor. Every operation self-registers at startup. Before wiring any client, confirm the plugin loaded by running this in the editor console:

LDAssist.List

It prints the registered operations. If you see them, the registry is up and any transport you enabled is serving the same set. LDAssist.Describe <operation> prints one operation's impact classification (read_only or destructive) and JSON input schema, which is the quickest way to read an argument list before a client calls it.

4. Choose a transport

Assist is transport-agnostic: the operations you just listed behave identically no matter which transport carries the call. Pick one by engine version and how you want to drive it.

  • Console, for smoke tests with no server. You already used it in step 3 (LDAssist.List); LDAssist.Exec runs any operation by hand.
  • Monolith bridge, for an MCP client on any supported engine version.
  • Engine ToolsetRegistry, on UE 5.8+, using Epic's built-in MCP server.
  • Ultimate Engine Co-Pilot, if you already use that third-party copilot. Its Logic Driver extension registers Assist's operations as UECP tools, reachable from UECP's chat, MCP server, and ACP agents.

The per-provider ports, call mechanics, config, and gotchas are on Transports & Bridges. Read the section for the transport you picked before wiring a client.

5. Connect your MCP client

The Monolith and ToolsetRegistry transports speak HTTP, so any MCP client that supports an HTTP (streamable) server can reach them. Point the client at the transport's URL: http://localhost:9316/mcp for the Monolith bridge, or http://localhost:8000/mcp for the engine ModelContextProtocol server. Restart or reconnect the client after editing its config, then confirm it lists the operations.

The exact config format depends on the client (Claude Code, Claude Desktop, Cursor, Cline, and others). Transports & Bridges has a concrete .mcp.json example and the per-provider call details. On Ultimate Engine Co-Pilot there is no URL to configure: enable its Logic Driver extension, restart the editor, and the ld_* tools appear wherever UECP's tools already do. See Transports & Bridges.

On Monolith, keep the agent on ld.*

The Monolith bridge is the one transport where an agent also sees a native logicdriver.* surface. Keep it on ld.*; Transports & Bridges covers why and how.

Verify end to end

With a transport wired, have the client (or the console) run a create-then-read round trip:

  1. ld.create_blueprint to mint an asset.
  2. ld.add_state against the returned asset_path.
  3. ld.get_asset to read the topology back and confirm the state is present.
  4. ld.compile and check the result reports clean.

Once that round trips cleanly, point your agent at the transport and give it the conventions in Authoring with an AI Agent. If any step fails, Troubleshooting maps the common symptoms to fixes.

A first agent session

With the client connected, a prompt like "Build a three-state traffic light state machine in /Game/MCP/TrafficLight and confirm it runs" drives a call flow along these lines:

  1. list_toolsets / describe_toolset (or the Monolith discovery tool) to read what the transport exposes. The names an agent sees are the transport's: ld.* operation names on the console and the Monolith bridge, typed function names such as CreateBlueprint on the ToolsetRegistry toolset.
  2. ld.create_blueprint to mint SM_TrafficLight, then ld.add_state for Red, Green, and Yellow, with one marked is_entry.
  3. For each transition, ld.add_transition, then gate it on time-in-state by authoring the transition graph with the bound-graph operations. What the Calls Look Like walks that five-call sequence and shows the graph it produces.
  4. ld.layout_states with apply=true, then ld.compile.
  5. Adding the SM component to an actor, placing that actor in a level, and starting PIE are done in the editor by hand (or with generic engine tools), not through ld.*; once PIE is running, ld.runtime_get_state confirms the active state advances.

The conventions in Authoring with an AI Agent are what keep this flow producing clean, compiling graphs, so give them to your agent up front. For the same flow shown call by call with the graphs it produces, see What the Calls Look Like. For a larger conversation system driven by prompts rather than raw calls, see A Dialogue System & the Lighthouse.