Connect Gemini Enterprise to C1

Give Gemini Enterprise users access to C1-governed tools, with every tool call attributed to the person who made it.

Google Gemini Enterprise calls the C1 MCP gateway as a tool source. Your users ask Gemini Enterprise a question, Gemini calls a C1 tool on their behalf, and C1 enforces your access policies against that person’s identity. Tool calls are attributed to individual users, not to a shared service account.

Activation required. AI access management must be enabled for your tenant before you can use it. To get started, contact the C1 support team for a walkthrough.

What you’ll do

Setup spans two products. Some stages depend on someone other than you, so line those up before you start.

Stage	Where	Depends on
Collect the values you’ll reuse	C1 and Google Cloud	Nothing
Enable the Google Cloud APIs	Google Cloud	roles/serviceusage.serviceUsageAdmin
Allow custom MCP data connectors	Google Cloud	An organization policy administrator
Prepare Gemini Enterprise	Gemini Enterprise	A Gemini Enterprise subscription
Get the OAuth client ID	C1 and Google Cloud	roles/storage.admin, if you host the document yourself
Create the data store	Gemini Enterprise	roles/discoveryengine.editor
Sign in to the web app	Gemini Enterprise	A licensed user
Enable the actions	Gemini Enterprise	Tool access already granted in C1
Verify the connection	Gemini Enterprise and C1	A user with C1 tool access

Before you begin

Confirm all of these before you start. The organization policy change in particular can take time to arrange.

• AI access management must be enabled for your tenant. See Enable AI access management.
• The users who will use Gemini Enterprise need C1 tool access already. Their access profiles determine which tools they can call, and a user with no toolset sees no tools at all. See Tools and toolsets.
• A Google Cloud project with a Gemini Enterprise app already created. In the console, open Gemini Enterprise and select Create app, or see Google’s Create a Gemini Enterprise app documentation. There is a command-line alternative in Enable the Google Cloud APIs.
• A Gemini Enterprise subscription with licenses available to assign. A new app starts with no users licensed. The identity provider must be set before you create the data store, and licenses must be assigned before tool discovery will work. Both are in Prepare Gemini Enterprise.
• Someone who holds roles/orgpolicy.policyAdmin at the organization level. Project Owner does not include it, and a project-level grant is not sufficient for the policy change below.
• Optional. The gcloud CLI, authenticated with gcloud auth login, if you prefer the command line for the Google Cloud steps.

Collect the values you’ll reuse

The steps below reuse these values. Collect them once.

Value	Where to get it	Example
Tenant	The subdomain of your C1 URL. It is also the prefix of your MCP server URL.	acme
MCP server URL	In C1, open your user profile menu and select AI & API > AI connections. Copy the URL shown at the top of the page.	https://acme-mcp.conductor.one/v1
Project ID	The Google Cloud console project picker, or gcloud config get-value project.	acme-gemini
Project number	gcloud projects describe YOUR_PROJECT_ID --format="value(projectNumber)". This is not the same as the project ID, and a few API calls need it.	514280176422
Your email	The Google identity you run these commands as, and the first person to be licensed.	[e-mail]
App location	At the top of the Gemini Enterprise Apps page, next to Current location.	global

The commands in this guide use global, which is what most setups run. If your app is in a different location, substitute it everywhere locations/global appears.

Your OAuth endpoints follow from the tenant. Confirm them against your tenant’s published metadata:

curl -s https://<your-tenant>-mcp.conductor.one/.well-known/oauth-authorization-server

Read two fields from that response:

Field in the response	Value for tenant acme
authorization_endpoint	https://acme.conductor.one/auth/v1/authorize
token_endpoint	https://acme.conductor.one/auth/v1/token

Required roles

Grant these on the Google Cloud project, except where noted.

Role	Scope	Why
roles/serviceusage.serviceUsageAdmin	Project	Enable the required APIs
roles/discoveryengine.editor	Project	Create the data store and authorize the connection
roles/orgpolicy.policyAdmin	Organization	Allow custom MCP data connectors. Project Owner is not sufficient.
roles/storage.admin	Project	Create the bucket that serves the client metadata document, and make it public. Needed only if you host the document yourself.
roles/discoveryengine.user	Project	Use the Gemini Enterprise web app and call the actions. Grant this to every end user, not just to whoever runs the setup.

