Plugins

Plugins (/admin/plugins) is the catalog of capabilities this server can offer clients. A row describes one plugin: what it is, whether it is switched on, and the JSON configuration that drives it.

A catalog row on its own reaches nobody. A user gets a plugin when a group they belong to has it in its Plugin Allowlist — set on the group’s edit page under Groups.

Kinds

Kind	Badge	What it is
rest_api	REST API	A plugin backed by an HTTP API
mcp_server	MCP Server	A packaged MCP server, uploaded as a .cab

A fresh database starts with an empty catalog. Knowledge bases add rows here as you create them on Knowledge Bases; everything else you add yourself.

The desktop client’s own built-in tools — memory, todos, reminders, files, and the rest — are not in this catalog and never were yours to switch on or off from here. They live in the client, and each user turns them on or off in the client’s own plugin settings.

Mesh pods and operators are not in this catalog view

Connectors and operators are stored as plugin rows of their own kinds, but they are deliberately kept out of the group plugin picker and are granted on their own pages instead.

Adding or editing one

1. Press Create Plugin, or Edit on an existing row.

2. Set Name, Kind, Description and Version.

3. Optionally upload an Icon — PNG or SVG, up to 256 KB.

4. Fill in ConfigJson. This is where a systemPromptAddition lives, alongside whatever the kind needs — an MCP server wants a transport, plus the command and args to launch it or the url to reach it.

5. For an MCP Server, attach the Plugin Package (.cab, up to 50 MB). Its size and SHA-256 hash are recorded with the row, and a client verifies the signature against the trust anchors on Certificates.

6. Leave Active checked and save.

ConfigJson is checked for being well-formed JSON — a blank field normalises to {}, a malformed one is refused with ConfigJson is not valid JSON, and what you typed is stored byte for byte. It is not validated against a schema: a well-formed object with a wrong handlerId saves cleanly and fails at runtime instead. On PostgreSQL the column is jsonb, which is why the well-formedness check is not optional.

Deactivate takes a plugin out of circulation while keeping the row and every group’s allowlist entry intact — the usual way to retire something. Delete is permanent and only offered on rows that are not preloaded.

What clients do with the catalog

Clients pull the catalog they are entitled to and store per-plugin preferences of their own (enabled or not, per user). Those preferences push back on the sync channel.

Because the client’s built-ins have no row here, the preferences it pushes include ids this server has never heard of. That is expected and harmless: an unknown id is skipped rather than rejected, so it can never wedge the rest of a client’s push. If a preference for a plugin you did add here seems not to stick, check that the row is active and that the user’s group has it in its allowlist.

For the client-side view of the same feature, see the Plugins guide.