Capabilities
What a Spinup Agent should have available when it runs: skills, MCP servers, tools, plugins, CLIs, and runtime requirements.
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 applies or validates them in the environment when the agent runs.
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, or this agent should have the Firecrawl MCP server wired up, or this agent should have the PostHog skill installed. The shape of the declaration is the same regardless of kind.
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 the work.
If a capability needs secrets, you attach the existing secret binding IDs to the capability. Secret values themselves never flow through capability requests.
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.