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, supported JavaScript/Python CLI and tool installs allowed by RuntimePolicy, bounded remote-script installers, 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 supported JavaScript/Python CLI and tool packages when RuntimePolicy allows them, download approved remote-script installers and run them as interpreter argv, materialize Spinup-owned runtime tools such as ffmpeg from pinned Worker Host artifacts, validate baseline CLIs and runtime requirements, and materialize supported OpenClaw plugin bindings. The default declared package install mode allows supported user-declared package and remote-script install plans. Use curated to restrict install-backed capabilities to the small documented installer set Spinup recognizes today, including Firecrawl CLI and the Loops installer, or none to block install-backed capabilities. ffmpeg is a runtime-owned capability: declare it with installPlan.strategy: "none" and Spinup deterministically exposes the verified runtime-tool artifact before executable validation instead of asking the guest to install it. Hermes plugin fulfillment and agent-authored skill promotion require additional policy and proof before they are treated as supported runtime behavior.

Command-line executable examples

Use installPlan.strategy: "none" when the executable is either already available in the runtime baseline or owned by Spinup's runtime-tool materialization path. Use this path for Spinup-owned runtime tools such as ffmpeg; the execution plane verifies the pinned artifact and exposes it on PATH before validation.

Use js_global_package for the Firecrawl CLI, for example package firecrawl-cli with executable firecrawl. Use python_tool for Python CLIs installed through uv tool install or pipx install.

Use remote_script for Loops-style installers. A Loops CLI capability should use url: "https://cli.loops.so", interpreter: "bash", executable: "loops", and a LOOPS_API_KEY secret binding. Spinup downloads the HTTPS script, optionally verifies checksumSha256, and runs bash <downloaded-script>; it never accepts pasted curl ... | bash commands or pipe-to-shell input as package text.

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.