`sc assistant` — AI-powered onboarding
`sc assistant dev setup` scaffolds your service config (Dockerfile, docker-compose.yaml, client.yaml). `sc assistant devops setup` walks through provisioning the parent stack. Plus an MCP server so other tools can drive SC programmatically.
Why an assistant ships in the CLI
Most infra tools optimize for the engineer who already knows the tool. SC optimizes for the first 30 minutes — the time between “I want to deploy this” and “it’s on api.my-org.com with SSL and a database hooked up”.
sc assistant dev setup reads your project, asks two or three clarifying questions, and writes the config. The output isn’t magic — it’s the same client.yaml you’d write yourself, just produced faster and with fewer typos.
| |
Built-in MCP integration
sc assistant mcp --port 7331 starts a Model Context Protocol server. Any MCP-compatible client — Claude Code, Cursor’s agent, Continue, the Anthropic API directly — can connect and use SC primitives as tools:
search_docs— look up SC featuresgenerate_config— produce a client.yaml from a descriptiondeploy— wired tosc deploywith the right safety checkssecrets_reveal/secrets_add— gated behind explicit user approval
This is what makes Forge — our flagship multi-agent product — work: Forge’s agents talk to SC over MCP for the infra layer. The agent never has direct shell access; it goes through scoped, typed tool calls.
What it isn’t
- Not a local-dev runtime. SC isn’t trying to replace Docker Compose; it generates a
docker-compose.yamlfor local use and gets out of the way. - Not a chatbot for production debugging.
sc assistant chatis configuration-aware, not metrics-aware. For runtime debugging you still want Grafana / Sentry. - Not free. The assistant calls a Claude API key you provide. SC ships the orchestration; the LLM bill is yours.
Ship your infrastructure on autopilot.
Try the SC parent stack in your own repo, or see what we built on top of it — Forge, our flagship AI workflow engine for teams.