Google Cloud MCP Server: Setup, Authentication, IAM, and Secure Usage
Learn what Google Cloud MCP servers are, how to connect an AI client, configure authentication and IAM, and operate tools safely.
Google Cloud MCP server refers to Google’s managed remote Model Context Protocol (MCP) endpoints for individual Google Cloud services. There is no single all-purpose endpoint: you choose the service you need, enable that product, authenticate the AI client, and grant both MCP-call permission and the underlying service permissions.
Google hosts these remote servers on its infrastructure and exposes them over HTTP. Examples include BigQuery (https://bigquery.googleapis.com/mcp), Cloud Run (https://run.googleapis.com/mcp), Cloud Storage (https://storage.googleapis.com/storage/mcp), Cloud SQL (https://sqladmin.googleapis.com/mcp), Cloud Logging (https://logging.googleapis.com/mcp), Cloud Monitoring (https://monitoring.googleapis.com/mcp), Compute Engine (https://compute.googleapis.com/mcp) and IAM (https://iam.googleapis.com/mcp). The supported-products catalogue changes, and some entries are Preview, so check Google’s current catalogue and product references before deployment.
What is the Google Cloud MCP server?
MCP standardizes how an AI application discovers and calls tools. Google’s managed remote servers adapt that interface to particular Cloud products. A BigQuery server exposes BigQuery-related tools; an IAM server exposes IAM-related tools. Tool names, toolsets, regions, supported operations and write capabilities vary by product.
Keep these deployments separate:
- Google-managed remote server: an HTTP endpoint operated on Google’s service infrastructure.
- Local MCP server: a process running on your workstation or your own runtime.
- Third-party server: software published and operated by another party.
How to connect an AI agent to Google Cloud with MCP
- Choose the Google Cloud product and read its MCP reference. Confirm the endpoint, available tools, toolsets and whether operations can change resources.
- Enable the required product or API in the Cloud project.
- Configure an authentication method supported by your AI client: Application Default Credentials (ADC), OAuth 2.0 client credentials, or an authorization header containing a bearer token.
- Grant the calling identity
roles/mcp.toolUser, or a custom role containingmcp.tools.call. - Grant the service-specific permissions required by each tool.
- Register the remote endpoint in the AI client and invoke a tool using that client’s MCP configuration.
Google’s remote servers do not support Dynamic Client Registration or OAuth Client ID Metadata Documents. Client support differs, so verify which credential flow your application can send. The documented protocol behavior is version-sensitive; the current overview describes MCP version 2026-07-28 and a stateless request model. Recheck the live documentation before relying on protocol details in production.
Authentication options
Application Default Credentials
ADC is useful when the agent runs in Google Cloud or on a developer machine configured with Google credentials. The client obtains credentials from the standard Google authentication chain and sends an access token to the remote MCP endpoint.
# Local development example
gcloud auth application-default login
gcloud auth application-default set-quota-project YOUR_PROJECT_IDUse a dedicated workload or service identity for production. Avoid sharing a personal user credential with an autonomous agent.
OAuth 2.0 client credentials
An AI client can use an OAuth client ID and secret when it supports Google’s documented OAuth flow. Store secrets in the client or workload’s secret manager and rotate them according to your security policy.
Bearer token in an HTTP header
Clients that allow custom headers can send a Google access token directly:
ACCESS_TOKEN="$(gcloud auth application-default print-access-token)"
curl -i \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
https://logging.googleapis.com/mcpThe endpoint expects MCP requests, so a plain GET is only a connectivity check; use your MCP client’s request format for actual tool discovery and calls.
IAM permissions: MCP access and service access are separate
roles/mcp.toolUser contains mcp.tools.call, which permits making MCP tool calls. It does not automatically grant access to BigQuery datasets, Cloud Storage objects, IAM roles or other resources. Add only the permissions required by the selected tools.
| Task | MCP permission | Underlying permission |
|---|---|---|
| Call any permitted MCP tool | mcp.tools.call |
Service-specific permission still required |
| Manage custom IAM roles | mcp.tools.call |
roles/iam.roleAdmin |
| Manage deny policies | mcp.tools.call |
roles/iam.denyAdmin |
The IAM MCP endpoint can inspect and manage custom roles and deny-policy configurations. Treat those tools as privileged: a successful call can change who or what is allowed to access resources. Use a separate agent identity, narrow project or resource scope, approval gates for writes, and audit review.
Google Cloud services that support MCP
The catalogue includes services such as BigQuery, Bigtable, Cloud Run, Cloud Storage, Cloud SQL, Cloud Logging, Cloud Monitoring, Compute Engine, IAM, GKE, Pub/Sub and Spanner. Coverage and status change over time; some endpoints are regional or Preview. Use the supported-products catalogue and the specific product’s MCP reference as the source of truth.
Read-only versus write-capable tools
MCP is an interface, not a read-only guarantee. One product may expose inspection tools while another exposes create, update or delete operations. Read every tool’s description and required role before enabling it. For write-capable agents:
- Use a dedicated service account or workload identity.
- Grant the smallest set of service permissions.
- Limit the project, folder or resource scope.
- Require human confirmation for destructive or policy-changing calls.
- Log calls and review the returned arguments and results.
Security, governance and Model Armor
Google documents IAM controls, centralized audit logging and optional Model Armor scanning for MCP calls and responses. Availability and routing depend on region. Logging can include the entire payload, so inspect retention and data-residency implications before sending secrets or regulated data. Resource/read calls used to render an MCP App are not scanned by Model Armor even when tool calls are scanned. Confirm the current regional behavior in Google’s management documentation.
Local or self-hosted MCP server versus Google-managed endpoint
| Decision area | Google-managed endpoint | Local or self-hosted server |
|---|---|---|
| Operations | Google operates the service infrastructure. | You operate the process, deployment and updates. |
| Coverage | Use the selected product’s published tools and toolsets. | You choose or implement integrations. |
| Identity | ADC, OAuth or bearer-token support depends on the client. | You define credential handling and network controls. |
| Governance | Google IAM, audit controls and optional Model Armor apply. | You own logging, scanning, routing and residency controls. |
Troubleshooting
401 Unauthorized
Cause: missing, expired or incorrectly formatted token. Fix: obtain a fresh Google access token, send Authorization: Bearer TOKEN, and confirm the client is using a supported authentication method.
403 Permission denied
Cause: the identity lacks mcp.tools.call, the service permission, or access to the target resource. Fix: grant roles/mcp.toolUser and the product-specific role at the narrowest practical scope; then retry with the intended project and identity.
404 or endpoint not found
Cause: wrong product endpoint, disabled API, or a regional endpoint used as a global one. Fix: copy the endpoint from the current catalogue and enable the corresponding product/API.
Tool is missing
Cause: the tool belongs to another product, toolset or Preview release. Fix: consult that service’s MCP reference and verify the client refreshed its tool list.
Request hangs or times out
Cause: network egress restrictions, proxy configuration, slow underlying operation or an incorrect MCP request. Fix: test HTTPS connectivity, allow the endpoint through the proxy, inspect client timeout settings and check the product’s operation limits.
Works locally but fails in production
Cause: production uses a different service account, project, region or organization policy. Fix: print the active identity and project in both environments, then compare IAM bindings, enabled APIs, egress rules and endpoint geography.
Performance, reliability and cost considerations
- Latency: total time includes the AI client’s planning, network round trips and the underlying Cloud API operation. Keep prompts and tool arguments narrow and avoid serial calls when the client can safely run independent reads in parallel.
- Reliability: handle HTTP failures and tool errors, use bounded retries with backoff for transient failures, and make write operations idempotent where the product supports it.
- Quotas: MCP calls consume the selected Google Cloud service’s quotas and may also be subject to client or endpoint limits. Check the product reference before bulk automation.
- Cost: Google Cloud pricing is determined by the underlying service and resources used. MCP does not make those operations free; review the product’s pricing and quota documentation.
- Auditability: retain request IDs and tool results where your policy permits, and avoid placing credentials or unnecessary personal data in prompts.
Or skip the browser setup
If your goal is website screenshots for an agent or pipeline, ScreenshotNeo provides a purpose-built screenshot API and MCP server instead of requiring you to operate browser infrastructure. One request returns PNG, JPEG, WebP or PDF:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpimport requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);See the ScreenshotNeo API documentation for all options. Cookie banners, popups and chat widgets are removed before the shot; bot checks, blank pages and failed loads are never billed; an MCP server lets AI agents take screenshots; 1,000 screenshots a month are free with no card and paid plans start at $5 for 3,000. Create a free ScreenshotNeo account.
FAQ
Is there one universal Google Cloud MCP URL?
No. Google publishes product-specific managed endpoints. Select the service endpoint that matches the tools you need.
Can an MCP client use a service account?
Yes, when the client supports ADC, workload identity or an equivalent bearer-token flow. Confirm the client’s credential support and grant the identity the required roles.
Does roles/mcp.toolUser grant access to my data?
No. It grants the MCP call permission. The identity also needs the selected service’s permissions and access to the target resource.
Are all Google Cloud MCP servers generally available?
No. The catalogue includes Preview entries and changes over time. Check the current product reference before depending on an endpoint.
Should I allow an agent to manage IAM policies?
Only with deliberate controls. IAM tools can change access policy, so use a dedicated identity, narrow permissions and human approval for changes.
