WorkerKitFor Gemini Enterprise
AI workers for Gemini Enterprise.
Gemini Enterprise brings an organization’s tools into a managed assistant and agent workflows. WorkerKit adds portable workers with their own instructions, app access, schedules and budgets. Use an administrator-managed custom MCP connector to bring those jobs into your organization’s workflows.
Start with your administrator
Add WorkerKit with your administrator.
Gemini Enterprise supports administrator-managed custom MCP connectors. Configure the connection, enable its actions and check access before delegating work.
- 01
Prepare connector credentials
Ask your administrator for a compatible OAuth client and the server’s authorization details. Keep the credentials in protected connector settings.
- 02
Prepare the managed connector
An administrator adds a Custom MCP Server data store in the Google Cloud console, enters the WorkerKit address and configures the connection.
- 03
Enable actions and verify access
After authentication works, enable the required actions and call key_info before using fleet tools. Do not run, install or change a worker until the person approves.
- WorkerKit MCP address, OAuth client required
https://mcp.workerkit.ai/workers
- Read Google’s custom MCP setup The administrator requirements and supported authentication options.
- Review WorkerKit setup requirements Administrator setup, edition differences and checks after connection.
Why WorkerKit
Control your AI workforce from Gemini Enterprise.
Ready-made, self-learning AI workers with only the access each job needs, a budget you set, and a record of every job and action.
- Put AI workers on jobs with real ROI. Install a kit for work your team already repeats, and a worker arrives with its instructions, app permissions and schedule already written and reviewed. Start with the job that costs the most time, or build your own kit.
- Turn your AI workers’ jobs and data into shared company knowledge. Each job’s instructions, apps and limits live in one kit your team keeps current, and workers that use the Records app keep what they find in shared tables and lists your team can open. Your team and every connected assistant work from the same process.
- Choose what each AI worker can access. Each worker holds its own grant for each app, read-only by default, and nothing it reads can widen it. An assistant's key carries only the scopes you choose and never an app credential.
- Track what your AI workers did and what they changed. Every run leaves a receipt with its result and its cost, and every tool call is logged with its outcome, so you can see what each worker did, when, and at what price.
- Keep AI spending within the limits you set. Each worker has a per-run and a daily spending limit, under a limit for the whole account. When one is reached, new runs stop before any money moves, and the receipt says why.
- Your AI workers learn as they work and keep getting better. A language worker can check every run against its job's quality criteria. A change that makes it better waits for your approval or, in Apply proven changes mode, applies on its own once it passes a comparison on your own examples. Its runs also propose what it should remember, and you approve what it keeps.
What Gemini Enterprise is
Custom integrations managed by your organization.
Gemini Enterprise lets administrators connect custom MCP servers and make their tools available as actions. Workflow Builder can call MCP tools in explicit steps or authorize them for an agent to choose during its work.
| Integration | How it fits |
|---|---|
| Custom MCP server | An administrator configures the connector and enables the actions users need. |
| Agent workflows | Authorized MCP tools can become workflow steps or tools an agent invokes when needed. |
| Custom APIs | An MCP server can expose API operations as tools. This does not make a WorkerKit REST endpoint a connector merely by pasting its URL. |
This is a separate setup from the personal Gemini app. That app also supports custom MCP apps for eligible personal accounts. Enterprise provides the organization-managed route; it is not the only Gemini surface with custom integrations.
Hired specialists
Give each recurring job its own worker.
Keep a job’s model, instructions, approved memory, app permissions and spending limits with the worker. Operate the same fleet from another supported client when your team’s assistant changes.
| Aspect | Gemini Enterprise | A WorkerKit worker |
|---|---|---|
| Integration access | Connectors and actions your administrator makes available | App permissions limited to the particular worker’s job |
| Instructions | The assistant or agent’s configured instructions | Instructions and approved memory kept with each worker |
| Recurring work | Organization-managed agents and workflows | A hosted job with its own schedule, model and budget |
| Results | Answers and workflow output | A run receipt with status, result and settled cost |
| Portability | Configured within your Google environment | The same workers reachable through supported MCP clients, the CLI and the API |
The operator pattern
Delegate a bounded job.
| Step | Who | What happens |
|---|---|---|
| 1 | Administrator | Creates the authenticated connector and enables the required actions. |
| 2 | Agent | Calls key_info, lists the relevant workers and reads the selected worker’s instructions and permissions. |
| 3 | You | Approves the proposed run or configuration change. |
| 4 | Worker | Runs with its own app grants and budget, then records the result and cost. |
| 5 | Agent | Reads the receipt with run_get or recent results with runs_feed and explains the outcome. |
With a configured connector, an Enterprise agent can request work and read the result. Google’s enabled actions and WorkerKit’s scopes both apply; neither substitutes for the other.
Why Gemini Enterprise and WorkerKit
Keep job settings with the work.
Use Enterprise for your organization’s conversations and agent workflows. Keep a WorkerKit job’s grants, approved memory and run history together across supported clients.
| Enterprise capability | WorkerKit alongside it |
|---|---|
| Administrator-controlled connectors | A single fleet endpoint behind scoped WorkerKit access |
| MCP tools in workflows | Delegate to a worker and read its receipt rather than copying the worker’s configuration into every workflow |
| Actions authorized for an agent | A second boundary at the worker’s app grants and the connection’s WorkerKit scopes |
| A shared place for team work | Individual jobs with their own model choice, spending limits and approved memory |
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.
MCP connections
WorkerKit for your fleet. Knowledge for your reports.
Use WorkerKit to discover kits, build workers and manage your fleet. Add Knowledge to search published worker reports. Both use the same sign-in or key.
| Mount | Address | What it carries |
|---|---|---|
| WorkerKit (default) | https://mcp.workerkit.ai/workers | Discover and install kits, build workers, and run and manage your fleet. Choose the full profile or a focused decision profile. Connect with OAuth or a bearer key. |
| Knowledge | https://mcp.workerkit.ai/knowledge | Company Knowledge: 6 tools to search and read published worker reports and track changes. Admins manage publication and reader access. Uses the same sign-in or key. |
| Area | Tools | What it covers |
|---|---|---|
| Continuous Learning | worker_quality_get, worker_quality_set, worker_quality_preview | Read criteria, three gates and availability reasons; save reviewed settings with expectedRevision; preview samples without a run. The worker dashboard offers owner-reviewed activation and a quoted AI draft when criteria are missing. Paid comparisons, diagnosis, monitoring, apply/rollback and company/shadow learning stay owner-only. Manager keys can disable any gate, but cannot enable automatic/shared learning. Kit install leaves all gates off. |
| 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 | Every worker with live run state, one worker in full, and start or stop. |
| Apps and workers | worker_permissions_get, worker_permissions_set, worker_bindings_get, worker_bindings_set | What a worker may touch, in the same vocabulary a kit is written in, and its grants to call other workers: read both, replace its app set (account Admin) and fill, re-point or clear its worker grants. The writes need manageAppsAndWorkers; rules, identities and MCP tool bindings stay in the dashboard. |
| 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, activity_feed, activity_summary, account_spend | Worker runs, app calls and configuration changes, activity counts, everything running now, fleet health, account headroom and spend by worker, day and model. |
| 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, 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. |
| 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, app_github_accounts, app_github_repos, app_github_branches, app_slack_workspaces, app_slack_conversations | 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. The GitHub and Slack lookups find repository and channel IDs for an install (discoverAppResources). |
| 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. |
| API apps | api_apps_list, api_app_get, api_app_create, api_app_update, api_app_validate, api_app_preview, api_app_publish, api_app_version_get, api_app_version_revoke | Account-private API apps: validate and preview a definition offline, create and update drafts, publish immutable versions and revoke them. Authoring needs a live account Admin and managePrivateApiApps; connections and worker bindings are configured in the dashboard. |
| Decision authoring | decision_worker_create, worker_decision_set | Compile typed questions and a supported source recipe into a private kit and installed decision worker. Optional deploy; never starts a run. Requires createWorkers, plus manageDeployments when deploying. Retry the same requestId and body to recover the receipt. worker_decision_set attaches, replaces or removes a hybrid worker's classifier. |
| Action workers | action_worker_options, action_worker_create, worker_tools, worker_tool_call, worker_tool_invocation | Selected app tools with no model, called one at a time with exact inputs. Create with createWorkers; call and read receipts with invokeActions. A write needs an idempotencyKey; never resend an outcome_unknown call. |
| Support | support_request_create | Contact support about an error you cannot fix, a bug, an app request or a question. Returns a PE-XXXXXX reference. |
| 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. |
| Company Knowledge | knowledge_sources, knowledge_search, knowledge_get, knowledge_changes, knowledge_configuration_get, knowledge_configuration_set | On the separate mcp.workerkit.ai/knowledge mount, with the same key: discover, search and read published worker reports, reconcile changes, and configure sharing as an admin. Access follows publication and reader grants. |
The manager key holds no app credentials: workers reach apps under their own grants and firewall, and no prompt can widen that. With readRuns or invokeActions the key can read what those workers return, including an Action worker's tool results.
Your fleet is also available from other MCP clients and the REST API.
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 createWorkers; 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 includes fleet management, app resource discovery, kit authoring and public directory reads. 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 the smaller workflow tool set. 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, Action worker and event-stream tools require the full profile. Successful responses include structured content and a text fallback; creation declares an output schema.
App tools, no model
Call app tools through an Action worker.
One exact app operation per call, with the inputs you supply.
An Action worker (modelType: "none") exposes 1 to 64 selected app tools and has no model, instruction, schedule or deployment. Each call invokes one tool with the arguments the caller sends, under the worker's own app access, and readiness.canInvoke on worker_get says whether its tools can be called now. Run and deploy requests answer 400 action_worker_requires_invoke.
On the workers connection's full profile: action_worker_options lists apps with no tools selected; pass an explicit app for schemas and defaults (readWorkers). action_worker_create requires an explicit app or actionSpec and copies the selected app's default tools, or takes an actionSpec of 1 to 64, plus a slackConnectionId for Slack tools when the account has more than one Slack bot (createWorkers); worker_tools lists the saved tools (readWorkers); worker_tool_call calls one with arguments, plus an idempotencyKey on a write (invokeActions); worker_tool_invocation reads a write's receipt (invokeActions). Pass the returned tokenId. kits_search(modelType:"none") finds Action kits; install one with kit_install and no deploy.
An explicit actionSpec needs no app and can span native or reviewed MCP apps. Private API tools require a dashboard binding to a published version; they are not actionSpec refs.
A write tool (readOnly: false) needs an idempotency key. Repeating the key with the same arguments returns the stored receipt (a confirmation, not the app's response) without calling the app again; with other arguments it is a 409. A call answers with status succeeded, denied, failed, in_progress or outcome_unknown; branch on it, not on the HTTP code. On outcome_unknown the write may have happened: never resend it automatically, under any key; read the receipt and check the app. Each call counts toward the worker's daily request limit; a refusal marked retryable, such as usage_limit, is retried later under a new key. Only the owner changes the selected tools, in the dashboard.
Access and control
Scoped per worker, and scoped for Gemini Enterprise 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. No scope gives it app credentials, but invokeActions returns an Action worker's tool results, so grant it only where an agent should call those tools. 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
Connect through your organization.
An administrator adds a Custom MCP Server data store, configures authentication and enables the actions the agent needs. The setup belongs to the organization rather than the personal Gemini app’s Connected Apps settings.
Follow the WorkerKit setup guide and Google’s custom MCP requirements. Business edition has its own team-managed flow.
For software you build yourself, WorkerKit’s REST API remains available. An API integration needs a configured caller and protected credentials; this page does not claim a direct Enterprise OpenAPI import.
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 Gemini Enterprise is not a paid feature, and the plans are on the pricing page.
Questions
Gemini Enterprise and WorkerKit, answered.
- Is Gemini Enterprise the only Gemini product with custom MCP apps? No. The personal Gemini app also supports custom MCP apps. Google currently limits that feature to adults in the US using a personal Google Account, in English, with Keep Activity enabled. Enterprise connectors are managed by an organization administrator instead.
- How is Enterprise setup different from the personal Gemini app? Enterprise uses an administrator-managed connector with its own authentication configuration and enabled actions. The personal Gemini app lets an eligible user add a custom app from Connected Apps. Use the setup guide for the product your organization uses.
- Can I paste my manager key into the OAuth form? No. A manager key authorizes WorkerKit operations; an OAuth client ID and client secret identify the connector application. They serve different purposes. Keep credentials in protected connector configuration and never put them into chat or agent instructions.
- Can Gemini Enterprise call custom APIs? Its documented MCP workflow integration can reach custom tools and APIs exposed by a server. That requires a configured connector and compatible authentication. It does not establish a direct REST connection to WorkerKit or a place to paste a manager key.
- Does enabling an action give access to all my workers? No. Google’s action setting only makes that tool available on its side. WorkerKit still checks the connection’s scope and worker access, and each worker reaches apps only under its own permissions. Read key_info after authentication to see the actual grant.
- Is Business edition configured the same way? Google documents a separate team administration flow for Business edition and labels its custom MCP connection Pre-GA. Use the guide for your edition, configure authentication and verify access before using worker tools.
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.
To build a kit of your own, how to build a kit walks the procedure, and the kit-authoring skill is the file an agent keeps for it.