Toolsets Architecture

ClaudusBridge exposes the Unreal Editor to an AI agent as a large, structured library of callable tools — ~900+ tools across roughly 65 toolsets. Almost all of these are not hand-written. They are generated automatically from Unreal's own reflection system, then surfaced through the MCP server. On top of that reflection-driven catalogue, ClaudusBridge ships a handful of purpose-built native plugin toolsets, and lets you author your own tools.

This guide explains where all those tools come from and how to add to them.

Where the tools come from

There are three sources of tools, layered from most to least numerous:

1. Reflection-driven toolsets — generated from the engine via UToolsetDefinition and UFUNCTION(meta=(AICallable)), surfaced through the ToolsetRegistry / AllToolsets engine plugins.
2. Native plugin toolsets — five hand-written C++ toolsets shipped by ClaudusBridge for things the reflection layer does not cover (Multi-User, Asset, Level, Image, Chess).
3. User-authorable ToolLibrary Blueprints — your own tools, added by subclassing UClaudusBridgeToolLibrary.

All three converge on the same MCP server and are presented to the agent identically through list_toolsets / describe_toolset / call_tool (in the default tool-search mode).

1. The reflection-driven toolset system

This is the bulk of the catalogue. Unreal's editor subsystems already describe themselves through reflection (UCLASS, UFUNCTION, UPROPERTY metadata). The ToolsetRegistry plugin harvests that metadata: any UFUNCTION marked meta=(AICallable) on a UToolsetDefinition becomes a callable MCP tool, with its parameters turned into a JSON input schema and its return value into an output schema. Doxygen-style comments on the function become the tool's description, so the agent knows what each tool does.

The AllToolsets plugin pulls in the full set of engine-provided toolset definitions, covering domains such as:

• Actors / World — spawn, transform, select, query actors and components.
• Blueprints — create and edit Blueprint assets, graphs, variables, and functions.
• Materials — author material graphs and instances.
• Niagara — build and configure particle systems.
• UMG / Widgets — assemble user-interface widgets.
• Sequencer — author cinematics and animation tracks.
• Assets — find, duplicate, import, and manage content.
• Levels — open, save, and organise maps.
• Textures — inspect and manipulate texture assets.

…and many more, totalling roughly 65 toolsets.

How they reach the MCP server

ClaudusBridge's editor module owns a FToolsetRegistryToolAdapterManager that walks every toolset the registry knows about. For each tool it reads the registry-generated JSON schema (name, description, input schema, output schema). What happens next depends on the server's mode:

• Tool-search mode (default): the manager registers only the three meta-tools (list_toolsets, describe_toolset, call_tool). Toolset tools are not registered individually; instead, a call_tool invocation is dispatched through the ToolsetRegistry on demand. Each tool's outputSchema is cached up front (keyed by its fully qualified name) so media (such as captured images) can be extracted from results even though the tools themselves were never registered.
• Eager mode: the manager creates one FToolsetRegistryToolAdapter per tool and registers each as a native MCP tool, so they all appear in tools/list.

Either way, when a tool runs, the adapter wraps execution in an editor transaction (so the agent's changes are undoable), serialises the arguments to JSON, calls ToolsetRegistry::ExecuteTool, and converts the JSON result back into an MCP tool result.

Tool names are qualified by their toolset, e.g. ToolsetRegistry.AgentSkillToolset.ListSkills. A bare leaf name (AgentSkillToolset) resolves to the full name, but the fully qualified form is preferred.

2. The five native plugin toolsets

Some capabilities are specific to ClaudusBridge and are hand-written in C++ as dedicated toolsets in the editor module. Each is a UToolsetDefinition with AICallable functions, so it flows through the exact same registry/adapter path as the engine toolsets — but ships inside the plugin.

Toolset	What it does
Multi-User (UClaudusBridgeMultiUserToolset)	~11 strictly non-blocking tools that let the agent and a human join the same Concert session as separate participants, each with a desktop presence avatar, reusing Unreal's existing Multi-User client. Covers discovering servers/sessions, joining/leaving, presence, and avatar control.
Asset (UClaudusBridgeAssetToolset)	~8 tools for finding, duplicating, and managing content-browser assets.
Level (UClaudusBridgeLevelToolset)	~6 tools for saving and organising levels: SaveCurrentLevel, SaveCurrentLevelAs, SaveAll, CreateFolder, and more.
Image (UClaudusBridgeImageToolset)	~3 tools for returning rendered/captured images to the agent as inline media.
Chess (UClaudusBridgeChessToolset)	~13 tools for a self-contained agent-vs-human 3D chess game built from primitive pieces: SetupChessGame, GetBoardState, MovePiece, RemovePiece, SpawnPiece, ClearChessGame, and autonomous-play helpers. A showcase of how far a native toolset can go.

Because these are native UToolsetDefinitions, they need no separate registration step — they are discovered and dispatched alongside everything else.

3. Authoring your own tools — ToolLibrary Blueprints

You can add your own native tools without forking the plugin by subclassing UClaudusBridgeToolLibrary. This is a specialised UBlueprintFunctionLibrary that automatically registers an MCP tool for each public function you define on it, deriving the tool name, description, and parameter schema from the function and its doxygen-style tooltip.

Adding a tool library in Blueprints

1. In the Content Browser, choose Add → ClaudusBridge Tool Library.
2. Add a public function for each tool you want to expose.
3. Give each function a doxygen-style tooltip — it becomes the tool's description, and the parameter comments become the parameter descriptions.

That is all. On module load, every public function is reflected into an FClaudusBridgeLibraryTool, its inputs become a JSON input schema, its outputs an output schema, and it is registered with the MCP module (controlled by the bAutoRegisterTools flag, default on). Function metadata is cached into the asset, so descriptions survive cooking.

Adding a tool library in C++

Subclass UClaudusBridgeToolLibrary and add UFUNCTIONs. Each public function is auto-registered the same way:

UCLASS()
class UMyProjectTools : public UClaudusBridgeToolLibrary
{
    GENERATED_BODY()
public:
    /** Resets the player's score to zero and returns the new value. */
    UFUNCTION()
    static int32 ResetScore();
};

A note on the recommended path

For brand-new tools, prefer authoring a UToolsetDefinition with UFUNCTION(meta=(AICallable)) functions — this is the same mechanism the engine and the five native toolsets use, and it integrates fully with the ToolsetRegistry (schema generation, tool-search discovery, output-schema media extraction).

UClaudusBridgeToolLibrary remains supported as a simpler, Blueprint-friendly path and a legacy fallback, but it is marked deprecated in favour of UToolsetDefinition; new C++ tools should target the toolset definition API.

How it all fits together

Engine reflection (UToolsetDefinition + UFUNCTION meta=(AICallable))
        │
        ├── ToolsetRegistry / AllToolsets  ──► ~65 toolsets, ~900+ tools
        │
Native plugin toolsets (UToolsetDefinition)
        │   Multi-User · Asset · Level · Image · Chess
        │
User ToolLibrary Blueprints (UClaudusBridgeToolLibrary subclasses)
        │
        ▼
  FToolsetRegistryToolAdapterManager  ──►  FClaudusBridgeServer (MCP)
        │
        ▼
  list_toolsets · describe_toolset · call_tool   (tool-search mode)
        or every tool registered natively         (eager mode)
        │
        ▼
            The agent / any MCP client

To learn how the server presents and dispatches these tools — including the difference between tool-search and eager mode — see the MCP Server guide.