To check what you already hold on the project:

gcloud projects get-iam-policy YOUR_PROJECT_ID \
  --flatten="bindings[].members" \
  --filter="bindings.members:user:YOUR_EMAIL" \
  --format="value(bindings.role)"

To grant a role in the console, go to IAM & Admin > IAM, select Grant access, enter the email, and choose the role. To grant one from the command line:

gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member="user:YOUR_EMAIL" \
  --role="roles/discoveryengine.editor"

Enable the Google Cloud APIs

Enable both. In the console, go to APIs & Services > Library, search for the API by the name in the first column, and select Enable. The service ID is the identifier you use with the gcloud CLI.

API to enable	Service ID	Why
Discovery Engine API	discoveryengine.googleapis.com	Backs Gemini Enterprise apps, data stores, and tool discovery
Organization Policy API	orgpolicy.googleapis.com	Required to read or change the policy in the next section

The Cloud Storage API is enabled on new projects by default, so hosting the client metadata document needs no extra API.

Google’s setup documentation for custom MCP servers does not list any APIs, so this list was established by testing, and it is deliberately short. The Connectors, Application Integration, Secret Manager, and IAM APIs are not required. With all four disabled, creating the data connector, authorizing it, discovering tools, calling them, and running the role commands above all succeed.

To enable them from the command line instead:

gcloud services enable \
  discoveryengine.googleapis.com \
  orgpolicy.googleapis.com \
  --project=YOUR_PROJECT_ID

To confirm which APIs are enabled on the project:

gcloud services list --enabled --project=YOUR_PROJECT_ID

Your project can now create custom MCP data connectors.

Create the Gemini Enterprise app from the command line

If you do not already have an app, create one after the APIs are enabled. There is no gcloud surface for this, so call the API directly:

curl -s -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "X-Goog-User-Project: YOUR_PROJECT_ID" \
  -H "Content-Type: application/json" \
  "https://discoveryengine.googleapis.com/v1alpha/projects/YOUR_PROJECT_ID/locations/global/collections/default_collection/engines?engineId=c1-gemini-app" \
  -d '{
    "displayName": "c1-gemini-app",
    "solutionType": "SOLUTION_TYPE_SEARCH",
    "industryVertical": "GENERIC",
    "appType": "APP_TYPE_INTRANET",
    "searchEngineConfig": {
      "searchTier": "SEARCH_TIER_ENTERPRISE",
      "searchAddOns": ["SEARCH_ADD_ON_LLM"]
    }
  }'

An app created this way has no subscription attached. Add one under Manage users in the console before you assign licenses.

Allow custom MCP data connectors

Google Cloud blocks custom MCP data connectors by default through the constraints/discoveryengine.managed.disableCustomMcpServerConnector organization policy. Turn it off for this project before you create the data store.

If the policy is enforced, creating the data store fails at the final step with:

