LabscoMCP early access ↗
floomhqMCP SERVER

Floom

Create, run and supervise Floom's background AI workers — and edit the context they read — from an MCP client.

by floomhq ↗Reasoning Scaffolds & Agent Workflow EnginesCommunity

LABSCO SUMMARY

The worker is a folder, so an agent can write one.

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.

What it is

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.

What you get

  • 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

Requirements

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.

Setup effort

One command plus a key — npx -y @floomhq/floom mcp install --target claude, then supply credentials

See installation options