Toolsets Architecture

ClaudusBridge exposes the Unreal Editor to an AI agent as a large, structured library of callable tools — a live catalog determined by the project, engine version and enabled plugins. 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 — C++ toolsets shipped by ClaudusBridge for reflection, domain-specific editing, coordination, image handling and collaboration.
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.

Use claudus toolsets to inspect the catalog available in your project. Listing tools requires the Unreal backend, even when its GUI is closed.

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 the three discovery 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.

The adapter converts arguments and results around ToolsetRegistry::ExecuteTool. Transaction support depends on the tool: some manage their own transaction or opt out, and asynchronous or external effects are not automatically undoable. Saving a package is a separate operation. Native dispatch also applies the current agent's policy and package ownership rules.

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. 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 family	What it does
Reflection	Inspect classes/objects, edit supported properties, invoke reflected functions and save packages.
Orchestration	Query backend activity, manage jobs, agent sessions and package leases.
Material and Niagara	Domain-specific graph authoring, instance settings and compilation workflows.
Blueprint and Simulation	Component/scaffolding helpers and game-state inspection in an appropriate world or play context.
Asset, Level and Image	Content operations, map persistence and image handling; capture tools require their rendering context.
Multi-User	Concert session participation and presence for compatible, separate project roots.

This is an overview, not an exhaustive API list. Discover each family's exact toolset name and schema with toolsets and describe.

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 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  ──► project-dependent live tool catalog
        │
Native plugin toolsets (UToolsetDefinition)
        │   Reflection · Orchestration · domain tools
        │
User ToolLibrary Blueprints (UClaudusBridgeToolLibrary subclasses)
        │
        ▼
  FToolsetRegistryToolAdapterManager  ──►  FClaudusBridgeServer (MCP)
        │
        ▼
  list_toolsets · describe_toolset · call_tool   (tool-search mode)
        or every tool registered natively         (eager mode)
        │
        ▼
     Native loopback connection → Claudus CLI
        │
        ▼
            The agent / stdio MCP client

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