Operation denied by org policy on resource '...':
["constraints/discoveryengine.managed.disableCustomMcpServerConnector":
"This constraint, when enforced, restricts the creation of data connectors
that use a custom MCP server as their data source."]

Check whether it is enforced on your project:

gcloud org-policies describe \
  discoveryengine.managed.disableCustomMcpServerConnector \
  --project=YOUR_PROJECT_ID --effective

The override applies at the project level, but the person applying it needs roles/orgpolicy.policyAdmin, which project Owner does not include.

1. In the Google Cloud console, go to IAM & Admin > Organization policies.

2. Filter for discoveryengine.managed.disableCustomMcpServerConnector and open it.

3. Select Manage policy.

4. Select Override parent’s policy, then set the enforcement to Off.

5. Select Set policy.

From the command line, save this as policy.yaml:

name: projects/YOUR_PROJECT_ID/policies/discoveryengine.managed.disableCustomMcpServerConnector
spec:
  rules:
    - enforce: false

Then apply it:

gcloud org-policies set-policy policy.yaml

Re-run the describe command above. The effective policy reports enforce: false, and your project can create custom MCP data connectors.

Organization policy changes take a minute or two to take effect. Until then the console returns the same denial message, so a failure immediately after you apply the policy does not mean the policy is wrong.

If your organization restricts outbound hostnames

Some organizations enforce constraints/discoveryengine.managed.allowedEgressFqdns, which limits the hosts a data connector may reach. It applies only to projects with VPC Service Controls enabled, or to projects your organization has added to the constraint’s enforced list, so most setups never meet it. Check it with:

gcloud org-policies describe discoveryengine.managed.allowedEgressFqdns \
  --project=YOUR_PROJECT_ID --effective

If the constraint has never been set, this command returns NOT_FOUND: Requested entity was not found. That is the healthy answer and means nothing is restricting egress.

If it does apply, allow the two hostnames your tenant uses. Use hostnames only, not full URLs. This is a boolean constraint that takes parameters, not a list of allowed values. Save this as egress.yaml and apply it with gcloud org-policies set-policy egress.yaml, keeping any hostnames your organization already allows:

name: projects/YOUR_PROJECT_ID/policies/discoveryengine.managed.allowedEgressFqdns
spec:
  rules:
    - enforce: true
      parameters:
        allowedEgressFqdns:
          - <your-tenant>-mcp.conductor.one
          - <your-tenant>.conductor.one

Prepare Gemini Enterprise

A new Gemini Enterprise app has neither of these, and both are needed. The identity provider blocks the data store form itself, with Create greyed out. Licenses do not block that form, but tool discovery fails later without them.

Set the identity provider

Gemini Enterprise needs an identity provider selected for the location your app runs in. Until one is set, creating a data connector fails with You must configure your access control settings before you continue.

Set this before you create any data store. Google’s own warning on this screen is that changing the identity provider later stops access-controlled data stores working, and that you must delete and recreate every one of them to update their permissions.

1. In the Google Cloud console, open Gemini Enterprise.

2. Select Settings, then the Authentication tab.

3. Find the row for your app’s location, such as global, and select the edit icon.

4. Choose Google Identity if your users sign in with Google Workspace accounts, or 3rd Party Identity if you federate through a workforce identity pool.

5. Select Save.

The row for your location now names the provider instead of reading Identity provider is not set up.

To do the same from the command line, for Google Workspace accounts:

curl -s -X PATCH \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "X-Goog-User-Project: YOUR_PROJECT_ID" \
  -H "Content-Type: application/json" \
  "https://discoveryengine.googleapis.com/v1alpha/projects/YOUR_PROJECT_ID/locations/global/aclConfig" \
  -d '{
    "name": "projects/YOUR_PROJECT_ID/locations/global/aclConfig",
    "idpConfig": { "idpType": "GSUITE" }
  }'

The response echoes "idpType": "GSUITE" once it is set.

This page reports You don’t have permissions to fetch Workforce Pools unless you hold a role that can read workforce pools at the organization level. The message is harmless if you are choosing Google Identity, which does not use them.

Assign Gemini Enterprise licenses

A new Gemini Enterprise app has a subscription but no licensed users, and the users list reads No existing users. Assign a license to yourself and to everyone who will use the connector.

1. Open Gemini Enterprise.

2. Select Manage users.

3. Confirm a subscription is listed and Active, and note how many licenses are unassigned.

4. Select Add users.

5. Enter the email addresses, choose the subscription, and select Submit.

Each address now appears in the users list with a license and an assignment date.

To do the same from the command line, first list the subscriptions available to assign:

curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "X-Goog-User-Project: YOUR_PROJECT_ID" \
  "https://discoveryengine.googleapis.com/v1alpha/projects/YOUR_PROJECT_ID/locations/global/licenseConfigs"

Each returned name ends in the subscription ID, such as free_trial_gemini. Then assign it, using your project number inside licenseConfig:

curl -s -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "X-Goog-User-Project: YOUR_PROJECT_ID" \
  -H "Content-Type: application/json" \
  "https://discoveryengine.googleapis.com/v1alpha/projects/YOUR_PROJECT_ID/locations/global/userStores/default_user_store:batchUpdateUserLicenses" \
  -d '{
    "inlineSource": {
      "userLicenses": [
        {
          "userPrincipal": "YOUR_EMAIL",
          "licenseConfig": "projects/YOUR_PROJECT_NUMBER/locations/global/licenseConfigs/YOUR_SUBSCRIPTION_ID",
          "licenseAssignmentState": "ASSIGNED"
        }
      ]
    }
  }'

Get the OAuth client ID

Gemini Enterprise authenticates each user to C1 with the OAuth 2.0 authorization code flow, and it needs an OAuth client that already exists. It does not register one itself, and it does not publish a client identity you can point at.

