Set up WorkerKit in Gemini Enterprise.

Before you start

What you need.

A Gemini Enterprise app and an administrator who can manage its connectors and organization policies. Business edition uses a separate team administration interface.

A WorkerKit account admin who can approve the connection and choose its access.

A compatible OAuth client registered for the Enterprise callback, with its authorization URL, token URL, client ID, client secret and scopes available to the administrator.

A remote HTTPS MCP endpoint using StreamableHTTP. A bearer manager key alone does not satisfy Google’s manual OAuth client form.

Gemini Enterprise exposes custom tools and APIs through MCP connectors. Use the WorkerKit MCP server for fleet operations and kit discovery.

For an eligible personal Google Account, the Gemini app guide covers custom Connected Apps. Enterprise is not the only Gemini product with custom MCP support.

The case for connecting at all is on the Gemini Enterprise page.

Step 0. WorkerKit and Google administrators

Prepare connector authentication.

Have an administrator register a compatible client and keep its credentials in protected settings.

A compatible client must accept https://vertexaisearch.cloud.google.com/oauth-redirect. Google’s form asks for authorization and token URLs, a client ID, client secret and scopes; confirm PKCE and token authentication compatibility with the server as well.

Use the OAuth client credentials supplied for this connector. Keep secrets out of chats, agent instructions and knowledge files.

Step 1. Google administrator

Create the custom MCP connection.

Use your edition’s administrator flow and the credentials prepared in step 1.

1. 01

   Google Cloud-managed Enterprise

   In the Gemini Enterprise console, select your app, then Connected Data Stores, New data store and Custom MCP Server. Follow Google’s guide for the required role and organization policy allowances.

2. 02

   Business edition

   Use Settings and help, your team, Manage team, Connected apps, then Add MCP server. Follow the Business edition guide for its OAuth form; this flow is Pre-GA.

Use https://mcp.workerkit.ai/workers with OAuth and the confirmed client configuration. Keep credentials in the connector’s protected configuration.

Step 2. Google administrator

Enable only the required actions.

A created data store does not automatically make its tools available.

In the Cloud console data store, open Actions, reload custom actions and enable the tools needed for the job. Start with key_info and read operations. Enabling a tool does not grant its WorkerKit scope.

For workflows, an administrator must enable Workflow Builder. An agent step can authorize connectors through Tools & Integrations; deterministic MCP steps are another option. See Google’s workflow instructions.

Step 3. Agent, only after connection succeeds

Check scopes and read the fleet.

Prove authenticated read access before asking a worker to act.

If the fleet is empty after workers_list and runs_feed, the connection is working. New accounts have no workers yet. Skip the run commands and continue to the first-worker step.

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.

Step 4. Agent author

Keep the operating instructions.

Make the WorkerKit rules available to the connected agent.

Read https://workerkit.ai/gemini-enterprise/SKILL.md. Put the relevant operating rules into the agent’s instructions without the YAML header, and keep the tool reference available through supported knowledge or retrieval. Linking the URL alone does not install a skill.

Require key_info at the start of a fleet session and approval before running, installing or changing workers. An enabled Enterprise action still cannot exceed the WorkerKit access granted at consent.

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.

Read the request example and full contract.

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.

Read the call examples.

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.