What is the WorkerKit MCP server?
The WorkerKit MCP server at mcp.workerkit.ai is a remote endpoint that lets any MCP client manage and run an account's AI workers, and search the kit directory.
MCP is usually described from the worker's side: how a worker reaches your apps. This is the other direction. It is how an AI client reaches your workers, so the fleet becomes something a client can read, run and maintain rather than something you open a browser to.
It is a hosted, remote server. Nothing is installed and nothing runs on your machine.
The tools it serves are defined once, in the open-source @workerkit/core library, and the same definitions drive the WorkerKit CLI, so the fleet an agent orchestrates here and the one you script in a terminal can never disagree. The server's product page is /mcp, and the whole developer surface is summarised at /developers.
Two endpoints, one host
| Endpoint | What it is | Auth |
|---|---|---|
https://mcp.workerkit.ai/workers | Your fleet: 87 tools in the full profile, or 20 in the decision profile for reading, running and configuring workers, deploying them onto the hosted runtime, routing their reports, setting budgets, cloning them, installing kits as new ones, authoring kits of your own, connecting apps, and registering your own MCP servers | Sign-in required |
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 | None at all |
They are deliberately separate. The catalog is public, so walling it behind a sign-in would be wrong; the fleet is yours, so it is never anonymous. A client can connect to one, the other, or both.
What the fleet endpoint can do
| Group | Tools | What it covers |
|---|---|---|
| Key | key_info | What the presented 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, worker_delete | Every worker with live run state, one worker in full including readiness, connected apps and 30-day activity, start or stop, delete, and what a worker may touch, read-only |
| Deployment | worker_deploy, worker_undeploy, deployment_get, deployment_update, deployments_list | Put a worker onto the hosted runtime and take it off, read one deployment, and change its model, reasoning, transcript retention, ceilings and pause state |
| 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, grade, or scrub a report a worker keeps carrying forward. On a decision-model worker it decides instead: 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 | Every worker's runs in one account-wide feed, everything running right now, and one brief on what needs attention: blocked, never deployed, overdue, or waiting on an answer |
| 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, with its usage against every cap |
| Schedules | schedules_list, schedule_create, schedule_update, schedule_delete | When a worker starts on its own, in its own time zone |
| 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 |
| 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-model worker it reads the routing table and the install questions instead, and writes their answers |
| Budgets | budget_get, budget_set, fleet_budget_get, fleet_budget_set, account_usage | A worker's spend and run ceilings, the account-wide fleet ceiling, and what the account has left in slots, wallet and request windows |
| 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 |
| Kits | kit_install_preview, kit_install | Preview a directory kit's install form against your account, then install it as a new worker |
| 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 a client 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 | models_list, model_keys_list, model_key_set, model_key_delete | The models a worker can be given, and your own model-provider API keys, so runs bill your provider account instead of the wallet |
| 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 |
The public catalog endpoint carries workerkit_about (what WorkerKit is and when to use it, written for an agent and served one section at a time), directory_overview, kits_search, kit_get, kit_stats, publisher_get, and the three reads a kit is written from: kit_app_tools (every app and the tools a worker gets on it), kit_authoring_guide and kit_vocabulary. It is read-only by construction: installing a kit happens on the kit's page as a signed-in human, or through the fleet endpoint's kit_install, never anonymously, and publishing one takes the fleet endpoint's kit_publish.
Create a decision worker
Use the workers connection to discover kit_app_tools(purpose:"decision"), read kit_authoring_guide(section:"decision"), then call decision_worker_create. It creates a private kit and installed worker from typed questions; optional deployment never starts a run. Creation requires publishKits and installKits, plus manageDeployments when deploying.
The initial recipes classify email previews, calendar events or Google Sheets rows without app writes. Check connections with apps_list. Reuse the same requestId and body on retries, follow the returned nextCall, and operate the returned tokenId through the existing run and instruction tools. Inspect receipt coverage, omissions and cost. Request example and source limits.
For a smaller list, send X-WorkerKit-Profile: decision consistently on every workers request, including initialization and listing. This selects 20 workflow tools on the same endpoint with the same authentication. Server operators can set MCP_WORKERS_PROFILE=decision instead. Full remains the default with 87 tools; publishing and broader fleet administration use that profile. Reconnect and relist after changing profiles. Successful MCP responses include structured content and a text fallback.
The one tool worth understanding first
worker_run takes an optional prompt for this run. Omit it and the worker does its standing job. Supply it and the worker does its job *about that subject*, with its method, its permissions and its memory unchanged.
That is what turns a fleet into something a client can compose with: the same research worker can be pointed at fifty accounts in an afternoon, and every one of those runs is done the way the worker was built to do it. The pattern has its own page, AI worker fleet orchestration.
How to set it up
Use the OAuth flow if your client supports it. It is fewer steps, and no raw credential is ever pasted into a config file or a chat window.
- Add
https://mcp.workerkit.ai/workersto your client as a remote MCP server. In clients with a connector UI this is "add a custom connector" and the URL. In Claude Code it is one line:
claude mcp add --transport http workerkit https://mcp.workerkit.ai/workers- Connect. The client discovers the sign-in flow from the server and opens the WorkerKit consent page at
workerkit.ai/mcpauth.
- On that page, sign in with Google or Microsoft, then pick the access key the client should use, or create one there and then, and approve. The client's reach is exactly that key's scopes, and the page says so before you approve.
- Back in the client, ask it to list your workers. If it names them, you are connected.
Only an account admin can complete step 3, because access keys are an admin-only surface. A member who follows the flow sees a notice saying so rather than a broken page.
If your client does not do OAuth
Create a key yourself at /fleet-access and send it as a bearer header. The key is shown once, at creation, and never again:
claude mcp add --transport http workerkit https://mcp.workerkit.ai/workers \
--header "Authorization: Bearer pe_mgr_..."Both routes end at the same place. A key added by hand keeps working after you later switch to OAuth.
The public catalog needs no setup at all
claude mcp add --transport http workerkit-directory https://mcp.workerkit.ai/directoryNo key, no sign-in, no account. It is the public directory, reachable the way a crawler reaches it.
Choosing what the client may do
An access key carries scopes, and a client can never exceed them. A refusal names the scope it wanted, so nothing fails mysteriously.
| Scope | What it unlocks |
|---|---|
readWorkers | See the fleet: which workers exist, their state, their readiness |
readRuns | Read run history, receipts, live step feeds, and the reports workers wrote |
runWorkers | Trigger a run now, and cancel one |
manageMemory | Add, edit and retire a worker's rules and facts, grade runs, scrub a report |
manageSchedules | Create, edit and delete schedules |
manageInstructions | Rewrite a worker's standing instruction |
manageState | Start and stop workers |
installKits | Install a directory kit as a new worker (the worker's own key is shown once in the response) |
manageDeliveries | Create, edit and delete the destinations a run report is sent to |
manageBudgets | Read and change a worker's spend and run ceilings, and the fleet ceiling |
createWorkers | Clone a worker into new ones; a clone carries only permissions a person already approved |
publishKits | Author kits: validate, publish, edit, unlist and delete, and keep the publisher profile |
manageConnections | Connect and disconnect apps by credential, register your own MCP servers, and set or remove your model-provider keys |
A sound progression, and the one worth actually following:
- First key: `readWorkers` and `readRuns`. The client can describe the fleet and everything it has done, and change nothing. Most of the value of the first session is here.
- Then add `runWorkers`. Now it can do work. This is the step where the server turns into AI worker fleet orchestration rather than a read-only view.
- Add the manage scopes deliberately.
manageInstructionslets a client rewrite the tested method of a worker, which is the largest of these and the one to withhold longest. - `publishKits` and `manageConnections` are the building scopes. With them a client can write a kit from the public guide, validate it, publish it privately and install it as a new worker; connect the apps it needs by credential; and, when the platform does not offer an app, register that app's MCP server as your own custom MCP app. Every credential is checked live and stored encrypted, and no read ever returns one.
Keys are per account, revocable, optionally expiring, and an account holds up to ten active at once. Giving a client its own key rather than sharing one is what makes revoking it later a decision with no side effects.
Use cases
Ask the fleet a question in plain language. "Which workers have not produced a successful run this week, and why?" is one prompt against workers_list and worker_runs, instead of opening every worker's page.
Run something out of cadence. A worker built from the Executive daily briefing kit runs at 07:00, it is now 15:00, and something changed. Ask the client to run it with a prompt naming what changed.
Debug a run without leaving the editor. run_events replays a run's steps in order with timings and outcomes, so "why did that take nine minutes" is answerable where you already are.
Keep memory honest. A worker carrying a fact that stopped being true drifts quietly. A client can read the memory, spot the stale item and retire it, which keeps provenance rather than deleting history.
Set up a schedule by describing it. "Every weekday at 8am in Europe/London" becomes a schedule without anyone translating it into fields.
Research what to build next. On the public endpoint, the client searches the directory for a kit that already does the job, reads its permissions manifest and its instruction, and hands you the install link.
What it is not
- It is not access to your apps. A fleet key grants no data access at all. No tool on this server reads a mailbox, a calendar or a CRM. Only workers reach apps, under their own app firewall, contact rules and redaction, and a run prompt cannot widen any of them.
- It is not an anonymous way to install kits. The catalog endpoint only reads. Installing takes a signed-in human on the kit's page, or the fleet endpoint's
kit_installbehind its own opt-in scope. - It is not a place where your data sits. The server holds no state, no sessions and no secrets. It forwards a request, returns the answer, and forgets.
- It is not a second permission model. MCP connects; it does not restrain. Every limit that applies to a worker on a schedule applies identically to a worker a client just triggered.
Manners that keep a session healthy
Worth telling a client once, because these are the things that turn a working session into a throttled one:
| Situation | The right behaviour |
|---|---|
| Watching a run | Poll its events every 3 to 5 seconds, never in a tight loop |
| A run comes back "skipped" | That is a receipt with a reason on it, not an error. Report the reason |
| A refusal naming a scope | The key is too narrow. An admin issues a wider key; retrying will not help |
| A rate limit | Back off for the time the response asks for |
The budgets are generous and are counted per account, so other people using the same hosted server never affect you: 120 requests a minute across the surface, 30 run triggers a minute, and a separate allowance for watching runs that is sized for exactly the poll spacing above.
FAQ
What is the WorkerKit MCP server?
It is a hosted remote MCP server at mcp.workerkit.ai with two endpoints: one authenticated endpoint carrying 87 tools in the full profile, or 20 in the decision profile for managing, running and extending your AI workers, and one public endpoint carrying 9 read-only tools for learning what WorkerKit is and when to use it, searching the kits directory, and reading the guide a kit is written from.
How do I connect Claude to my WorkerKit workers?
Add https://mcp.workerkit.ai/workers to the client as a remote MCP server, then connect. The client sends you to workerkit.ai/mcpauth, where you sign in, choose or create an access key, and approve. An account admin has to complete that step. Clients without OAuth support can send a key created at /fleet-access as a bearer header instead.
Can an MCP client read my email or CRM through this?
No. The credential a client holds manages workers and grants no access to any connected app. Workers reach apps; the fleet endpoint does not, and no prompt can change that.
Do I need a paid plan to use the WorkerKit MCP server?
No. The connection itself is not a paid feature. What a client triggers is metered like any other run: tool calls count against your daily allowance, and model tokens are billed at provider list price with no markup.
What can a client actually change?
Exactly what the access key's scopes allow, and nothing more. A read-only key lets a client describe your fleet and its history without touching anything. Running, memory, schedules, instructions and start/stop are each a separate scope, so you decide how far the client's reach goes and can revoke it at any time.
Is there an MCP server for creating kits?
Not yet. A kit-creation endpoint is planned on the same host. Today the catalog endpoint reads the public directory and the fleet endpoint manages workers you already have.