C1 does not hand out an opaque client ID from a registration form. Instead, the client ID is a URL: it points at a small public JSON file describing the client, called a Client ID Metadata Document. C1 fetches that URL to learn who the client is, which means someone has to host the document.

Google is the party that should host it, since Gemini Enterprise is the client it describes. Today it does not, and Google’s own instructions are to register the MCP server as an OAuth client with your identity provider and take a client ID from it. Until Google publishes a document, somebody else has to host one on Google’s behalf.

Who hosts it	Client ID	Status
Google	A Google-published URL	Not published. The preferred outcome
You	The URL you publish it at	Works today
C1	https://<your-tenant>.conductor.one/auth/v1/client-metadata/gemini-enterprise	Not available yet

Host the document yourself for now. The C1-hosted document has not shipped, so every tenant returns a 404 from that URL, and it is a stopgap rather than the end state: a client identity carries the most weight when the client’s own vendor publishes it. Contact the C1 support team for timing.

When Google publishes a client metadata document for Gemini Enterprise, use that URL as the client ID and retire whatever you were hosting.

This client has no secret, so nothing expires and nothing needs rotating. Configure it once and it keeps working.

Do not register a client through C1’s dynamic registration endpoint instead. An unapproved dynamic registration’s secret expires one hour after it is issued, and rotating it preserves the original expiry rather than extending it, so the connector fails at its first token refresh.

Host the client metadata document yourself

Publish this JSON at any public HTTPS URL you control. Two fields are unforgiving: client_id must exactly equal the URL the document is served from, and redirect_uris must contain Google’s redirect endpoint verbatim.

Save the file as gemini-enterprise-oauth-client.json. The Cloud Storage commands below serve it at https://storage.googleapis.com/YOUR_BUCKET/gemini-enterprise-oauth-client.json, so set client_id to exactly that, with your own bucket name:

