Publishing

This page explains how a finished plugin reaches users. The steps differ for remote plugins and bundled plugins. A plugin document is published by pushing its folder to GitHub; see Declarative plugins and the marketplace's submit flow.

Remote pluginsCopy Anchor Link

1. Deploy your MCP server over HTTPS (Quickstart).
2. Make sure your MCP server's name matches the registry id you will use.
3. List the plugin in the marketplace. You can add a manifest to your repository and submit it on this website (manifest reference, submitting). Or you can open a pull request that adds an entry to registry/registry.json in pku-harness-plugins. The review policy explains how entries are reviewed and how the verified badge is given.
4. Users install the plugin from Settings → Plugins → Marketplace, or add your URL by hand.

Updates go out as soon as you deploy. The app picks up the new tool list the next time it refreshes the plugin.

Keep tool names stable. Users' widgets and scheduled checks refer to tools by name, so renaming a tool breaks them.

Bundled pluginsCopy Anchor Link

1. Open an issue in pku-harness-plugins first. Say what the plugin does and why it has to be bundled.

2. Send a pull request with three parts: the folder plugins/<id>/, the entry in builtinPlugins in plugins/index.ts, and a registry entry with "kind": "builtin".

3. Continuous integration (CI) and the reviewers run these checks:

   Copy Text

   bun test
   bunx tsc --noEmit -p .
   bun scripts/validate-registry.ts

4. After the merge, the app moves its plugins/ submodule to the new commit. How the change then reaches phones depends on what it touches. A change to JavaScript only is delivered as a signed over-the-air (OTA) update, which the app downloads and applies on its next launch. A change that needs native code waits for the next app release, which is a new APK.

Nothing is published to npm. The app and other developers use the SDK and plugins straight from the GitHub repository.

Renaming or mergingCopy Anchor Link

Users may have stored plugin ids, tool ids or widget keys in their widgets, checks or settings. Never reuse such an id, and never rename one silently. Instead, use PluginDef.legacy to map the old plugin ids, tool ids and widget keys to the new ones (SDK → plugin).

Using PKU harness CloudCopy Anchor Link

PKU harness Cloud is our hosted service for features that need a server. If your plugin declares PluginDef.cloud, copy its cloud declaration into the registry entry. The declaration has the fields uses, e2e (whether stored data must be end-to-end encrypted), disclosure and, optionally, backend.

The marketplace shows this declaration before install. disclosure.zh must say in plain words what data leaves the device. See Cloud → plugin guide.