That is what makes this agent-shaped rather than a workflow builder with an API bolted on: a worker is a YAML file and a script, which an assistant can generate, diff and revise. Two safety properties are worth knowing before you let it: script workers run in an isolated microVM with platform secrets withheld, while plain-English agents run in the API process and are explicitly not isolated — so the two worker types carry different risk. Side effects can be held behind an approval, and every run is replayable, which is what makes an unattended schedule reasonable.
Floom turns a folder into a background worker: a worker.yml plus either a Python script or a plain-English SKILL.md. The MCP server is how an agent builds and operates those workers — creating them, running them, watching runs and editing the shared context they draw on, all scoped to one workspace.
- Workers — workers.list, workers.get, workers.create from worker.yml plus Python source, workers.update for trigger type, cron expression and timezone, saved default inputs and capability overrides, and workers.run
- Runs — runs.list, runs.get and runs.watch, so an agent can start work and follow it rather than firing and forgetting
- The company brain — contexts.list, contexts.read and contexts.write over the file packs workers read at run time, which is how you change what a worker knows without editing the worker
- connections.list for the app and MCP connections the workspace can reach, and secrets.list and secrets.set for secret names
- ask_workspace_agent, a single tool that hands a whole instruction to Floom's own workspace agent when you would rather describe the outcome than pick the calls
- Fifteen hosted tools across six categories — the lean surface an agent is given; the broader engine and admin registry is not served by default
- Secrets and tokens are redacted from tool results automatically
- Triggers a worker can carry: manual, cron, webhook, or an app event
- Script workers run inside E2B sandbox microVMs with the host filesystem, environment and process isolated and platform secrets withheld; plain-English agents run in the API process and are not microVM-isolated by policy
- Side-effecting workers can require human approval, and every run records logs, outputs, tool calls, approval state, replay and rollback
A Floom workspace. For Floom Cloud, npx @floomhq/floom mcp install writes the client config — endpoint, workspace and token — for Claude Code, Cursor, VS Code, Windsurf or Continue; authenticate with a workspace API token rather than a session JWT, since the token does not expire and suits static config. Self-hosting instead means Python 3.11 or later, Node.js 20 or later, a model provider key and an E2B key for the sandboxes, and the OSS server runs over stdio. Floom charges no per-task fee; you pay for E2B sandbox runtime and your own model and API usage. MIT licensed.
One command plus a key — npx -y @floomhq/floom mcp install --target claude, then supply credentials