{
  "client_id": "https://storage.googleapis.com/YOUR_BUCKET/gemini-enterprise-oauth-client.json",
  "client_name": "Gemini Enterprise",
  "client_uri": "https://cloud.google.com/gemini/enterprise",
  "redirect_uris": ["https://vertexaisearch.cloud.google.com/oauth-redirect"],
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

C1 fetches this document over the public internet, so it must be reachable without authentication. A Cloud Storage bucket works. Replace YOUR_BUCKET with a bucket name you choose, which must be globally unique across all of Cloud Storage:

gcloud storage buckets create gs://YOUR_BUCKET \
  --project=YOUR_PROJECT_ID \
  --location=us-central1 \
  --uniform-bucket-level-access

gcloud storage cp gemini-enterprise-oauth-client.json gs://YOUR_BUCKET/

gcloud storage buckets add-iam-policy-binding gs://YOUR_BUCKET \
  --member=allUsers \
  --role=roles/storage.objectViewer

Two organization policies can block that public binding. If the next command fails, see If an organization policy blocks the public binding below.

Confirm the document resolves before you continue. It returns the JSON you published, and its client_id matches the URL you requested:

curl -s https://storage.googleapis.com/YOUR_BUCKET/gemini-enterprise-oauth-client.json

That URL is the value you use as the client ID.

If an organization policy blocks the public binding

The two constraints below are separate from the constraint in Allow custom MCP data connectors, and both need roles/orgpolicy.policyAdmin. To change either in the console, use the same IAM & Admin > Organization policies flow described there, searching for the constraint name below instead.

Domain restricted sharing. If constraints/iam.allowedPolicyMemberDomains is enforced, granting allUsers fails with:

HTTPError 412: One or more users named in the policy do not belong to a permitted customer.

The constraint does not accept allUsers as an allowed value, so the override has to permit all values. Save this as drs.yaml and apply it with gcloud org-policies set-policy drs.yaml:

name: projects/YOUR_PROJECT_ID/policies/iam.allowedPolicyMemberDomains
spec:
  rules:
    - allowAll: true

This override is project-wide, not bucket-scoped. Any resource in the project can then be shared publicly. Publish the document from a project dedicated to it rather than one holding other data, and remove the override as soon as you stop hosting the document.

Public access prevention. If constraints/storage.publicAccessPrevention is enforced, the binding is refused regardless of the constraint above. Save this as pap.yaml and apply it with gcloud org-policies set-policy pap.yaml:

name: projects/YOUR_PROJECT_ID/policies/storage.publicAccessPrevention
spec:
  rules:
    - enforce: false

Check the effective value of either constraint with:

gcloud org-policies describe storage.publicAccessPrevention \
  --project=YOUR_PROJECT_ID --effective

Organization policy changes take a minute or two to take effect, in both directions. After you apply the override, the binding can still fail with the same 412 for a short while, and describe --effective may report the new value before enforcement catches up. Retry the binding rather than assuming the override is wrong, and confirm success by fetching the document URL.

Create the data store

Connect the C1 MCP gateway to your Gemini Enterprise app.

Creating the connector is the one step you cannot script. The public Discovery Engine API refuses it:

Data Connector parameters must be one of: oauth_access_token but got: instance_uri

It accepts only a pre-obtained access token, not the OAuth client configuration, so it cannot run the per-user authorization this integration depends on. Discovering the tool list is console-only too, because the method behind Reload custom actions is not on the public endpoint. Choosing which actions are enabled, however, can be scripted once the tools are discovered. See Enable the actions.

The data connector name generates an ID that cannot be changed later. Choose it before you begin, and keep it short and lowercase with hyphens, such as c1-mcp-gateway.

Use the Custom MCP Server card, not a server imported from Agent Registry. A connector created from a registry import fails tool discovery with Failed to reload custom actions and a FAILED_PRECONDITION error, while an otherwise identical connector created from the Custom MCP Server card completes normally.

Finish Prepare Gemini Enterprise before you open this form. If you leave the wizard partway through to set the identity provider, you return to a partially reset form and it is easy to submit it incomplete.

1. In the Google Cloud console, open Gemini Enterprise.

2. Select your app.

3. Select Connected data stores, then select New data store.

4. In Select a data source, search for Custom MCP.

5. On the Custom MCP Server card, select Add MCP server.

6. Under Authentication settings, choose OAuth 2.0.

7. Complete the fields. The third column is where this form most often goes wrong.

   Field	Value	Watch out for
   MCP Server URL	https://<your-tenant>-mcp.conductor.one/v1	Ends with /v1.
   Authorization URL	https://<your-tenant>.conductor.one/auth/v1/authorize	No trailing parameters.
   Authorization URL Parameters	&resource=https://<your-tenant>-mcp.conductor.one/v1	Required. C1 binds tokens to a resource, so omitting this yields a token your MCP endpoint rejects.
   Token URL	https://<your-tenant>.conductor.one/auth/v1/token	No special handling
   Client ID	Your client metadata document URL	The full https:// URL, not a bare identifier.
   Client Secret	none	Proof Key for Code Exchange (PKCE) needs no secret, but the console requires a value in this field, and Google’s documentation says to enter none. C1 never reads it.
   Scopes	openid profile email offline_access	Space-separated, not comma-separated.
   Enable PKCE Support	Selected	Not selected by default. C1 requires PKCE, so the flow fails without it.
   Use HTTP Basic Authentication	Cleared	Selected by default. Leaving it selected sends credentials in an Authorization header, which does not work for a client with no secret.

8. Select Verify Auth. A window opens for you to sign in through your identity provider and authorize the connection.

9. Select Continue.

10. Enter your Data connector name, then select Continue.

    Leave Location as it is, and leave Sensitive data protection policy empty unless your organization requires one.

11. Select Create.

    Some versions of the console add a Select the pricing model step first. If you see it, leave General pricing selected unless your organization has chosen a subscription, then select Create.

The form shows Successfully logged in after you authorize. The connector is created immediately and reaches the Active state within a minute.

Sign in to the web app

Do this before you reload the actions. Tool discovery runs as the signed-in user, and it fails if that user has never opened the Gemini Enterprise web app. The console gives no hint that this is the cause: Reload custom actions simply reports Failed to reload custom actions.

This is the step most often missed, because nothing in the admin console mentions it and nothing about the connector looks wrong. The connector reads Active, every setting is correct, and discovery still fails until a licensed user has signed in once.

Signing in through Verify Auth while creating the connector does not count. That authorizes the connector; this is a separate sign-in to the web app itself.

1. In the Google Cloud console, open Gemini Enterprise.

2. Select your app, then open Overview.

3. Copy the web app URL shown there. It looks like https://vertexaisearch.cloud.google.com/home/cid/<id>.

4. Open that URL as a licensed user and select Get started on the welcome panel.

One sign-in by one licensed user unblocks tool discovery for the whole connector. Each user still authorizes the connector separately later, in Verify the Gemini Enterprise connection; that is a different action, and it cannot happen until the actions are enabled.

To confirm the sign-in registered, check that lastLoginTime is present:

curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "X-Goog-User-Project: YOUR_PROJECT_ID" \
  "https://discoveryengine.googleapis.com/v1alpha/projects/YOUR_PROJECT_ID/locations/global/userStores/default_user_store/userLicenses"

A user with a license but no lastLoginTime has never opened the web app, and tool discovery will fail for them.

Enable the actions

Gemini Enterprise calls MCP tools actions, and imports every one of them turned off. Enable them on the data connector, not on the app’s Actions page, which only redirects you here. Turn on only the actions your users need: a data store supports a maximum of 100 enabled actions, and a shorter list makes the agent’s tool selection more accurate.

Wait for the connector state to reach Active before you start. The reload fails while the connector is still creating.

Reload custom actions takes about 30 seconds. Gemini Enterprise calls your MCP server for its tool list and holds the request open while it waits. The table stays empty until it finishes, which looks like a silent failure if you navigate away early. Wait for the Custom actions reloaded confirmation.

1. Open the data store, then select the Actions tab.

2. Select Reload custom actions. Gemini Enterprise queries your MCP server for its current tool list.

3. Select the actions to expose.

4. Select Enable actions.

The actions you selected are now enabled on the connector. No one can call them yet: each user must authorize the connector themselves, which is the first part of Verify the Gemini Enterprise connection.

Set the enabled actions from the command line

Once the tools are discovered, the enabled set is an ordinary field you can write, which is easier to keep consistent across environments than clicking through the table. Read the current list first:

curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "X-Goog-User-Project: YOUR_PROJECT_ID" \
  "https://discoveryengine.googleapis.com/v1alpha/projects/YOUR_PROJECT_ID/locations/global/collections/YOUR_COLLECTION_ID/dataConnector"

dynamicTools holds every discovered tool and bapConfig.enabledActions holds the enabled ones. Write a new set with a PATCH, sending the complete list, since it replaces rather than merges:

curl -s -X PATCH \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "X-Goog-User-Project: YOUR_PROJECT_ID" \
  -H "Content-Type: application/json" \
  "https://discoveryengine.googleapis.com/v1alpha/projects/YOUR_PROJECT_ID/locations/global/collections/YOUR_COLLECTION_ID/dataConnector?updateMask=bapConfig.enabledActions" \
  -d '{
    "bapConfig": {
      "enabledActions": [
        "search_tools",
        "execute",
        "get_execution",
        "list_guides",
        "load_guide",
        "create_vfs",
        "create_vfs_artifact",
        "list_vfs_files",
        "get_vfs_download_url",
        "find_api_objects",
        "count_api_objects",
        "query_metrics"
      ]
    }
  }'

