How Crimson MCP Works

Model Context Protocol (MCP) lets an AI agent call editor operations as structured tools. UE 5.8 ships an MCP server in the editor plus a Toolset Registry; Crimson plugs its own tools into that registry. This page explains the moving parts so the toolbar and settings make sense.

Toolsets, not flat tools

In UE 5.8 an AI tool is a static function tagged UFUNCTION(meta = (AICallable)) on a UToolsetDefinition subclass. The class name is the toolset's name; each function is one tool, addressed as Toolset.Tool (e.g. CrimsonSourceToolset.ReadFile). Crimson ships three such toolsets. The engine's Toolset Registry discovers them and bridges each into the MCP server automatically.

Tool search keeps the list small

With Enable Tool Search on (the engine default), the server exposes just three meta-tools - list_toolsets, describe_toolset, and call_tool - and the agent discovers real tools on demand instead of loading hundreds of schemas up front. This is the key reason Crimson uses toolsets: a flat tool registered the old way is callable by exact name but is not surfaced by list_toolsets, so an agent would never discover it.

The master switch cascades

UCrimsonMCPSettings::bEnableCrimsonMCP (Project Settings -> Crimson -> Crimson MCP) is read once at module startup. Every Crimson plugin checks it before registering any MCP tool, so this one switch turns the entire suite's MCP surface on or off - and because it is read at startup, changing it needs an editor restart. CrimsonEditorUtilities registers its three toolsets only when the switch is on.

Two layers for enabling Epic's toolsets

Epic's toolsets each live in their own plugin. Making one available has two independent layers, which is exactly what the Crimson MCP toolbar exposes:

A toolset must be loaded (layer 1) before it can be shown (layer 2). The toolbar's 'Epic Toolset Plugins' section drives layer 1; the 'Toolset Visibility (loaded)' section drives layer 2.