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.
Two endpoints, one host
| Endpoint | What it is | Auth |
|---|---|---|
https://mcp.workerkit.ai/workers | Your fleet: 22 tools for reading, running and configuring workers, and for installing kits as new ones | Sign-in required |
https://mcp.workerkit.ai/directory | The public kits catalog: 5 read-only tools | 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 |
|---|---|---|
| Fleet | workers_list, worker_get, worker_set_enabled | Every worker with live run state, one worker in full including readiness and 30-day activity, and start or stop |
| Runs | worker_run, worker_runs, run_get, run_events, run_cancel, run_score, run_clear_digest | Trigger a run with a prompt for that run, watch it step by step, read the receipt, cancel, grade, or scrub a report a worker keeps carrying forward |
| 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 |
| Instruction | instruction_get, instruction_set | The standing instruction, versioned on every change |
| Kits | kit_install_preview, kit_install | Preview a directory kit's install form against your account, then install it as a new worker. The one place a client can create a worker |
The public catalog endpoint carries directory_overview, kits_search, kit_get, kit_stats and publisher_get. 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.
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 mint 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
Mint a key yourself at /fleet-access and send it as a bearer header. The key is shown once, at mint time, 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) |
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.
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 re-mints it; 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 22 tools for managing and running your AI workers, and one public endpoint carrying 5 read-only tools for searching the kits directory.
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 mint an access key, and approve. An account admin has to complete that step. Clients without OAuth support can send a key minted 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.