WorkerKitWhat 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.
Published by WorkerKit. Updated .
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.
WorkerKit and Knowledge MCP
Connect to https://mcp.workerkit.ai/workers as WorkerKit for kit discovery and fleet operations. Add the separate Knowledge MCP to read published reports.
| Endpoint | What it is | Auth |
|---|---|---|
https://mcp.workerkit.ai/workers | WorkerKit: manage workers, runs, schedules, budgets and app access; discover, install and author kits. Full profile or smaller decision profile | Sign-in required |
https://mcp.workerkit.ai/knowledge | Company Knowledge: discover sources, search reports, read cited evidence and reconcile changes; admins can configure publication and reader grants | Same sign-in or key as WorkerKit |
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, worker_timezone_set | When a worker starts on its own, and the time zone it works in: its local dates, its report times and the clock its daily schedules follow |
| 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 |
| Action workers | action_worker_options, action_worker_create, worker_tools, worker_tool_call, worker_tool_invocation | Selected app tools with no model: create the worker, list its tools, call one with exact inputs (a write takes an idempotency key) and read a write's receipt. Never deployed or 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 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 workers endpoint also 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, 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. These discovery tools read the catalog. Installing a kit happens on the kit's page as a signed-in human, or through kit_install with its own scope; publishing one takes 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 createWorkers, 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 a smaller set of workflow tools on the same endpoint with the same authentication. Server operators can set MCP_WORKERS_PROFILE=decision instead. Full remains the default profile; publishing, Action workers and broader fleet administration use that profile. Reconnect and relist after changing profiles. Successful MCP responses include structured content and a text fallback.
Call an Action worker
An Action worker (modelType: "none") has no model: it exposes selected app tools that you call one at a time with exact inputs, under the worker's own app access. On the full profile, action_worker_options lists apps and tools, action_worker_create creates the worker, worker_tools lists its tools, and worker_tool_call calls one (the invokeActions scope, which also covers worker_tool_invocation for a write's receipt). A write takes an idempotency key; never resend a call whose status is outcome_unknown. It is never deployed or run. Call examples.
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.
Add the Knowledge MCP for published reports
The Knowledge MCP is a separate connection at https://mcp.workerkit.ai/knowledge, using the same sign-in or manager key. Name this connection WorkerKit Knowledge:
claude mcp add --transport http workerkit-knowledge https://mcp.workerkit.ai/knowledgeIt carries knowledge_sources, knowledge_search, knowledge_get and knowledge_changes; admins can also configure publication and reader grants.
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 |
invokeActions | Call an Action worker's tools and read the receipts of its writes |
manageMemory | Add, edit and retire a worker's rules and facts, grade runs, scrub a report |
manageSchedules | Create, edit and delete schedules, and set a worker's own time zone |
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 | Create an Action or decision worker from scratch, and 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 |
manageDeployments | Put a worker on the hosted runtime and manage that deployment; without it an installed worker never runs |
deleteWorkers | Delete a worker permanently, with its sub-workers |
readWallet | Read the wallet balance, fees and checkout status |
requestWalletTopUp | Create a checkout link a person confirms and pays |
discoverAppResources | Read private setup metadata such as GitHub repositories and Slack conversations, never their content |
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 America/Chicago" becomes a schedule without anyone translating it into fields.
Research what to build next. On the workers 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 holds no app credentials. Only workers reach apps, under their own app firewall, contact rules and redaction, and a run prompt cannot widen any of them. Run results (with
readRuns) and an Action worker's tool results (withinvokeActions) can include data from those apps. - It is not an anonymous way to install kits. Discovery tools only read. 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 MCP server for managing AI workers and discovering kits. Connect as WorkerKit at https://mcp.workerkit.ai/workers. The separate Knowledge MCP at https://mcp.workerkit.ai/knowledge searches and reads published worker reports with the same sign-in or key.
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?
Only through workers you set up. The key holds no app credentials, but run results (with readRuns) and an Action worker's tool results (with invokeActions) can include data from the apps that worker was granted. Choose the worker's app access and the key's scopes together.
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?
Yes. The WorkerKit connection at https://mcp.workerkit.ai/workers includes kit_validate, kit_publish and kit_install, so a client can author a kit, publish it privately and install it as a new worker with the required scopes.