AI workers for ChatGPT.
ChatGPT reaches outside itself through plugins, and in developer mode it takes a remote MCP server of your own, by URL. Put a WorkerKit fleet on the other end of that URL: background AI workers, each with its own instruction, memory, schedule, budget and pre-scoped app access, hosted around the clock and answering in short, costed digests. Both mounts go in as connections, the catalog with no credential and the fleet through an approval on a WorkerKit page. No key is pasted into ChatGPT, because ChatGPT cannot take one and does not need one.
What ChatGPT is
Several surfaces, one door.
ChatGPT is OpenAI's assistant, on the web, on desktop and on mobile, across Free, Go, Plus, Pro, Business, Enterprise and Edu accounts. It extends itself through plugins, the current packaging of what were apps and, before that, connectors, and that layer is built on the Model Context Protocol: a plugin is an MCP server, optional UI, and the skills that teach ChatGPT how to use it. Developer mode is the setting that lets one person point ChatGPT at a remote MCP server of their own, by URL.
| What a fleet adds | Why it helps |
|---|---|
| One connection, many jobs | The fleet is a single connection rather than a connector per service. Each worker holds its own app grants underneath it, so the list in ChatGPT does not grow with the work. |
| Work that survives the tab | A conversation ends when you close it. A hosted worker keeps its schedule, runs at 6am, and has the answer waiting. |
| Effects you approve, with a receipt | Developer mode asks you to confirm write actions by default. WorkerKit puts a scope layer under that: the key reaches the fleet only, and every run settles its exact cost. |
| A fleet that is not tied to this surface | The same workers answer any other MCP client, a terminal and a plain HTTPS API, so a plan change or a renamed menu does not strand the work. |
It is worth being precise about which surface, because ChatGPT has several and only one of them takes an arbitrary server. Deep research and company knowledge connectors accept a server that exposes exactly two read-only tools, search and fetch, which no general tool surface matches. Custom GPTs and their OpenAPI Actions were the old way in and are being retired: OpenAI has said new creation closes around 25 September 2026 and custom GPTs stop running on 11 December 2026, with plugins as the migration path. Developer mode is the door this page documents, and it is the one that is open.
Hired specialists
What a worker adds beside ChatGPT.
An AI worker is a background agent with its own instruction, memory, triggers, budget, model, app permissions and key. WorkerKit hosts the runs, so ChatGPT never has to hold a conversation open for them.
| Aspect | ChatGPT | A WorkerKit worker |
|---|---|---|
| Context | One conversation, plus what the account carries between them | Its own, sealed per run; only the digest returns |
| Model | The OpenAI model behind this conversation | Chosen per worker from any supported provider, or your own provider key |
| Identity | The plugins and connections on your account, acting as you | Its own key, with an explicit grant per app, read-only by default |
| When it runs | While you are there, in a browser tab | Hosted around the clock: on demand, on a schedule in its own time zone, or on a signed inbound webhook |
| What comes back | The work itself, in the thread | A closing report of at most 8,000 characters, a typed digest beside it, and the settled cost |
| Memory | What the assistant remembers of your earlier conversations | The worker's own rules and facts, carried across runs, and approved by you before a run may use them |
| Taking it back | Remove the connection, or turn developer mode off | Disable or revoke one worker; nothing else moves |
The operator pattern
ChatGPT operates. Workers work.
| Step | Who | What happens |
|---|---|---|
| 1 | You | Ask in plain language. "Which workers ran today?", "Run the invoice chase now", "Pause the scanner." |
| 2 | ChatGPT | Reads its key's scopes first with key_info, picks the matching tool on the fleet connection, and follows the operating rules in the WorkerKit skill. |
| 3 | You again, for anything that writes | Developer mode asks you to confirm a write action by default, so starting, pausing or rewriting a worker is a decision you take rather than one you read about afterwards. |
| 4 | The worker | Executes in its own context, on its own runtime, on its schedule or on demand. |
| 5 | Both | ChatGPT reads the result with runs_feed and run_get: one connection covers the whole fleet, and the run's receipt carries the digest, the typed structure when the run produced one, and the settled cost. People receive it through the worker's delivery channels. |
ChatGPT becomes the fleet operator: it reads the fleet, says what it is about to change, and waits for the confirmation developer mode puts in front of you. The workers do the unattended work, and the interactive work workers are not for stays exactly where it is.
Why ChatGPT and WorkerKit
Each one covers what the other is not for.
Use ChatGPT for the work you want to watch and steer. Use a WorkerKit worker for run unattended against my apps, on a schedule, with its own grant, and deliver to Slack.
| ChatGPT strength | What WorkerKit adds beside it |
|---|---|
| Developer mode: full MCP client support, read and write | Two streamable-HTTP mounts that go in by URL, the public catalog anonymously and the fleet through the OAuth mode |
| Plugins that bring a service into the conversation as you work | Standing grants for the services that must stay reachable when nobody is watching, held per worker rather than per conversation |
| Write actions confirmed before they run | A scoped key underneath that confirmation: it reaches the fleet only, and never a mailbox, a calendar or a CRM |
| The same assistant on the web, on desktop and on mobile | A fleet anyone on the account can operate from the surface they already use, with the same receipts whoever asked |
| Skills that teach a repeatable workflow, in SKILL.md | A skill file of our own, so the fleet arrives with its tool reference and operating rules already written |
What it unlocks
Background work that stays out of the chat.
Each run executes sealed inside its own context, settles its exact cost and returns a digest. The worker remembers its own state. Your conversation stays clean.
- Sealed jobs, small returns Every job runs in its own context and only the digest comes back. A long crawl becomes the few paragraphs that matter, so many workers fit in one conversation.
- The right model per job Inexpensive models scan, frontier models judge. Every run is priced to the token, with reserved-versus-settled tracking, so background work is never a black box on your bill.
- Money you can trust A run that never started costs nothing. A run that went silent mid-flight is absorbed by WorkerKit and labelled as an unbilled estimate. A failed run settles at actual usage with no minimum charge.
- Standing monitors and briefings Workers watch on a schedule and report only what is new, so you stop relying on remembering to ask.
- Two-way work A run that needs input does not guess or stall. It asks on every delivery channel and resumes as a linked follow-on run when you answer.
- Memory that compounds Rules and facts persist across runs, so the tenth run is smarter than the first. Anything a run proposes for memory waits for your approval before a future run may use it.
- Kits: install one or make your own Browse the catalog, install a ready-made worker, or author your own through the authoring guide, the validator and the publisher. Every path runs the same validators.
- Fleet operations Clone a tuned worker for the next client, set budgets, route deliveries, and start and stop workers, all from the assistant you already talk to.
- Delivery where people live Results land in email, Slack, Teams, Telegram, Discord, Notion, or SMS and WhatsApp, where their readers already are, instead of waiting in a chat nobody opens.
- Auditable trails Every run leaves a typed event stream, liveness heartbeats, owner and self scores, and the allow or redact outcome of each tool call underneath it.
What the two mounts expose
A public catalog, and your fleet.
WorkerKit publishes two mounts over streamable HTTP. The catalog is public, so it is never walled behind a sign-in; the fleet is yours, so it is never anonymous.
| Mount | Address | What it carries |
|---|---|---|
| Directory | 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. No key at all, so the catalog can be browsed before anyone signs in. |
| Workers | https://mcp.workerkit.ai/workers | Your fleet and authoring on one connection: 91 tools in the full profile (84 manager tools plus 7 public discovery reads), or 20 tools in the decision profile. Discover sources, create classifiers, run and configure workers; the full profile also includes fleet administration, publishing and connection management. A manager key on the header, and the key's scopes are exactly its reach. |
| Area | Tools | What it covers |
|---|---|---|
| Key | key_info | What your 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 | Every worker with live run state, one worker in full, start or stop, and what a worker may touch, read-only, in the same vocabulary a kit is written in. |
| 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 or grade it. On a decision worker it decides instead and acts on what it routes: 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, account_usage | Every worker’s runs in one feed, everything running right now, what is quietly wrong across the fleet, and the account’s headroom before you spend a slot or a run. One call each, instead of asking each worker in turn. |
| 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. |
| 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, 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 worker it reads the routing table and the install questions instead, and writes their answers. |
| 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. |
| Deployment | models_list, deployments_list, deployment_get, worker_deploy, deployment_update, worker_undeploy | What makes an installed worker actually run: pick its model from the priced catalog, cap its spend, pause or resume it, take it off again. A worker with no deployment fires no schedule and refuses a run with not_deployed. |
| Budgets | budget_get, budget_set, fleet_budget_get, fleet_budget_set | A worker’s spend and run ceilings, and the account-wide fleet ceiling. Their own scope, because raising a dollar cap is the one management action that can cost money. |
| 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. |
| Deletion | worker_delete | Remove a worker for good, with its sub-workers. Permanent, where stopping one is not — which is why it is a scope of its own. |
| Kits | kit_install_preview, kit_install | Preview a directory kit against your account, then install it as a new worker — with deploy set, in the same call, which is what makes it 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 an agent 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 | model_keys_list, model_key_set, model_key_delete | Your own model-provider API keys, so runs bill your provider account instead of the wallet. |
| Onboarding and wallet | onboarding_get, wallet_get, wallet_checkout_create, wallet_checkout_get | Check model funding, hand off BYOK setup, inspect wallet balance, and request a human-confirmed Stripe checkout. A purchase is complete only when its status is credited. |
| 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. |
| Decision authoring | decision_worker_create | Compile typed questions and a supported source recipe into a private kit and installed decision worker. Optional deploy; never starts a run. Requires publishKits and installKits, plus manageDeployments when deploying. Retry the same requestId and body to recover the receipt. |
| Discovery and authoring reads | workerkit_about, directory_overview, kits_search, kit_get, kit_app_tools, kit_authoring_guide, kit_vocabulary | Public reads also available on the workers connection. Discover classification sources with kit_app_tools(purpose:"decision") and read kit_authoring_guide(section:"decision"). These reads never forward the manager bearer upstream. |
The manager key reaches the fleet only. It grants no access to any connected app: workers reach apps under their own grants and firewall, and no prompt can widen that.
The same two mounts answer every other MCP client, and the same fleet answers the REST API for hosts that speak plain HTTPS instead.
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.
Access and control
Scoped per worker, and scoped for ChatGPT too.
| Layer | What it holds |
|---|---|
| Per-worker grant | You connect each account yourself and choose what the worker may do there: per-app operations, read-only by default, narrowed by rules such as contact blocks, label and folder rules, customer-domain limits, time windows and IP allowlists. An account-level ceiling caps what any worker can be granted. |
| The app firewall | Every tool call is checked against the grant and the rules, field-masked, scanned for sensitive data, redacted, rate-limited and logged with its outcome. The worker's model never sees what the rules removed. |
| Prompt injection | A worker steered by content it reads still cannot exceed its grant. Proposed memory waits for a human. Publishing a kit to the directory runs a supply-chain and prompt-safety scan that fails closed. |
| The assistant's own access | A manager key carries explicit scopes, is shown once and stored hashed. It reaches the fleet only: no scope on it reads a mailbox, a calendar or a CRM. An agent reads its scopes before planning, and an admin can revoke the key at any time without touching a worker. |
A worker is only as trustworthy as the access behind it, so the access is yours to give, to narrow and to take back, one worker at a time. You delegate without handing over the kingdom.
How it connects
Two servers, developer mode, no key.
Developer mode is the setting that lets ChatGPT add a remote MCP server by URL. OpenAI lists it as available to Pro, Plus, Business, Enterprise and Education accounts on the web, and on the three workspace plans an owner enables it first, so it is worth checking that before anything else.
The catalog mount asks for no credential at all, which is one of the modes OpenAI lists for developer mode. The fleet mount runs OAuth: it is an OAuth 2.1 authorization server as well as an MCP server, so ChatGPT registers itself and sends you to a WorkerKit consent page, where an account admin picks or creates the manager key that connection will hold. Nothing is typed into the chat, which matters more here than elsewhere: ChatGPT cannot present a user-supplied API key or Authorization header to an MCP server at all, so a key in a message would be a leaked credential and nothing more.
The whole procedure, written for the agent doing it, is the setup guide. The human's part is three steps and about a minute.
One thing this page will not claim: we publish 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, there is no key field to fall back on, so fall back to a different client instead.
The same fleet answers from anywhere else you work: any other MCP client, the wk CLI in a terminal, and the REST API for hosts that speak plain HTTPS. For a developer there is a fourth door, and it is OpenAI's own: the Responses API accepts a remote MCP server as a tool, with an authorization value alongside the server URL, which is where a manager key does belong. That is code you write, not the ChatGPT app.
Cost: WorkerKit has a Free plan with no card required. Runs bill model tokens at the provider list price with no markup, from a prepaid wallet or your own provider key, inside the budgets you set. Connecting ChatGPT is not a paid feature, and the plans are on the pricing page.
Questions
ChatGPT and WorkerKit, answered.
- Can ChatGPT connect to WorkerKit over MCP? Yes, through developer mode, which OpenAI describes as full MCP client support for all tools, both read and write. It is the one ChatGPT surface that takes an arbitrary remote MCP server by URL. OpenAI lists it as available to Pro, Plus, Business, Enterprise and Education accounts on the web, and notes that availability can depend on account and workspace policy. Neither Free nor Go is on that list.
- Which ChatGPT surface do I set this up on? ChatGPT on the web. Settings, then Security and login, then Developer mode; the connections themselves are added from the plugin list, with the plus button and a Connection. On Business, Enterprise and Education a workspace owner enables developer mode and custom MCP connectors first, and can grant it per person. The desktop app matters for one thing only: it is where a skill can be installed locally.
- Do I paste a WorkerKit key into ChatGPT? No, and you could not if you wanted to. OpenAI states that ChatGPT cannot present custom API keys or customer-provided mTLS certificates, and allows only two tool security schemes: no authentication, and OAuth. There is no header field in the connect form. The catalog mount needs no credential, and the fleet mount is an OAuth 2.1 authorization server, so you approve on a WorkerKit page and the connection holds the key. Never put a key in the URL either: OpenAI documents a token in a query string as prohibited by the MCP authorization specification.
- Can ChatGPT read my email or CRM through WorkerKit? No. The connection holds a manager key, and a manager key operates workers: no scope on it opens a mailbox, a calendar or a CRM. Each worker holds its own grant for the apps it needs, under the app firewall and the rules you set on it, and nothing said to ChatGPT in a conversation widens either one.
- What does ChatGPT need to set this up? A ChatGPT plan with developer mode, on the web, and a WorkerKit account with admin access, because picking the key a connection holds is an admin decision. The person's part is about a minute: turn developer mode on, and approve the fleet connection when ChatGPT sends them to it. ChatGPT adds both servers, verifies the scopes with key_info, keeps the WorkerKit skill and runs a smoke test.
- What about custom GPTs and GPT Actions? Do not build on them. OpenAI has said new custom GPT creation closes around 25 September 2026 and custom GPTs stop running on 11 December 2026, with plugins named as the migration path. An Action over the WorkerKit REST API would also hold one builder-supplied key for everyone who used the GPT, which is the wrong shape for a fleet. Developer mode is the door, and it is the one this guide documents.
- How does ChatGPT get a worker's results? Two paths, and neither needs the tab open. ChatGPT pulls them over the fleet connection with runs_feed and run_get, so one connection covers every worker on the account and each receipt carries the closing report, the typed digest when the run produced one, and the settled cost. The people who need the result get it from the worker itself, through its delivery channels: Slack, Teams, email, Telegram, Discord, Notion, SMS and WhatsApp, or a signed webhook.
- I connected it and the fleet is empty. What now? That is the expected state of a new account, and the connection is already proved. Two ways to fill it. Open any kit at workerkit.ai/kits and install it in one click, which asks no scope of the key at all; or, with installKits on the key, have ChatGPT shortlist with kits_search, show you exactly what the new worker would be allowed to touch with kit_install_preview, and call kit_install once you say yes. The catalog mount is anonymous, so ChatGPT can read and explain the whole catalog even before the fleet connection exists.
- What does it cost? WorkerKit has a Free plan and asks for no card: 5 workers, 500 tool calls a day, and the whole safety layer. Model tokens are billed at the provider list price with no markup, drawn from a prepaid wallet or from your own provider key, and capped by the per-worker and fleet budgets you set. Connecting ChatGPT costs nothing on our side; developer mode is the part that needs a paid ChatGPT plan, and that gate is OpenAI's rather than ours.
The setup guide is written for the agent doing the work, the MCP server page holds the surface behind it, and the wk CLI reaches the same fleet from a terminal.