Build with MCP
Build a kit with your AI assistant.
Connect Claude, ChatGPT, Cursor or any MCP client to the WorkerKit MCP server and describe the job in plain words. The assistant reads the authoring guide, writes the kit, validates it, publishes it private and runs it once on your account. You approve the access and the public step; nobody writes JSON by hand.
Step 1. You
Connect your assistant to WorkerKit.
The fleet mount is the one that builds: it carries the guide and the vocabulary as well as the tools that validate and publish.
| Mount | What it is | Auth |
|---|---|---|
https://mcp.workerkit.ai/workers | Your fleet and authoring on one connection: 122 tools in the full profile (115 manager tools plus 7 public discovery reads), or 24 tools in the decision profile. Discover sources, create classifiers, run and configure workers; the full profile also includes activity and spend, quality settings, worker access and bindings, API apps, Action workers, fleet administration, publishing and connection management. | Sign-in required |
https://mcp.workerkit.ai/directory | The public kits catalog: 8 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 |
- Your fleet
claude mcp add --transport http workerkit https://mcp.workerkit.ai/workers - The public catalog
claude mcp add --transport http workerkit-directory https://mcp.workerkit.ai/directory
Clients with OAuth connect with no key at all: an account admin approves on a WorkerKit consent page and picks the scopes there. Consent starts read-only, so grant the scopes below for the build. Clients without OAuth send a key created under Fleet access as a bearer header, typed once into the client and never into the chat.
Step-by-step setup for your assistant: Claude, ChatGPT, or any MCP client.
Least privilege
The scopes a build uses.
The first two build and install. The rest let the assistant run what it built once, and read the result, before you decide anything goes public.
| Scope | What building a kit uses it for |
|---|---|
publishKits | Validate, publish, edit, replace, unlist and delete your kits, and set the publisher name. |
installKits | Preview the install form and install the private kit as a new worker. |
manageAppsAndWorkers | Optional: fill worker slots or change the installed worker's apps afterwards. |
manageDeployments | Deploy the new worker so it runs at all. Install with deploy set, or deploy after. |
runWorkers | Start the test run. |
readRuns | Read what the run returned. Without it the receipt comes back with its content withheld. |
readWorkers | Which apps are connected, your kits with their moderation state, and the scan reports. |
Step 2. You
Give it the kit-authoring skill.
The procedure and the rules, so the assistant follows them without being told each time.
- Claude Code, for yourself (use .claude/skills/ inside a repository to share it with the team)
mkdir -p ~/.claude/skills/workerkit-kit-authoring curl -fsSL https://workerkit.ai/build/SKILL.md -o ~/.claude/skills/workerkit-kit-authoring/SKILL.md
On claude.ai, upload a ZIP containing workerkit-kit-authoring/SKILL.md under Customize, then Skills. An assistant that keeps no skills can read https://workerkit.ai/build/SKILL.md at the start of any session that builds a kit: one request, always current.
Step 3. You
Describe the job in plain words.
What it reads, what it may change, when it runs, and what it must never do. One job per kit.
- A language kit
Build me a private WorkerKit kit that reads yesterday's task-board changes every morning at 8 and writes a standup digest. Read-only: it must never edit a task. - A decision kit
Make a private kit that labels my unread email that needs a reply today, and leaves everything else alone. - From a worker you already tuned
Publish my worker "Invoice Follow-Up" as a private kit. - When the test run looks right
The standup kit works. Keep it private and update it with the changes we discussed.
A good assistant interviews you before it writes anything: which apps, which of them it may write to, how often it runs, and what counts as a blocker that should stop a run. Answer in your own words; it turns them into the instructions and the exact permission keys.
Step 4. The assistant
What it does, tool by tool.
| Move | Tool | Scope |
|---|---|---|
| Learn the rules: index, then schema and rules | kit_authoring_guide | none |
| See what each app lets a worker do | kit_app_tools | none |
| Copy the exact permission keys | kit_vocabulary | none |
| Check which apps are connected | apps_list | readWorkers |
| Dry run, every gate at once | kit_validate | publishKits |
| Publish it private | kit_publish | publishKits |
| Read the install form | kit_install_preview | installKits |
| Install and deploy in one call | kit_install (deploy: true) | installKits, manageDeployments |
| Fill worker slots after install | worker_bindings_set | manageAppsAndWorkers |
| Test run and its receipt | worker_run, run_get | runWorkers, readRuns |
| Update it privately | kit_replace (visibility: private) | publishKits |
| Check the listing after | my_kits_list, kit_scan_get | readWorkers |
It validates until the dry run answers canPublish, publishes the kit private, then installs it and runs it once on your account, so you read a real receipt before anything is public.
A publish is not idempotent: every successful kit_publish creates another listing. After a timeout the assistant reads my_kits_list before it tries again, rather than publishing twice.
Step 5. You
Approve what matters.
- The access. Read the apps and operations it chose before it publishes. Every write operation should match a write the job really makes.
- The public step. Public publishing, promotion and relisting are temporarily paused. The assistant must explicitly send visibility private when publishing, replacing or validating a kit.
- The secrets. Never paste a key into the chat. An install returns the new worker's key, and any webhook signing secret, exactly once: keep them, and never put either in a kit.
After it ships
Edit, unlist and delete it from the same chat.
Ask for it in words: "tighten the standup kit to read-only", "unlist it", "show me its scan report". The tools are my_kits_list, kit_update, kit_replace, kit_scan_get, kit_unpublish, kit_relist, kit_make_private and kit_delete, and the full table across surfaces is on the build hub.
The same steps run over the API and from the terminal.