Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.mistle.dev/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

Connect to Google Cloud by authorizing Mistle with a Google OAuth client that you create in Google Cloud. Mistle uses the OAuth authorization code flow to obtain Google access tokens, then uses those tokens to call Google-hosted MCP servers selected in a sandbox profile. The connected Google user remains subject to Google Cloud IAM. OAuth lets Mistle request a token; IAM decides what that token can do in each Google Cloud project and resource.

​
OAuth And IAM

Google Cloud access has two independent parts:
  1. OAuth client and scopes - identify the application and allow Mistle to obtain Google tokens. Mistle currently requests the https://www.googleapis.com/auth/cloud-platform scope so selected Google Cloud MCP servers can use Google Cloud APIs.
  2. IAM grants - authorize the Google principal that completes OAuth. Grant IAM roles to that user, or to a Google group that contains that user, on the Google Cloud projects and resources the agent should access.
The Google OAuth client can live in one Google Cloud project, while IAM access can be granted in other resource projects. The user who clicks Connect Google Cloud must have the required IAM roles wherever the selected MCP tools will operate.

​
Create A Google OAuth Client

Create a Web application OAuth client in Google Auth Platform.
  1. In Mistle, open Integrations and choose Google Cloud. Mistle uses Google OAuth for this connection.
  2. Copy the callback URL shown by Mistle.
  3. In Google Cloud, open Google Auth Platform > Clients.
  4. Create an OAuth client with Application type set to Web application.
  5. Add the Mistle callback URL to Authorized redirect URIs.
  6. Create the client and copy its Client ID and Client secret.
  7. Return to Mistle, enter the client ID and client secret, and click Connect Google Cloud.
  8. Complete the Google consent flow with the Google account that should back the connection.
If your Google Auth Platform app is in testing mode, add the authorizing Google account as a test user before connecting.

​
Configure IAM

Grant roles/mcp.toolUser to every Google principal that will call Google-hosted MCP tools through Mistle. Then add the product-specific IAM roles for the MCP servers selected in the sandbox profile. 
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:USER_EMAIL" \
  --role="roles/mcp.toolUser"
Replace PROJECT_ID with the Google Cloud project and USER_EMAIL with the Google account that authorizes the Mistle connection. To grant access through a Google group, use --member="group:GROUP_EMAIL" for a group that contains the authorizing user. Run the same command once for each additional role you grant: 
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:USER_EMAIL" \
  --role="ROLE"
If the required APIs are not already enabled, an administrator may also need roles/serviceusage.serviceUsageAdmin to enable them: 
gcloud services enable \
  cloudresourcemanager.googleapis.com \
  container.googleapis.com \
  logging.googleapis.com \
  run.googleapis.com \
  storage.googleapis.com

​
MCP IAM Reference

MCP serverRead-only IAM to start withWhen to grant more
All Google Cloud MCPsroles/mcp.toolUser on the projectRequired for MCP tool calls. This does not replace product-specific service permissions.
Cloud Resource Managerroles/browser on the project, folder, or orgroles/mcp.toolUser already includes basic project get/list permissions. Use broader Resource Manager roles only when agents need folder, organization, IAM policy, or project-management actions.
Cloud Storageroles/storage.objectViewer on the project or bucketUse roles/storage.objectUser, roles/storage.objectAdmin, or roles/storage.admin for write/admin work.
Cloud Loggingroles/logging.viewer on the project or log viewUse roles/logging.privateLogViewer for Data Access audit logs, or roles/logging.admin for config work.
Cloud Runroles/run.viewer on the project, service, or jobDeploy-capable access needs Cloud Run permissions plus deployment prerequisites such as Service Account User on the runtime identity and Artifact Registry access to the image source. Follow Google’s Cloud Run IAM and deployment docs for write paths.
Google Kubernetes Engineroles/container.clusterViewer on the projectUse stronger Kubernetes Engine roles only when agents should create or modify clusters or workloads.

​
Connect MCP Servers To A Sandbox Profile

After the Google Cloud connection is active:
  1. Open the sandbox profile that should use Google Cloud.
  2. Add the Google Cloud integration connection to the profile.
  3. In Resources & Tools, select the Google Cloud MCP servers that agents may use.
  4. Publish the profile version.
Only selected MCP servers are exposed to sessions using that published profile.

​
Official References