AI workers for OpenClaw.
OpenClaw runs on your own hardware and answers in the chat app you already use. WorkerKit gives it a fleet of specialists it does not have to host: background AI workers with their own instruction, memory, schedule, budget and pre-scoped app access, running around the clock whether or not your Gateway is up, and reporting back in short, costed digests. The connect is one remote MCP server and one Authorization header, with nothing to register anywhere. Your part takes about a minute.
What OpenClaw is
The assistant that runs on your own hardware.
OpenClaw is an open-source assistant, MIT licensed, published by the OpenClaw Foundation, an independent 501(c)(3) nonprofit; the project was created by Peter Steinberger, who no longer leads it. It runs as a Gateway process on a machine you control and meets you where you already talk: Discord, iMessage, Slack, Teams, Telegram and WhatsApp among others, beside native apps for macOS, iOS, Android, Windows and Linux, a browser Control UI, a CLI and a TUI. State, memory and credentials stay on your hardware, and you bring your own model API key.
If you know this project as Clawdbot or Moltbot, it is the same one. It was renamed through Warelay, Clawd, CLAWDIS, Clawdbot and Moltbot to OpenClaw on 30 January 2026, and the older names point at the same Gateway, the same config file and the same MCP support described here.
| What a fleet adds | Why it helps |
|---|---|
| Work that survives a closed laptop | The Gateway holds its MCP connections only while it is running. A hosted worker keeps its schedule whether your machine is awake, asleep, travelling or being rebuilt. |
| Credentials that are not in your config | Each worker connects its own apps on the WorkerKit side, under its own grant. Nothing new joins the secrets already on your disk. |
| Room in the channel you actually read | A Telegram thread or a Discord channel is a poor place for a screen of machine output. Work runs sealed and comes back as a digest. |
| A model chosen per job, not per install | OpenClaw runs on the model key you gave it. A worker picks its own model for its own job, priced to the token from a prepaid wallet or your own provider key. |
Running it yourself is the point of it, and that is where it should stay. What self-hosting cannot give you is a job that keeps its schedule while the machine is asleep, holds app credentials somewhere other than your own config, and answers to a budget rather than to whoever is at the keyboard. That is the shape of a fleet, and it sits beside OpenClaw rather than inside it.
Hired specialists
What a worker adds beside OpenClaw.
An AI worker is a background agent with its own instruction, memory, triggers, budget, model, app permissions and key. WorkerKit hosts the runs, so your Gateway never has to be the thing that stays up for them.
| Aspect | OpenClaw | A WorkerKit worker |
|---|---|---|
| Where it runs | Your Gateway, on hardware you own, for as long as you keep it running | WorkerKit's hosted runtime, around the clock, with no machine of yours involved |
| Context | The session, plus the skills and memory kept on your disk | Its own, sealed per run; only the digest returns |
| Model | The provider key you configured, for everything it does | Chosen per worker from any supported provider, or your own provider key |
| Identity | Your accounts, your credentials, held locally | Its own key, with an explicit grant per app, read-only by default |
| When it runs | While the Gateway is up and something asks it | On demand, on a schedule in its own time zone, or on a signed inbound webhook |
| What comes back | The reply, in the channel you asked from | A closing report of at most 8,000 characters, a typed digest beside it, and the settled cost |
| Taking it back | Remove the server from mcp.servers, or stop the Gateway | Disable or revoke one worker; nothing else moves |
The operator pattern
OpenClaw operates. Workers work.
| Step | Who | What happens |
|---|---|---|
| 1 | You | Ask from wherever you talk to it, a Telegram thread, the TUI, the Control UI. "What ran overnight?", "Run the invoice chase", "Pause the scanner." |
| 2 | OpenClaw | Reads its key's scopes first with key_info, picks the matching tool from the fleet mount, and follows the operating rules in its WorkerKit skill. Tool policy and the session approval posture still apply, exactly as they do to a native tool. |
| 3 | The worker | Executes on the hosted runtime, in its own context, on its schedule or on demand, with the Gateway free to be off the whole time. |
| 4 | Both | OpenClaw reads the result with runs_feed and run_get: one server covers the whole fleet, and the run's receipt carries the digest, the typed structure when the run produced one, and the settled cost. People receive it through the worker's own delivery channels. |
Nothing about the local setup changes. OpenClaw keeps its channels, its skills and its own credentials, and gains a fleet it can list, run, schedule and read reports from, in whichever chat app you happened to open.
Why OpenClaw and WorkerKit
Each one covers what the other is not for.
Use OpenClaw for the assistant you own outright and talk to all day. Use a WorkerKit worker for run unattended against my apps, on a schedule, with its own grant, and deliver to Slack whether or not anything of mine is switched on.
| OpenClaw strength | What WorkerKit adds beside it |
|---|---|
| Local-first: state, memory and credentials on your own hardware | Hosted runs for the jobs that must continue when the Gateway is not running, with their app grants held on our side rather than added to your config |
| Open source and MIT licensed, with no subscription and no hosted tier | A Free plan with no card, and runs billed at the provider list price with no markup, so neither half of the setup is a black box on your bill |
| Meets you in Discord, iMessage, Slack, Teams, Telegram and WhatsApp | Workers deliver into the same kinds of channel on their own schedule, so a briefing arrives without anyone opening a chat to ask for it |
| Static bearer headers on remote MCP servers, documented and first class | Two streamable-HTTP mounts that take exactly that: one header for the fleet, and none at all for the public catalog |
| Skills that follow the AgentSkills spec, installable from a git reference | A skill file of our own, so the fleet arrives with its tool reference and operating rules already written |
| Tool policy, approval postures and per-server tool filters | Scopes on the manager key, so the ceiling is set on our side too. Narrow either end, and the two narrowings compose rather than fight |
What it unlocks
Background work that stays out of the chat.
Each run executes sealed inside its own context, settles its exact cost and returns a digest. The worker remembers its own state. Your conversation stays clean.
- Sealed jobs, small returns Every job runs in its own context and only the digest comes back. A long crawl becomes the few paragraphs that matter, so many workers fit in one conversation.
- The right model per job Inexpensive models scan, frontier models judge. Every run is priced to the token, with reserved-versus-settled tracking, so background work is never a black box on your bill.
- Money you can trust A run that never started costs nothing. A run that went silent mid-flight is absorbed by WorkerKit and labelled as an unbilled estimate. A failed run settles at actual usage with no minimum charge.
- Standing monitors and briefings Workers watch on a schedule and report only what is new, so you stop relying on remembering to ask.
- Two-way work A run that needs input does not guess or stall. It asks on every delivery channel and resumes as a linked follow-on run when you answer.
- Memory that compounds Rules and facts persist across runs, so the tenth run is smarter than the first. Anything a run proposes for memory waits for your approval before a future run may use it.
- Kits: install one or make your own Browse the catalog, install a ready-made worker, or author your own through the authoring guide, the validator and the publisher. Every path runs the same validators.
- Fleet operations Clone a tuned worker for the next client, set budgets, route deliveries, and start and stop workers, all from the assistant you already talk to.
- Delivery where people live Results land in email, Slack, Teams, Telegram, Discord, Notion, or SMS and WhatsApp, where their readers already are, instead of waiting in a chat nobody opens.
- Auditable trails Every run leaves a typed event stream, liveness heartbeats, owner and self scores, and the allow or redact outcome of each tool call underneath it.
What the two mounts expose
A public catalog, and your fleet.
WorkerKit publishes two mounts over streamable HTTP. The catalog is public, so it is never walled behind a sign-in; the fleet is yours, so it is never anonymous.
| Mount | Address | What it carries |
|---|---|---|
| Directory | https://mcp.workerkit.ai/directory | The public kits catalog: 9 read-only tools, including what WorkerKit is and when to use it, written for an agent, plus the guide, the vocabulary and the app-by-app tool explorer a kit is written from. No key at all, so the catalog can be browsed before anyone signs in. |
| Workers | https://mcp.workerkit.ai/workers | Your fleet and authoring on one connection: 91 tools in the full profile (84 manager tools plus 7 public discovery reads), or 20 tools in the decision profile. Discover sources, create classifiers, run and configure workers; the full profile also includes fleet administration, publishing and connection management. A manager key on the header, and the key's scopes are exactly its reach. |
| Area | Tools | What it covers |
|---|---|---|
| Key | key_info | What your key is and exactly which scopes the other tools will honour. Call it first. |
| Fleet | workers_list, worker_get, worker_set_enabled, worker_permissions_get | Every worker with live run state, one worker in full, start or stop, and what a worker may touch, read-only, in the same vocabulary a kit is written in. |
| Runs | worker_run, run_bulk, worker_runs, run_get, run_events, run_transcript, run_cancel, run_score, run_clear_digest | Trigger a run with a prompt for that run, or one prompt across up to 20 workers; watch it step by step, read the receipt and the stored process log, cancel or grade it. On a decision worker it decides instead and acts on what it routes: sourceArgs and maxItems narrow and cap what is judged, and waitSeconds waits for the settled receipt, which carries the per-item decisions. |
| Fleet activity | runs_feed, fleet_pulse, fleet_health, account_usage | Every worker’s runs in one feed, everything running right now, what is quietly wrong across the fleet, and the account’s headroom before you spend a slot or a run. One call each, instead of asking each worker in turn. |
| Two-way runs | run_question, run_answer | A run that needs an answer ends by asking; the answer starts a linked follow-on run. |
| Memory | memory_get, memory_add, memory_update, memory_delete | The rules and facts a worker carries into every run. |
| Schedules | schedules_list, schedule_create, schedule_update, schedule_delete | When a worker starts on its own, in its own time zone. |
| Instruction | instruction_get, instruction_set, instruction_versions, instruction_version_get, instruction_restore | The standing instruction, versioned on every change, with the history to compare against and roll back to. On a decision worker it reads the routing table and the install questions instead, and writes their answers. |
| Deliveries | delivery_list, delivery_channels, delivery_create, delivery_update, delivery_secret_rotate, delivery_delete | Where a run report goes when the worker finishes: email, Slack, Teams, Telegram, Notion, Discord, SMS or a signed webhook. |
| Deployment | models_list, deployments_list, deployment_get, worker_deploy, deployment_update, worker_undeploy | What makes an installed worker actually run: pick its model from the priced catalog, cap its spend, pause or resume it, take it off again. A worker with no deployment fires no schedule and refuses a run with not_deployed. |
| Budgets | budget_get, budget_set, fleet_budget_get, fleet_budget_set | A worker’s spend and run ceilings, and the account-wide fleet ceiling. Their own scope, because raising a dollar cap is the one management action that can cost money. |
| Creation | worker_clone_preview, worker_clone, worker_clone_bulk | Clone a worker into new ones, singly or in bulk, with a dry run first. A clone carries only permissions a person already approved on the source. |
| Deletion | worker_delete | Remove a worker for good, with its sub-workers. Permanent, where stopping one is not — which is why it is a scope of its own. |
| Kits | kit_install_preview, kit_install | Preview a directory kit against your account, then install it as a new worker — with deploy set, in the same call, which is what makes it run. |
| Kit authoring | kit_validate, kit_publish, kit_update, kit_replace, kit_unpublish, kit_relist, kit_make_private, kit_delete, kit_scan_get, my_kits_list, publisher_get_mine, publisher_set | Validate a kit in one dry run that reports every gate at once, publish it from content or from a worker you own, keep it private or list it, and keep your publisher profile. A private kit installed with kit_install is how an agent builds a worker from scratch. |
| Connected apps | apps_list, app_connect, app_disconnect | Which apps an operator can use right now, in the kit vocabulary, and connecting the rest by credential: validated live, stored encrypted, never returned. Browser sign-ins stay on the Apps page. |
| Model keys | model_keys_list, model_key_set, model_key_delete | Your own model-provider API keys, so runs bill your provider account instead of the wallet. |
| Onboarding and wallet | onboarding_get, wallet_get, wallet_checkout_create, wallet_checkout_get | Check model funding, hand off BYOK setup, inspect wallet balance, and request a human-confirmed Stripe checkout. A purchase is complete only when its status is credited. |
| Custom MCP servers | mcp_servers_list, mcp_server_get, mcp_server_create, mcp_server_discover, mcp_server_set_tools, mcp_server_delete | An app the platform does not offer, reached through its MCP server: register it as your own custom MCP app with its credential in the same call, enable the tools a job needs, and bind it in a kit. |
| Decision authoring | decision_worker_create | Compile typed questions and a supported source recipe into a private kit and installed decision worker. Optional deploy; never starts a run. Requires publishKits and installKits, plus manageDeployments when deploying. Retry the same requestId and body to recover the receipt. |
| Discovery and authoring reads | workerkit_about, directory_overview, kits_search, kit_get, kit_app_tools, kit_authoring_guide, kit_vocabulary | Public reads also available on the workers connection. Discover classification sources with kit_app_tools(purpose:"decision") and read kit_authoring_guide(section:"decision"). These reads never forward the manager bearer upstream. |
The manager key reaches the fleet only. It grants no access to any connected app: workers reach apps under their own grants and firewall, and no prompt can widen that.
The same two mounts answer every other MCP client, and the same fleet answers the REST API for hosts that speak plain HTTPS instead.
Classification on demand
Create a decision worker from your questions.
Categorize, score or triage connected data, then reuse and adjust the worker.
Reuse an existing worker or decision kit when its questions fit. For a custom classification task, creation compiles a supported source recipe and typed questions into a private kit and an installed decision worker. Optional deploy:true adds deployment; creation never starts a run or adds a schedule. The kit can be edited and published later through the normal kit lifecycle.
On the workers connection, call kit_app_tools(purpose:"decision") for recipes, argument schemas, permissions and examples, then kit_authoring_guide(section:"decision"). Check account connections with apps_list; public discovery does not check them. Send the request to decision_worker_create, follow nextCall, then use worker_run and run_get. Running needs runWorkers; results need readRuns. Use instruction_get / instruction_set for saved category or level answers, or answers on one run. Structural question/source changes need a revised kit and a replacement install. Check receipt status, coverage, omissions, warnings and cost before claiming completion.
Start with email-previews, calendar-events or sheets-rows. These recipes return judgments without app writes. Email previews do not include full threads; calendar events are invitation data, not transcripts; Sheets needs a Google file ID, a finite tab-qualified range and a columns map. A connected app alone does not make every tool a supported source. Source filters select evidence, not permissions: the Sheets recipe grants spreadsheet reads across the linked Drive account.
Supply 1–8 questions: choice with named options, score with ordered levels, or noul for the probability of a statement. Choice adds unclear automatically. Set an explicit confidenceFloor between 0 and 1; it routes uncertainty and does not promise accuracy. maxItems is 1–50, default 20. Creation requires publishKits and installKits; optional deployment also needs manageDeployments.
Use a fresh requestId for each new worker. Retry with the same ID and identical body to recover the original receipt; a changed body returns 409. The response includes tokenId for MCP/CLI worker commands, stable workerId, kitSlug, readiness and nextCall. A deploymentError means the worker already exists: fix deployment on that worker. The receipt is a snapshot; check current worker readiness before running. No worker API secret is returned.
The workers connection includes discovery and authoring, so classification needs one MCP connection. Its full profile has 91 tools (84 manager tools and 7 public discovery reads); only decision_worker_create is new. For a smaller list, a client that supports custom headers can send X-WorkerKit-Profile: decision on every request, including initialization, listing and calls, to select 20 workflow tools. A server operator can instead set MCP_WORKERS_PROFILE=decision. The endpoint and existing sign-in stay the same; a profile grants no additional permissions. Reconnect and relist after changing profiles. Use the advertised tool list: fleet administration, publishing and event-stream tools require the full profile. Successful responses include structured content and a text fallback; creation declares an output schema.
Access and control
Scoped per worker, and scoped for OpenClaw too.
| Layer | What it holds |
|---|---|
| Per-worker grant | You connect each account yourself and choose what the worker may do there: per-app operations, read-only by default, narrowed by rules such as contact blocks, label and folder rules, customer-domain limits, time windows and IP allowlists. An account-level ceiling caps what any worker can be granted. |
| The app firewall | Every tool call is checked against the grant and the rules, field-masked, scanned for sensitive data, redacted, rate-limited and logged with its outcome. The worker's model never sees what the rules removed. |
| Prompt injection | A worker steered by content it reads still cannot exceed its grant. Proposed memory waits for a human. Publishing a kit to the directory runs a supply-chain and prompt-safety scan that fails closed. |
| The assistant's own access | A manager key carries explicit scopes, is shown once and stored hashed. It reaches the fleet only: no scope on it reads a mailbox, a calendar or a CRM. An agent reads its scopes before planning, and an admin can revoke the key at any time without touching a worker. |
A worker is only as trustworthy as the access behind it, so the access is yours to give, to narrow and to take back, one worker at a time. You delegate without handing over the kingdom.
How it connects
Two mounts, one header.
Both mounts are ordinary remote MCP servers to OpenClaw: an entry under mcp.servers in ~/.openclaw/openclaw.json with a url and transport set to streamable-http. The catalog needs nothing else. The fleet mount adds one pair to the optional headers map, an Authorization value carrying a WorkerKit manager key, and that is the whole of the authentication. The Gateway watches the file and applies changes automatically.
The same entry can be written with openclaw mcp add, in the Control UI under Settings then MCP, or from a chat session through the plus button and Connectors. OpenClaw also documents an OAuth mode for remote servers, and our fleet mount is a full OAuth 2.1 authorization server, so that path is open too; the two are mutually exclusive per server, because a server set to OAuth ignores static headers.
The whole procedure, written for the agent doing it, is the setup guide. The human's part is creating one key and pasting it once.
The same fleet answers from anywhere else you work: any other MCP client, the wk CLI in a terminal, and the REST API for hosts that speak plain HTTPS. The fleet outlives the choice of assistant, which matters more than usual for software you host yourself.
OpenClaw runs on your own hardware and carries terminal tools, so it can run wk directly as well as speak MCP. The commands are generated from the same tool definitions the MCP server serves, so neither surface is a subset of the other: what an agent can do over MCP, a shell can do. The wk CLI is the reference, and the setup guide carries the step.
Cost: WorkerKit has a Free plan with no card required. Runs bill model tokens at the provider list price with no markup, from a prepaid wallet or your own provider key, inside the budgets you set. Connecting OpenClaw is not a paid feature, and the plans are on the pricing page.
Focused OpenClaw skills
Three classifiers, ready to set up and reuse.
Choose a skill for email, calendar or Google Sheets. Each guides account setup, source consent, kit installation and the first bounded run.
These skills use published kits and the existing worker lifecycle. The person completes signup, source consent and any funding; OpenClaw checks access, installs the worker, fills setup answers and reads the results. A connected app and sufficient runtime capacity are required.
jev-email SKILL.md uses the Email Jev Classifier. Sender, subject and the opening body preview, not full message bodies or fetched threads. Mailbox labels stay unchanged. Do not infer customer or colleague relationships from an address alone.
jev-calendar SKILL.md uses the Calendar Jev Classifier. Event title, invitation description, location, times, status, organizer and attendees. These are invitation details, not transcripts or proof of what occurred. Events stay unchanged.
jev-sheets SKILL.md uses the Sheets Jev Classifier. Only explicitly mapped row fields. Returns categories and file/tab/row references without writing cells. Microsoft Excel files are not a source for this kit.
Save each file as skills/jev-email/SKILL.md, skills/jev-calendar/SKILL.md or skills/jev-sheets/SKILL.md inside the active OpenClaw workspace. Keep them as sibling folders beside the general fleet skill. Run openclaw skills list, then invoke /skill jev-email, /skill jev-calendar or /skill jev-sheets. Each file is self-contained; the general fleet skill remains available for broader work.
All three return judgments without changing source data. The Sheets kit’s spreadsheet read permission is broader than the selected file/range; review the live manifest before installation.
OpenClaw’s skill authoring guide explains local skill installation and discovery. Use a fresh session if a newly saved skill has not appeared.
Questions
OpenClaw and WorkerKit, answered.
- Which OpenClaw surface should I set this up on? The Gateway, whichever way you reach it. The Gateway is the process that holds MCP connections, so a server added once is available to every front end: the native apps, the Control UI, the CLI, the TUI and every chat channel. There are four documented ways to add one. The config file at ~/.openclaw/openclaw.json under mcp.servers is the canonical form, and the Gateway watches it and applies changes automatically. The CLI is openclaw mcp add. The Control UI is Settings, then MCP, at /settings/mcp. And in a chat session it is the plus button, then Connectors, then Add MCP server, with scope This session or Everywhere.
- Do I have to paste a key into OpenClaw? Once, and it stays on your own machine. The manager key becomes the value of an Authorization header on the fleet mount, written into ~/.openclaw/openclaw.json or set through the CLI. The public catalog mount takes no credential at all. OpenClaw also documents an OAuth mode for remote MCP servers, and the WorkerKit fleet mount is itself an OAuth 2.1 authorization server, so that route is available; note that a server configured for OAuth ignores static Authorization headers, so it is one or the other per server. The header is what our setup guide walks, because both halves of it are documented end to end.
- Can OpenClaw read my email or CRM through WorkerKit? No, and the two credential sets never meet. The header you add under mcp.servers carries a manager key, which operates workers and reaches no connected app at all; the accounts OpenClaw already holds on your disk stay where they are and are not read, copied or referenced by anything on our side. Workers reach apps under their own per-app grants on the WorkerKit side, behind the firewall and the rules, and no prompt in any channel can widen that.
- Does my machine have to stay on for the workers to run? No, and that is most of the reason to connect the two. OpenClaw runs where you put it, so nothing it does happens while the Gateway is down. WorkerKit workers are hosted: they keep their schedules, fire on their triggers and deliver their reports whether your Gateway is up, asleep or halfway through an upgrade. When you next open a chat, OpenClaw reads the whole backlog with runs_feed and tells you what happened while you were away.
- Is there a minimum OpenClaw version for this? Yes: 2026.5.12 or later. Advisory GHSA-rjxq-qqhf-8hwh (CVE-2026-53840), rated CVSS 7.1, described operator-configured custom MCP headers being forwarded on a cross-origin redirect, which is precisely the shape of a bearer header on a remote server. OSV records it fixed in 2026.5.12. Run the upgrade before you set the header rather than working out which build you are on, and rotate the manager key at workerkit.ai/fleet-access if you already ran one on an older build. Separately, OpenClaw needs Node 24.16 or later, or Node 26.1 or later; Node 22, 23 and 25 are unsupported.
- What does OpenClaw need to set this up? A running Gateway, a WorkerKit account with admin access, a manager key created at workerkit.ai/fleet-access, and the WorkerKit skill file at workerkit.ai/openclaw/SKILL.md. Your part is creating the key and handing it over once, about a minute. OpenClaw writes both servers into its own config, proves them with openclaw mcp doctor and key_info, keeps the skill and runs a smoke test.
- How do a worker's results come back? Two paths, and only one of them involves your Gateway. Ask OpenClaw and it reads runs_feed and run_get across the whole fleet on one server, so a single question covers everything that ran while you were away; each receipt carries the closing report, a typed digest when the run produced one, and the settled cost. Separately, each worker's own delivery channels push results out on their own: email, Slack, Teams, Telegram, Discord, Notion, SMS and WhatsApp, or a signed webhook. Those go direct from the hosted runtime, so they land whether the Gateway is up or not.
- I connected it and the fleet is empty. What now? Nothing is wrong: a new account has no workers yet, and an empty list is itself the proof, because the header authenticated and the read scopes answered. Fill it with a kit, which is a ready-made worker. Either open one at workerkit.ai/kits and install it in the browser, which asks nothing of the key, or, with installKits on it, have OpenClaw do the whole thing in the channel you are already in: kits_search to shortlist, kit_install_preview to show you exactly what the new worker would be allowed to touch, kit_install when you say yes. Then have it run the worker once and read you the receipt.
- What does it cost? OpenClaw is MIT licensed with no subscription and no hosted tier, so its half costs whatever your own model key costs and nothing more. WorkerKit adds a Free plan with no card required: 5 workers, 500 tool calls a day and the complete safety layer. Worker runs are the only other line, and they work the way your local setup already does: model tokens at the provider list price with no markup, drawn from a prepaid wallet or from a provider key of yours, under the per-worker and fleet ceilings you set. Connecting the two is not a paid feature.
The setup guide is written for the agent doing the work, the MCP server page holds the surface behind it, and the wk CLI reaches the same fleet from a terminal.