Your collection ID is the one shown as Collection ID on the data store’s Details tab.

Reach every tool without spending your action budget

The C1 gateway publishes far more tools than the 100 a data store can enable. Rather than choosing a hundred of them, enable the twelve tools above. They let the agent find and run any tool your access profiles allow:

Tool	What it does
search_tools	Finds the right tool for a task across everything you can reach, and returns its input and output schema
execute	Runs a short TypeScript program that calls those tools, so several calls happen in one step
get_execution	Collects the result of a program that ran too long to answer inline
list_guides, load_guide	Fetch usage guides for the more involved flows
create_vfs, create_vfs_artifact, list_vfs_files, get_vfs_download_url	Give that program a scratch filesystem, and hand results back as files
find_api_objects, count_api_objects	Look up and count C1 objects such as users, apps, and entitlements, without writing a program
query_metrics	Return bucketed time series for reporting questions in one call

Add whichever named C1 actions your users ask for by name on top of those, and the rest stay reachable through search_tools.

Enable get_execution alongside execute. A program that runs longer than about 25 seconds returns a pending status and an execution ID instead of a result, and get_execution is what collects it. Without it those runs cannot be recovered and the agent reports a failure for work that actually succeeded.

The enabled set still only decides what is offered. Every call is evaluated against the calling user’s access profiles, so this changes what the agent can find, never what a person is allowed to do.

