AI workers for Grok Bot.
Grok Bot is the operator you talk to. WorkerKit gives it a fleet of specialists: background AI workers with their own instruction, memory, schedule, budget and pre-scoped app access, hosted around the clock and reporting back in short, costed digests. Long jobs stay out of the chat, each worker gets its own narrow grant, and every run comes back with its settled cost. Setup takes about a minute of your time.
What Grok Bot is
A desktop assistant, and a good one.
Grok Bot is a personal desktop assistant in Cursor's Grok Bot app: it talks in chat, runs work on its own computer, reaches the machines you register with your approval, connects services through MCP, and saves routines that fire on a schedule or an event. It is built to stay with you in conversation, for research, ops, follow-ups, drafting and tool use, while you drive.
| What a fleet adds | Why it helps |
|---|---|
| Room in the chat | Machine output lands in a digest instead of the conversation, so the thinking stays in front of you. |
| A session per job | Each job gets its own context and its own model, chosen for that job rather than inherited from the chat. |
| A grant per job | App access is wired once, per worker, so Grok Bot orchestrates the work without carrying every integration itself. |
Grok Bot already handles recurring work through routines and long jobs in the background, and it stays the right place for anything you want to watch happen. A fleet beside it takes the standing jobs: the ones that should keep running when the chat is closed, hold their own app access, and report a paragraph instead of a screen.
Hired specialists
What a worker adds beside Grok Bot.
An AI worker is a background agent with its own instruction, memory, triggers, budget, model, app permissions and key. WorkerKit hosts the runs, so Grok Bot never has to keep a chat open for them.
| Aspect | Grok Bot | A WorkerKit worker |
|---|---|---|
| Context | One conversation, plus the routines you save | Its own, sealed per run; only the digest returns |
| Model | The model behind this chat | Chosen per worker from any supported provider, or your own provider key |
| Identity | The connectors and tools the bot holds | Its own key, with an explicit grant per app, read-only by default |
| When it runs | While you chat, or on a Grok Bot routine | Hosted around the clock: on demand, on a schedule in its own time zone, or on a signed inbound webhook |
| What comes back | The work itself, in the chat | A closing report of at most 8,000 characters, a typed digest beside it, and the settled cost |
| Memory | The bot's memory about you | The worker's own rules and facts, carried across runs, and approved by you before a run may use them |
| Taking it back | Remove a connector or pause a routine | Disable or revoke one worker; nothing else moves |
The operator pattern
Grok Bot operates. Workers work.
| Step | Who | What happens |
|---|---|---|
| 1 | You | Ask in plain language. "Which workers ran today?", "Run the invoice chase now", "Pause the scanner." |
| 2 | Grok Bot | Reads its key's scopes first with key_info, picks the matching MCP tool, and follows the operating rules in its WorkerKit skill. |
| 3 | The worker | Executes in its own context, on its own runtime, on its schedule or on demand. |
| 4 | Both | Grok Bot reads the result with runs_feed and run_get: one connection 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 delivery channels. |
Grok Bot becomes the fleet operator. The workers do the unattended work, Grok Bot does the thinking about it, and the interactive desktop jobs workers are not for stay exactly where they are.
Why Grok Bot and WorkerKit
Each one covers what the other is not for.
Use a Grok Bot routine for ping me in this chat. Use a WorkerKit worker for run unattended against my apps, with its own grant, and deliver to Slack.
| Grok Bot strength | What WorkerKit adds beside it |
|---|---|
| Custom MCP servers, added in chat | Two streamable-HTTP mounts, the public catalog and your fleet, live as soon as you add them |
| Conversational ops | Sealed specialists that hand back digests, so a long job costs a paragraph of chat rather than a screen of it |
| The desktop and the browser, when a job needs them | Hosted runs that keep going after the desktop session is closed |
| Routines on a schedule or an event | Hosted schedules in their own time zone, with per-run budgets, an app firewall and a receipt for every run |
| Ops workflows end to end | Ready-made kits and custom workers for monitoring, follow-ups, reporting and triage across the apps you connect |
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 Grok Bot chat stays clean.
- Sealed jobs, small returns Every job runs in its own context and only the digest returns to the chat. A large 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, through run_question and run_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 with kits_search and kit_get, install with kit_install, or author your own through kit_authoring_guide, kit_validate and kit_publish. Every path runs the same validators.
- Fleet operations Clone a tuned worker for the next client with worker_clone or worker_clone_bulk, set budgets, route deliveries, and start and stop workers, all from the chat.
- 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.
Grok Bot speaks MCP natively, so WorkerKit arrives as two custom servers added in chat. 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 Grok Bot can browse the catalog 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 |
|---|---|---|
| Decision authoring | kit_app_tools, kit_authoring_guide, decision_worker_create | Discover supported classification sources with purpose:"decision", read section:"decision", then create a private kit and worker from typed questions. Optional deployment never starts a run. Use the existing run and instruction tools afterward. |
| Key and fleet | key_info, workers_list, worker_get, worker_permissions_get, worker_set_enabled, fleet_health, account_usage | What this key may do, every worker on the account with its live run state (filterable), starting or stopping one, what is quietly wrong across the fleet in one call, and the account’s headroom before you spend a slot or a run. |
| Runs | worker_run, run_bulk, worker_runs, runs_feed, fleet_pulse, run_get, run_events, run_transcript, run_cancel, run_score | Run now, or one prompt across up to 20 workers; watch the whole fleet on one connection, follow a run event by event, and read the receipt with its settled cost and, when the deployment opted in, its stored process log. On a decision worker worker_run decides instead and acts on what it routes: sourceArgs and maxItems narrow and cap what is judged, and waitSeconds waits for the settled receipt and its per-item decisions. |
| Two-way runs | run_question, run_answer | Read what a waiting run asked, answer it, and let the linked follow-on run carry on. |
| Memory and instruction | memory_get, memory_add, memory_update, memory_delete, instruction_get, instruction_set, instruction_versions, instruction_restore | Teach a worker rules and facts that persist, and read, replace or roll back its method. Every instruction change keeps its history. On a decision worker instruction_get reads the routing table and its install questions, optionsFor lists one app pick's live options, and instruction_set takes answers. |
| Schedules and deliveries | schedules_list, schedule_create, schedule_update, schedule_delete, delivery_channels, delivery_list, delivery_create, delivery_update, delivery_delete, delivery_secret_rotate | When a worker runs, in its own time zone, and where its report lands when it finishes. |
| 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 | Per-worker and account-wide ceilings on spend and run count, the brakes that make unattended work safe to leave running. |
| Kits | kit_install_preview, kit_install, kit_validate, kit_publish, kit_update, kit_replace, my_kits_list, kit_scan_get | Install a catalog kit as a new worker — with deploy set, in the same call, which is what makes it run — and author, validate and publish kits of your own. |
| Apps, MCP and model keys | apps_list, app_connect, app_disconnect, mcp_servers_list, mcp_server_create, mcp_server_set_tools, model_keys_list, model_key_set | Connect apps by credential, register your account's own MCP servers as custom apps, and bring your own model-provider keys. |
| 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. |
| Clone | worker_clone_preview, worker_clone, worker_clone_bulk | Copy a tuned worker for the next client, singly or in bulk, with a dry run first. |
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.
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 Grok Bot 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. |
| Grok Bot'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. Grok Bot 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 servers, one key, a skill.
Add the directory mount with no headers, then the fleet mount with a manager key created at Fleet access and sent as one Authorization header. That header is the whole of the authentication, so there is nothing to register and nothing to pre-approve. The agent then installs the WorkerKit skill file that carries its operating rules.
The whole procedure, written for the agent doing it, is the setup guide. The human's part is two steps and about a minute.
The same fleet answers from anywhere else you work: any MCP client, the wk CLI in a terminal, and REST hosts such as Meta Muse, which reaches services over their APIs. The fleet outlives the choice of assistant.
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 Grok Bot is not a paid feature, and the plans are on the pricing page.
Questions
Grok Bot and WorkerKit, answered.
- What is Grok Bot? Grok Bot is a desktop AI assistant in Cursor's Grok Bot app: chat, a computer of its own, MCP connectors, and routines that fire on a schedule or an event. It is the conversational operator, and WorkerKit workers are the unattended specialists it operates.
- Does Grok Bot connect to WorkerKit over MCP? Yes, and that is the path this guide takes. Grok Bot adds custom MCP servers in chat, so it adds two: the public directory mount at https://mcp.workerkit.ai/directory, which needs no key, and the fleet mount at https://mcp.workerkit.ai/workers, which carries a manager key as a bearer header. Meta Muse, a personal agent that reaches services over their APIs instead, uses the plain-HTTPS WorkerKit API.
- Can Grok Bot read my email or CRM through WorkerKit? No. The manager key Grok Bot holds operates workers and grants no access to any connected app. Workers reach apps under their own per-app grants, firewall and rules; the fleet surface does not, and no prompt can change that.
- What does the Grok Bot agent need to set this up? A WorkerKit account with admin access, a manager key created at workerkit.ai/fleet-access, and the WorkerKit skill file at workerkit.ai/grok-bot/SKILL.md. The person's part is about a minute: create the key and hand it over once. The agent adds both MCP servers, verifies the scopes, installs the skill and runs a smoke test.
- How does Grok Bot get a worker's results? Two paths. Grok Bot reads them with runs_feed and run_get: one connection watches every worker on the account, and each run's receipt carries the closing report, a typed digest when the run produced one, and the settled cost. People receive them through the worker's delivery channels: email, Slack, Teams, Telegram, Discord, Notion, SMS and WhatsApp, or a signed webhook.
- I connected it and the fleet is empty. What now? That is the expected state of a new account, and the connection is already proved. Install a kit to get the first worker: open any kit at workerkit.ai/kits and install it in one click, which needs no scope on the key at all, or, with installKits on the key, let Grok Bot shortlist with kits_search, preview exactly what the new worker would be allowed to touch with kit_install_preview, and install it with kit_install once you approve. Then ask Grok Bot to run it and read you the receipt.
- When do I use a routine and when do I use a worker? Use a Grok Bot routine when the job is "remind me in this chat": it is local, conversational and already in reach. Use a WorkerKit worker when the job should run unattended against your apps, with its own grant, its own budget and a report delivered to Slack or email. They complement each other, and the same chat drives both.
- What does it cost? WorkerKit has a Free plan with no card required: 5 workers, 500 tool calls a day and the complete safety layer. Runs bill model tokens at the provider list price with no markup, from a prepaid wallet or your own provider key, inside the per-worker and fleet budgets you set. Connecting Grok Bot is not a paid feature.
Ready? The setup guide is written for the Grok Bot agent doing the work, and the MCP server page holds the surface behind it.