Set up WorkerKit in ChatGPT.

Before you start

What you need.

ChatGPT on the web, on a plan that has developer mode. OpenAI states it is "Available to Pro, Plus, Business, Enterprise, and Education accounts on the web", and adds that availability can depend on account and workspace policy. Neither Free nor Go is on that list. Reporting outside OpenAI's own pages disagrees about how much of developer mode Plus and Pro get, so take the toggle on your own account as the answer rather than any list, this one included.

On Business, Enterprise and Education, a workspace owner enables developer mode and custom MCP connectors first. It is an admin control there rather than a personal setting, and on Enterprise and Education it can be granted per person, so an employee may have to ask before the toggle appears at all.

A WorkerKit account, and admin access on it: choosing the key a connection will hold is an admin-only decision. The Free plan is enough, and no card is needed.

About a minute of the human's time. ChatGPT does everything except turning developer mode on and approving the connection.

Why this route: developer mode is the one ChatGPT surface that takes an arbitrary remote MCP server by URL, and OpenAI describes it as full MCP client support for all tools, both read and write. So the hosted WorkerKit MCP mounts go in directly, with nothing to install, nothing to publish and no code to write.

Why no key: OpenAI states that ChatGPT "does not support machine-to-machine OAuth grants such as client credentials, service accounts, or JWT bearer assertions, nor can it present custom API keys or customer-provided mTLS certificates", and the connect form has no header field. That is not a gap to work around. The fleet mount is an OAuth 2.1 authorization server, which is the scheme ChatGPT does support, so the credential is issued to the connection instead of being handled by a person.

One address is worth reading twice: workerkit.ai/mcp is the documentation page, and the live mounts are on mcp.workerkit.ai. The table above has both in full.

The case for connecting at all is on the ChatGPT page.

Step 0. Human, about 30 seconds

Turn on developer mode.

Developer mode is what lets ChatGPT add a remote MCP server by URL. It is a paid-plan, web-only setting, and on a workspace an owner enables it first.

• ChatGPT on the web Settings > Security and login > Developer mode

