Capabilities

Capabilities describe what a Spinup Agent should have available when it runs. They are how you tell Spinup which tools, integrations, and runtime requirements belong to this agent.

Spinup keeps capability settings with the agent, then projects, materializes, or validates the supported parts in the environment when the agent runs.

The current runtime path supports declared capability settings, MCP configuration projection, skill materialization, package-backed CLI/tool/runtime installs allowed by RuntimePolicy, baseline CLI/runtime validation, and OpenClaw plugin materialization. Hermes plugin fulfillment and agent-authored skill promotion are still treated as limited or deferred runtime behavior unless Spinup records support-safe evidence for that specific capability.

What counts as a capability

The current capability kinds are:

• skills
• MCP servers
• tools
• plugins
• CLIs
• runtime requirements

Each capability you add is a declaration: this agent should have ffmpeg available, should have the Firecrawl MCP server configured, or should have the PostHog skill requested. The shape of the declaration is the same regardless of kind.

Declarations are accepted independently from runtime support. For example, a CLI or runtime requirement can be declared and then validated against the current environment baseline, but Spinup does not treat arbitrary package installation as complete unless runtime evidence says the capability was materialized or validated.

Declared settings versus runtime fulfillment

There are two sides to a capability:

• the declared setting, which you control
• the runtime fulfillment, which Spinup records as evidence after it tries to apply or validate the capability in the environment

You declare the settings. Spinup records the result. Runtime fulfillment is not user-authored, so you will not find a way to set a capability to materialized or validated through the API. Those values show up after Spinup attempts supported projection, materialization, or validation work.

If a capability needs secrets, you attach the existing secret binding IDs to the capability. Secret values themselves never flow through capability requests.

Current runtime fulfillment is intentionally bounded. Spinup can project MCP server configuration, resolve configured secret bindings into disposable runtime env, materialize skills through the supported skills path, install declared CLI/tool/runtime packages when RuntimePolicy allows declared installs, validate baseline CLIs and runtime requirements, and materialize supported OpenClaw plugin bindings. Curated package registry policy, Hermes plugin fulfillment, and agent-authored skill promotion require additional policy and proof before they are treated as supported runtime behavior.

Where to go next

• See Spinup Agents for the object capabilities belong to.
• See Environments for where capabilities get applied.
• Manage capability declarations from the terminal with Agent capabilities.
• See the Skills feature page for how skills are installed.
• See the MCP servers feature page for how external tool servers are wired up.
• List, add, update, or remove capability settings through the workspace API with Control plane agents.