Plugins

ue-mcp's plugin system lets npm packages extend the server in three ways:

• Inject new actions into ue-mcp's built-in categories so agents discover them where they're already working.
• Provide entirely new top-level categories that the plugin owns end-to-end.
• Ship native C++ that registers handlers directly with the editor bridge, opening up engine APIs that have no built-in coverage.

Most plugins use only the first shape; the other two are available when injection is the wrong fit. This section splits into using a plugin somebody else wrote and writing your own.

Browse and search published plugins in the registry at plugins.ue-mcp.com, then install any listing by its slug with ue-mcp plugin install [slug].

Quick start

In your Unreal project directory:

ue-mcp plugin install <slug>

That runs npm install --save, validates the plugin's manifest, deploys its native C++ module if it has one, and adds an entry to your ue-mcp.yml. When a native module was deployed, rebuild the UE project so it compiles in. Then restart your MCP client (in Claude Code, /mcp reconnects).

Verify with the introspection tool:

plugins(action="list")

The plugin's entry reports status: "active" and lists the categories it injects into or provides. Its actions are then callable like built-in ones, for example [category](action="[prefix]_[action]", ...) for an injected action. Full consumer details are in Using plugins.

How plugins work

A plugin is a normal npm package that ships:

• A ue-mcp.plugin.yml manifest declaring an actionPrefix, the actions it injects into which host categories, and the task classes that back them.
• Compiled task classes (one per injected action) under dist/, each extending UeMcpTask from ue-mcp/task.
• Optional knowledge/[category].md markdown that the server attaches to the host category's AI-facing docs at boot.
• Optional flows: entries that compose injected actions with built-ins.

At server start, ue-mcp:

1. Reads plugins: from your project's ue-mcp.yml.
2. Resolves each entry against [project]/node_modules/.
3. Loads and validates each plugin's ue-mcp.plugin.yml.
4. Imports its task classes and registers them with the flow runtime.
5. Merges the injected actions into the host category tools - the action shows up as [category](action="[prefix]_[bare]", ...).
6. Concatenates the plugin's knowledge files into the host categories' AI-facing docs.

The injection happens before any tool is registered with the MCP client, so by the time the agent sees the gameplay tool's action list, the plugin's actions are already there alongside the built-ins.

Three shapes a plugin can take

Shape A is overwhelmingly the right answer. An action that belongs inside an existing category is best discovered where agents are already working.

Shape B is for genuinely new domains. If your plugin's actions don't fit anywhere in the built-in category list, owning a new top-level category is cleaner than forcing a misfit injection.

Shape C is for capability that can't be expressed through orchestration of existing actions. The plugin ships C++ source that compiles into the user's project alongside the bridge, and registers handlers via UEMCP::RegisterExternalHandler from its StartupModule. Native handlers participate in the same dispatch path as built-in ones. See Native C++ modules.

What belongs in core and what belongs in a plugin

Core is a provider-neutral bridge to engine modules and to the Epic plugins that ship with the engine, reached through public or reflected APIs. Core holds no third-party credentials and calls no third-party service itself.

The exception is first-party infrastructure the server needs to run: the plugin registry client, feedback routing, the daemon extension host, and registry login (whose token the hosted plan also accepts).

Everything else is a plugin:

• Integrations with third-party Unreal plugins.
• Provider-specific behaviour layered on a neutral core surface. For example, p4_ actions injected into the source_control category, which itself works with any provider the editor supports.
• Opinionated workflows, test harnesses, demos and products built on the core surface.
• Anything where ue-mcp itself would call an external service or hold a credential.
• Anything that reaches undocumented interfaces or interfaces whose terms restrict that use.

Where to next