The console toast is not a reliable signal. To see whether a reload actually succeeded, read the audit log:

gcloud logging read 'protoPayload.methodName:"RefreshDataConnectorTools"' \
  --project=YOUR_PROJECT_ID --limit=5 --freshness=10m \
  --format="value(timestamp,severity,protoPayload.status.message)"

A 401 entry on its own is normal: the console retries and a successful reload logs an entry with no error a few seconds later. Judge by that later entry, not by the first error.

Verify the Gemini Enterprise connection

Seeing actions listed does not confirm your credentials work. You confirm the setup only when a user successfully calls a C1 tool.

1. Open your Gemini Enterprise web app as an end user who has C1 tool access.

2. In the message box, select the Connectors icon. Your connector is listed with an Authorize link beside it.

3. Select Authorize, sign in through your identity provider, and approve. The connector then shows a toggle, switched on.

   Every user does this once, for themselves. Enabling actions as an administrator authorizes nobody. Until a user authorizes here, the assistant answers that it has no C1 integration, even though the actions are enabled and the connector is Active.

4. Ask a question that needs a C1 tool, naming the connector, such as “Using the C1 connector, list the access reviews in C1.”

5. The assistant names the action it wants to call and waits. Select Send to confirm it.

6. In C1, go to AI > C1 Gateway and select the AI clients tab. Gemini Enterprise is listed with a registration type of CIMD, and People connected counts the users who have authorized it. The AI connections tab shows one row per user. Users can see their own connections under their profile menu at AI & API > AI connections.

   The Verified column shows the domain that serves your client metadata document, so a self-hosted document reads storage.googleapis.com rather than a Google domain. That is expected while you host the document yourself.

7. Confirm the tool call was logged. Every call through C1 MCP records the end user, the tool, the result, and a denial reason when refused. See Audit AI tool usage.

The connection is working, and every tool call is attributed to the user who made it.

If the agent does not call a tool, returns nothing, or reports a denial, see Troubleshoot Gemini Enterprise connection errors. A denial that names a missing toolset or access profile is C1 working as configured, not a broken integration.

Troubleshoot Gemini Enterprise connection errors

Symptom	Cause	Fix
Operation denied by org policy when you create the data store	The disableCustomMcpServerConnector constraint is enforced, or the override has not propagated.	Turn the constraint off and wait several minutes. See Allow custom MCP data connectors.
The override is set but the denial persists	An enforced organization- or folder-level policy overrides your project setting.	Re-run the describe --effective command. If it still reports enforce: true, ask your organization policy administrator to add the project exception.
PERMISSION_DENIED on gcloud services enable	The caller lacks roles/serviceusage.serviceUsageAdmin on the project.	Grant it. See Required roles.
PERMISSION_DENIED on gcloud storage buckets create or the allUsers binding	The caller lacks roles/storage.admin on the project.	Grant it. See Required roles.
You must configure your access control settings before you continue, and Create is greyed out	No identity provider is set for the app’s location.	Set one, then return to the form. See Set the identity provider.
Client ID and Client Secret are blank on the Re-authenticate panel	Expected. The console never displays stored credentials, on a working connector or a broken one.	Nothing to fix. To change them, type both in again and select Verify Auth.
404 on the client metadata URL	Nothing is hosting a document at that URL, or the file is not publicly readable.	Confirm you are using a URL you host yourself. The C1-hosted URL is not available yet. See Get the OAuth client ID.
We encountered some problems during authentication	The client ID is wrong, or the sign-in window was closed or blocked.	Confirm the client ID resolves, allow popups for the console, and retry Verify Auth.
The form will not accept an empty Client Secret	The console treats the field as required.	Enter none, as in Create the data store. C1 never reads it.
Failed to reload custom actions on a connector imported from Agent Registry	Registry-imported connectors fail discovery with FAILED_PRECONDITION.	Recreate the data store from the Custom MCP Server card. See Create the data store.
Failed to reload custom actions on a connector that is Active	The most common cause by far is that the signed-in user has never opened the Gemini Enterprise web app.	Open the web app as that user, then reload again. See Sign in to the web app.
Failed to reload custom actions, and the user has signed in	The connector is still creating, discoveryengine.googleapis.com is not enabled, the user holds no license, or no identity provider is set.	Wait for Active, then check each in turn. See Prepare Gemini Enterprise.
Reload custom actions shows no error and no actions	Most often the reload is still running. It takes about 30 seconds.	Wait for the Custom actions reloaded confirmation, then reload the page.
The action list stays empty after the reload finishes	C1 returned an empty tool list for the authorizing user, which happens when that user has no toolset.	Assign the authorizing user an access profile that includes the tools you expect, then reload again. See Tools and toolsets.
The assistant answers that it has “no ConductorOne integration”	The user has not authorized the connector in the web app. Enabling actions authorizes nobody.	In the message box, open Connectors and select Authorize beside your connector. See Verify the Gemini Enterprise connection.
The assistant picks a web search instead of a C1 action	No enabled action matches the request, so nothing is callable.	Enable the actions the request needs, and name the connector in the prompt.
A user’s tool calls are denied while another user’s succeed	C1 is enforcing that user’s access profile. This is expected behavior.	Check the denial reason in the audit log. See Audit AI tool usage.
Authorization works, then breaks about an hour later	The connector uses a dynamically registered client whose secret expired.	Host a Client ID Metadata Document and use its URL as the client ID instead of registering dynamically. See Get the OAuth client ID.
Tool calls fail immediately after a working Verify Auth	The token is not bound to your MCP endpoint.	Set Authorization URL Parameters to &resource=https://<your-tenant>-mcp.conductor.one/v1.
failed to fetch client metadata	C1 fetches its own client metadata document over the public internet, and your tenant hostname does not resolve publicly.	This affects self-managed C1 deployments rather than C1 cloud tenants. Contact the C1 support team.