OpenAI documents that path on its connect page and lists the plans on its developer mode guide (https://developers.openai.com/api/docs/guides/developer-mode). Three things to expect. The connector list is named ChatGPT Plugins in the current vendor docs, which repackaged what were apps and, before that, connectors, and some surfaces still spell the entry point differently, so read the labels on the screen rather than assuming this page has the newest ones. OpenAI's own help centre still files developer mode as a beta and describes its write support as rolling out, so expect the screen to move again. And OpenAI marks developer mode elevated risk, because it lets anyone connect any server: on the strength of this guide, connect the two mounts below and nothing else.

On Business, Enterprise and Education the toggle appears only after a workspace owner has enabled developer mode and custom MCP connectors in the workspace settings, and those two plans can grant it per person. If the setting is not there, that is the reason, and the fix is a request rather than a retry.

Step 1. Human and agent, under a minute

Add the public catalog.

The catalog mount takes no credential at all, so it connects on the URL alone and proves the wiring before any account is involved.

• ChatGPT Plugins, the plus button, then Connection Name: WorkerKit directory Description: The public WorkerKit catalog of ready-made AI workers Connection: https://mcp.workerkit.ai/directory

The catalog mount takes no credential at all, on either path. It is the fastest proof that the client can reach WorkerKit, and it is worth adding first for exactly that reason: if it connects and the fleet mount does not, the problem is the credential rather than the wiring.

OpenAI lists three authentication modes for developer mode: OAuth, no authentication, and a mix of the two. This mount declares none of its own, so there is nothing to choose and nothing to type beyond the address.

ChatGPT lists the tools and metadata it discovered once the connection is created. Read that list: it is the fastest confirmation that the URL, the transport and the discovery all worked, and it is what the next steps operate through. The mount is read-only, so nothing here can change anything.

The connect page (https://developers.openai.com/plugins/deploy/connect-chatgpt) also offers a Secure MCP Tunnel for a server that is not reachable on the public internet. WorkerKit needs none of that: both mounts are public HTTPS over streamable HTTP, so the URL is the whole of the connection.

Step 2. Human, about 60 seconds

Connect your fleet.

Add the fleet mount by URL and approve on the WorkerKit consent page. Nothing is pasted into ChatGPT, and the reach is exactly the scopes on the key chosen there.

The fleet mount is an OAuth 2.1 authorization server as well as an MCP server: it publishes discovery, accepts dynamic client registration and runs authorization code with PKCE. That is the oauth2 scheme ChatGPT supports, and the mount announces it, so the connection is a URL, a sign-in and an approval.

1. 01

   Give the client the URL and nothing else

   The fleet mount publishes OAuth discovery, so a client that supports it finds the authorization server on its own and registers itself. There is no client ID to create, no secret to store and no redirect address to register in advance.

2. 02

   Approve on the WorkerKit consent page

   The client sends the person to https://workerkit.ai/mcpauth. Signing in there is what proves who is connecting; nothing is typed into the assistant.

3. 03

   An account admin picks the key the client will hold

   The consent page lists the account's manager keys and can create one on the spot, so a first connect needs no visit to Fleet access beforehand. It is admin-only on the server, not just in the page: a member sees an honest notice rather than a broken screen.

4. 04

   Scopes are chosen with the key, and are the whole of the reach

   Whatever that key carries is exactly what the assistant can do, and nothing on it reaches a connected app. Narrow it now or widen it later; a new key drops into the same connection.

• ChatGPT Plugins, the plus button, then Connection Name: WorkerKit fleet Description: Operate my WorkerKit AI workers Connection: https://mcp.workerkit.ai/workers Then approve at https://workerkit.ai/mcpauth

Nothing is pasted into the chat on this path, which is its real advantage: the credential never passes through a message, a log or a screenshot, and revoking it later is one action in the dashboard rather than an edit inside the assistant.

One honest hedge, because this page will not pretend otherwise: WorkerKit publishes the discovery, the registration endpoint and the consent page, and we verify those from our side, but we cannot run a connect inside your ChatGPT account. If the OAuth mode does not complete there, do not go looking for a key field. There is none, and there is no supported way to supply one. Operate the fleet from another MCP client, the wk CLI or the REST API, and leave the catalog mount connected in ChatGPT, where it needs no credential.

A client that cannot run an OAuth flow takes the same fleet on one header instead. An account admin creates a key at https://workerkit.ai/fleet-access, copies it once, and it becomes the value of an Authorization header on the fleet mount. That header is the whole of the authentication: there is nothing to register and nothing to pre-approve. ChatGPT is not one of those clients, which is the whole reason this step is an OAuth step. Keep the key out of ChatGPT: never in a message, never in the description field, and never in the URL. OpenAI documents a token in a query string as prohibited by the MCP authorization specification, so a key smuggled into the address is not a clever workaround, it is a credential in a log.

A key carries the scopes it was granted when it was created. Granting a scope later never reaches an existing key: if a call answers 403 OPERATION_NOT_ALLOWED, an admin re-scopes the key at Fleet access or creates a new one, and the new key drops into the same place. Read key_info rather than assuming.

Step 3. Agent

Verify the scopes.

Call key_info on the fleet mount. The scope list it returns is the truth, whatever was intended on the consent page.

• Ask the key what it can do (no arguments) key_info

It returns the account title, the key name, the scopes and expiry, and serverTimeUtc; any valid key may ask. Confirm the list matches what the admin picked. If a scope is missing it was either not granted, or granted after the key was created, and an admin re-scopes at Fleet access or creates a new key. Plan against what this call returns rather than what was intended.

It is also the call that tells a ChatGPT session what kind of assistant it is about to be. An observer key makes it a reporter on the fleet; a builder key lets it install a kit. Say which, in plain words, before offering to do anything.

Step 4. Agent

Keep the WorkerKit skill.

Use a standalone skill in the ChatGPT desktop app where supported, or include it in a plugin. On other surfaces, read the file with an available retrieval tool or attach it as reference.

• Skill folder, standalone or inside a plugin workerkit-fleet/SKILL.md For a plugin: skills/workerkit-fleet/SKILL.md Source: https://workerkit.ai/chatgpt/SKILL.md
• Without a skill installation Read https://workerkit.ai/chatgpt/SKILL.md before the first fleet call, using an available retrieval tool; if unavailable, use an attached copy.

The file starts with YAML name and description fields, then Markdown instructions. Keep the workerkit-fleet directory when installing it as a skill. Standalone skills are available in the ChatGPT desktop app; plugin skills can also reach ChatGPT on web and mobile. This is a skill file, not an installable plugin package.

For custom or project instructions, retain only the relevant workflow and operating rules without the YAML header; attach the full file as reference where supported. Do not paste the entire tool catalog into a short instruction field. Referencing a URL alone does not install a skill or give ChatGPT tools to retrieve it.

Step 5. Agent

Run the smoke test.

List the fleet and read recent runs, which alone prove the setup. If the account has workers, read one before running it, run it with approval, and report the receipt.

If the fleet is empty, stop after step 3 and say so: a new account has no workers yet, and the steps above have already proved the setup, because the key authenticated and both read scopes answered. Do not read it as a fault, and do not invent a worker to run. Go to the first-worker step and give the fleet something to do.

If the fleet has workers, pick one whose effects are reads. Judge it from the instruction and the permissions, never from the name: a worker whose apps are all read-level and whose instruction only gathers, summarises or reports is safe to run; one that sends, posts, writes, orders or pays is not, whatever it is called. If none is clearly read-only, run one with an explicit prompt for that run bounding it to a read.

• 1. The directory is alive: confirm a kit count comes back directory_overview
• 2. The fleet list: report how many workers the assistant can see workers_list
• 3. Recent runs across the fleet: confirms readRuns runs_feed { "limit": 5 }
• 4. Before running anything, read what that worker does and what it may touch. Both ride on readWorkers, and this is the step that decides whether the run is safe instruction_get worker_permissions_get
• 5. Run it with the person's approval, then poll every 3 to 5 seconds until a terminal event arrives: run.succeeded, run.failed, run.blocked or run.awaiting_input worker_run run_events { "afterSeq": <lastSeq> }
• 6. Read the receipt: costAuthority first, then modelCostUsd run_get

Read costAuthority first, then modelCostUsd beside it, and report both. A null finalDigest is not a failure: a run produces one only when its harness wrote a report. A costAuthority of unbilled_estimate, none or in_flight is not a failure either; it says how far to trust the number, and the operating rules below say what each value means.

A Skipped run is also a pass, and it is the cost brake working: the gate refused the run before any money moved. Report the skipReason rather than retrying. Then report the fleet size, the active scopes, and what the test cost, and the fleet is live.

Expect a confirmation prompt on the first write. Developer mode asks the person to confirm write actions by default, so worker_run pauses for a click. That is the surface doing what a fleet operator would want, not a fault to retry around.

Step 6. Human and agent

Give the fleet its first worker.

A new account starts empty. Install a kit from its page in one click, or let ChatGPT preview and install one with kit_install_preview and kit_install once the person approves.

A new WorkerKit account starts with no workers, so the last step of setup is getting one. A kit is a ready-made worker: its instruction, its exact app permissions and its schedule, written and reviewed in advance, so installing one is how a fleet usually starts rather than a shortcut. There are two paths, and either ends with something to operate.

1. 01

   The one-click path: install a kit from its page

   Browse the catalog at workerkit.ai/kits, open a kit whose job you recognise, and install it. It arrives pre-instructed, pre-permissioned and pre-scheduled, and asks for whatever it needs to connect. This path needs no scope on the manager key at all, so it works on the first session whatever the key can do.

2. 02

   The agent path: shortlist, preview, approve, install

   With installKits on the key, the assistant can do the whole thing in chat: shortlist with kits_search, read the candidate with kit_get, then call kit_install_preview to surface its setup questions and exactly what the new worker would be allowed to touch. Put that in front of the person in plain words, and call kit_install once they approve, with deploy set to true so the new worker is actually able to run (that half needs manageDeployments on the key; without it the worker is installed but inert until worker_deploy). The new worker's key is shown once in the response.

3. 03

   Then run it once and read the receipt

   A worker earns its place on the first run. Trigger it with worker_run, follow run_events until a terminal event arrives, and report the digest and the settled cost from run_get. Set a schedule with schedule_create when the person is happy with what it did, and the fleet is not just connected, it is working.

The catalog mount is anonymous, so this works before the fleet is connected at all. A reader whose plan or workspace blocks the fleet connection can still have ChatGPT read the whole catalog and explain what each ready-made worker would do, then install one in a click from its page.

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.

Read the request example and full contract.

Least privilege

What each scope grants.

The key's scopes are exactly its reach, and a refusal names the scope it wanted. Start with the reads and add scopes as the work asks for them.

Operating rules

What the agent follows on every call.

The same rules the skill file carries, so a session that read neither still has them. Every row is a fact of the platform, not advice.

Quick answers

Symptoms, causes, fixes.

Each WorkerKit failure names itself in the response, so an agent never has to guess which one it met: read the code, apply the row, and carry on.