Capabilities

Capabilities are reusable bundles of agents, Python tools, skills, and MCP servers published into an organization registry.

Capability bundles can also carry runtime metadata such as dependency-install instructions and health checks, even though the main catalog view is centered on the user-facing agent, tool, skill, and MCP components.

In the App IA, this page lives under Hub.

This page is about the shared platform catalog. If you want to author a capability on disk, start with Custom Capabilities. If you want to install a capability into the active runtime, start with TUI Capabilities.

What the page is for

The platform capability page is the place to:

• browse capabilities from your organization and the public catalog
• search and filter by keyword, author, and license
• inspect a capability before installing it
• publish, unpublish, or delete versions you own

The detail drawer groups components by type so you can review the packaged agents, tools, skills, and MCP servers before using them.

Workflow

Capabilities usually move through three distinct stages:

1. author locally as a capability directory
2. publish the version to the Hub catalog
3. install that published version into one runtime when you actually want to use it

That third step is the one people miss. A capability can exist in the registry for days without being active in your current runtime.

How capabilities map across surfaces

Surface	What you use it for
App	browse the shared catalog and inspect one published version
TUI	install, remove, or update capabilities for the active runtime
CLI	validate, push, sync, install, pull, publish, and delete versions
SDK	load a local capability directory or publish one programmatically

Ownership and visibility

State	Meaning
org-scoped	visible inside the owning organization only
public	visible in the public catalog and installable across organizations
canonical name	displayed as <owner>/<name> when the owning org matters
pinned reference	use org/name@version when you need a reproducible install or automation target

Publishing a capability to the registry does not install it into every runtime automatically. Installation is still a runtime or project decision.

What agents should assume

• Use org/name@version when precision matters. Bare names are convenient for humans, but pinned refs are safer for reproducible workflows.
• Treat registry ownership and runtime installation as separate steps. A capability can exist in the catalog without being installed into the current runtime.
• Expect public catalog entries to appear alongside org-local entries when the app is showing the combined view.
• Use the owning org for publish, unpublish, or delete operations.

Common workflows

dreadnode capability get acme/[email protected]
dreadnode capability install acme/[email protected]
dreadnode capability push ./capabilities/web-recon --public

Use Packages and Registry when you need the CLI surface for validation, publish, install, visibility updates, or deletion.