Skip to main content

Plugin Catalog

The platform ships 28 built-in plugins. This page is the complete list — every ID, activation condition, injected tool, bundled skill, and prompt.

Understanding the activation model

Whether a plugin is live in a given turn is decided by three fields, evaluated in this order:
1

user_selectable

true = the plugin appears in the plugin panel and only activates when you tick it.false or absent = it never appears in the panel and activates automatically when its conditions are met.
2

requires

Runtime context keys that must be satisfied. For example {"desktop_connected": true} means desktop-only. When unmet, the plugin’s tools do not exist — the model can’t see or call them.
3

conditions

Environment conditions. Currently only {"sandbox_mode": "!none"} is used, meaning a sandbox is required.
There is also exclusive: true: when that plugin activates, no other plugin loads at all. Only profy-evolution and profy-movie use it.
“Not in the panel” does not mean “not there.” Only 14 of the 28 plugins are user_selectable: true; the other 14 are infrastructure that engages automatically. This is why “I didn’t enable any plugin, why is it writing files?” — sandbox tools were never a tickable plugin.

The full table

User-selectable (14)

These appear in the plugin panel and require an explicit tick.

Automatically available (14)

These never appear in the panel and engage on their own when conditions are met.

What a manifest looks like

Activation rules aren’t if-else branches scattered through the code — each plugin directory holds a plugin.json. Here’s the record-and-replay plugin (excerpted from the real file):
Each block does one job: contracts declares what the plugin brings (tools reference existing code via ref + export rather than reimplementing it), prompts declares what gets injected, and activation declares when it applies. Adding a tool usually means editing a manifest, not the main pipeline — which is also why this page stays in sync with the implementation: the manifest is the implementation.

Counts at a glance

Things worth calling out

The four office plugins have no tools

profy-docx / profy-pdf / profy-pptx / profy-xlsx declare an empty tools array. What they provide is method plus scripts — skill documents and pre-installed libraries in the sandbox. The expert runs them via bash rather than calling a “make me a Word file” tool. The tradeoff: capability ceiling equals whatever runs in the sandbox, instead of being boxed in by a tool signature. The cost is that output quality depends on how well the skill document is written.

The three software bridges have unwired MCP

blender-bridge / godot-bridge / photoshop-bridge declare mcpServers in their manifests, but neither agent-runtime nor Core currently consumes the mcpServers field of builtin plugins. What actually takes effect is the skill layer only (workflow discipline and prompts) — there are no callable software-control tools. See the “Known defect” section on each plugin’s page.

Several plugins bind browser

profy-game-studio, profy-visualize, and profy-sites all reference browser in their own tool lists. That is not redundant declaration but a necessary binding — each of those three has a core loop (playtest verification, render self-check, preview confirmation) that needs browser screenshots. Ticking any one of them activates the browser tool alongside it.

profy-movie is exclusive

exclusive: true means enabling Movie loads nothing else. Video production is a long pipeline; mixing in other tools distracts the model and squeezes context.

Where requires keys come from

These keys are supplied by the activation context assembled at invoke time:

Tools that belong to no plugin

One class of tools is not injected by a plugin at all — it is bound to the conversation mode: So: “I didn’t enable any plugin, why can the expert write files?” — sandbox tools were never a plugin. Full signatures are in the Tool Catalog.

Creators can disable built-in plugins

Creators can switch off specific built-in plugins in the Studio plugin tab. The disabled IDs are stored on the expert config, sent to the runtime at invoke time, and the matching manifests are skipped. This applies to every conversation with that expert, and it sits at a different level from the user’s panel tick: what the creator disabled cannot be re-enabled by ticking.

Troubleshooting: why isn’t this plugin working

Work through these in order; four steps is always enough:
1

Is it in the panel at all?

If not, check the table above: the 14 plugins with user_selectable: false are never listed. They apply automatically and need no ticking.
2

Is `requires` satisfied?

The five desktop plugins need a desktop connection, Chrome needs the extension online, and the Feishu plugin needs a Feishu-channel turn. When unsatisfied, the plugin’s tools simply do not exist — the model won’t say “I lack that tool”, it just never uses it.
3

Did the creator disable it?

Built-in plugins disabled in Studio never load, no matter what the user ticks. When the same request behaves differently across two Experts, this is usually why.
4

Was it crowded out by an exclusive plugin?

While Movie or Evolution is active, no other plugin loads.

Tool Catalog

Parameter signatures for every tool

Skill Catalog

Built-in skills and the three ownership tracks

Plugin overview

Conceptual introduction to the plugin system

Limits

Platform-wide limits and quotas
Verified 2026-08-11. Sources: services/agent-runtime/src/plugins/builtin/*/plugin.json (28 files), services/agent-runtime/src/plugins/registry.py, services/agent-runtime/src/base/tools/sandbox.py.