To correct an authentication value, edit the existing connector’s settings rather than recreating it. The connector name cannot be changed after creation, as noted in Create the data store, so changing it means creating a new data store and removing the old one.

What this integration cannot do

These constraints come from Gemini Enterprise and Google Cloud.

• VPC Service Controls and Private Service Connect are not supported for custom MCP data stores. If your Google Cloud perimeter requires either, this integration cannot run inside it.
• Gemini Enterprise supports egress mode only. It calls out to your MCP server; your MCP server cannot call in.
• A data store supports a maximum of 100 enabled actions.

C1’s gateway already satisfies Google’s other requirements for a custom MCP server: it uses StreamableHTTP transport rather than server-sent events, and it presents a certificate from a publicly trusted authority.

Frequently asked questions about connecting Gemini Enterprise

Does a shared client ID mean Gemini Enterprise sees everyone's data?

No. The client ID identifies Gemini Enterprise as an application, not as a user. Every person authorizes individually through your identity provider and receives their own token. C1 evaluates each tool call against that person’s access profiles, and their activity is logged under their own identity.

Why does the Client Secret not matter?

The client is a public OAuth client with no secret. Client ID Metadata Document clients cannot use shared secrets, so C1 never reads the field. Security comes from the authorization code flow with PKCE, which you turn on with Enable PKCE Support.

Do I need Agent Gateway or Agent Registry?

No, and this was tested rather than taken on trust. A working connector reports use_agent_gateway_egress: false, so its traffic never passes through Agent Gateway, and a setup built with no gateway and no registry discovers tools and serves live tool calls normally. C1 governs the tool calls.

Agent Registry is a catalog of approved MCP servers. Listing the C1 gateway there is a separate exercise that changes nothing about this integration. If you do list it, still create your data connector from the Custom MCP Server card: a connector imported from the registry fails tool discovery.

How do I cut off access in a hurry?

In C1, open AI > C1 Gateway, select the AI clients tab, find the Gemini Enterprise client, and use its kill switch. It revokes all tokens for that client immediately, for every user. To cut off one person instead, use Revoke on their row in the AI connections tab. See Manage AI clients.

Can I see what tools Gemini Enterprise called?

Yes. Every tool call through C1 MCP is logged with the end user, the tool, the result, and a denial reason when refused. See Audit AI tool usage.

Pages related to governing AI tool access

These pages cover the C1 side of the integration.

• Tools and toolsets covers the access profiles that decide which tools each user can call.
• Manage AI clients covers lifecycle states, the kill switch, and allowed client types.
• Connect to the C1 MCP covers the same gateway from desktop AI assistants.
• Audit AI tool usage covers what C1 logs for every tool call.