ScreenshotNeo

BlogAI agents

How to Use Google-Hosted MCP Servers

Connect Claude, Cursor, VS Code, or another MCP client to Google's remote servers with the right endpoint, identity, permissions, and transport.

By the ScreenshotNeo team1 October 20269 min read

Google-hosted MCP servers are remote HTTP services. To use one, choose the Google product and its current MCP endpoint, enable any required API, configure an identity, grant both MCP and resource permissions, then add the endpoint and supported authentication method to an MCP client such as Claude, VS Code, Gemini CLI, or Cursor. The exact endpoint, tools, scopes, and setup depend on the service.

This guide separates Google’s managed remote servers from local stdio servers and custom servers deployed on Cloud Run. It also shows how to discover tools over HTTP, diagnose authentication failures, and choose an operating model that fits your security and maintenance needs.

What a Google-hosted MCP server is

A Google-managed MCP server runs on Google’s infrastructure and exposes a remote MCP endpoint. Your AI application is the MCP host: it contains an MCP client that connects to the endpoint and invokes tools. The connection is normally remote HTTP or Streamable HTTP.

A local MCP server is different. It runs beside the AI application and usually communicates over standard input/output (stdio). You install and operate that process yourself. Do not paste a local command into a client field that expects a remote URL.

Model Who operates it Transport Typical setup
Google-managed server Google Remote HTTP or Streamable HTTP Enable the product, configure identity and permissions, add the endpoint to your MCP host
Local server You stdio Install a package or binary and let the host launch it
Custom Cloud Run server You or your team Streamable HTTP Deploy source to Cloud Run and configure its authentication

Setup checklist

  1. Pick the Google service and read its current MCP support page.
  2. Record the exact endpoint, supported tools, authentication methods, and required scopes or roles.
  3. Select the Google Cloud project and enable the product API if the service requires it.
  4. Choose the identity the MCP client will use: a user, application or workload identity, or agent identity.
  5. Grant roles/mcp.toolUser where Google Cloud remote MCP documentation requires it, plus the permissions needed on the underlying resources.
  6. Configure the endpoint and credentials in a compatible MCP host.
  7. Run capability discovery with tools/list (and, when supported, prompts/list and resources/list).
  8. Test one read-only operation before allowing writes or production workflows.

1. Choose the service and endpoint

Google maintains a supported-products catalog and service-specific references. The catalog is the source of truth for whether a product has a managed MCP server. Google Cloud’s examples include Google Maps, BigQuery, Google Kubernetes Engine, and Cloud Run, but that list is not a permanent or complete catalog.

One concrete endpoint is the Developer Knowledge MCP server:

https://developerknowledge.googleapis.com/mcp

It exposes a search_documents tool for finding official documentation about Google developer products. Treat each other endpoint as service-specific: never assume that a tool name, URL, or permission from one server applies to another.

2. Enable the required Google product

Choose a Google Cloud project and enable the API named by the service documentation. Google’s authentication guidance says to enable the products intended for MCP use before configuring access. In Google’s Cloud Logging codelab, for example, the project is selected and logging.googleapis.com is enabled.

# Example only: replace the service with the API required by your MCP server
gcloud services enable logging.googleapis.com --project YOUR_PROJECT_ID

Billing and a project are prerequisites for some services and guided codelabs, not a universal requirement for every MCP endpoint. Follow the target service’s current prerequisites.

3. Choose an identity and grant permissions

If the client acts with your personal identity, every call is attributed to you and inherits your permissions. That can be convenient for a private experiment, but a separate application, workload, or agent identity usually gives a clearer ownership boundary for shared or automated systems.

For Google Cloud remote MCP calls, Google’s management guidance instructs administrators to grant roles/mcp.toolUser and the permissions required by the underlying resource. The predefined role includes mcp.tools.call. Grant access at the narrowest project, folder, or resource scope that supports the task.

# Illustrative IAM command; use the principal and scope required by the service
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member='serviceAccount:YOUR_SERVICE_ACCOUNT' \
  --role='roles/mcp.toolUser'

The MCP role alone does not grant access to BigQuery datasets, Cloud Logging entries, GKE clusters, or other resources. Add the underlying service roles separately, and remove unused permissions after testing.

4. Configure authentication

Google documents three common patterns:

  • Application Default Credentials (ADC): useful when the host runs in an environment already configured with Google credentials.
  • OAuth 2.0 client ID and secret: suitable for user-authorized applications that can complete an OAuth flow.
  • Authorization header: send a bearer token, or an API key where the service explicitly supports it.

Authentication support is determined by both the server and the MCP host. Services protected by IAM do not accept ordinary API-key authentication. Some services that do not use IAM, such as Google Maps, may accept API keys. Some endpoints may require no authentication. Check the service reference and your host’s credential configuration before choosing a method.

5. Add the remote server to an MCP client

Client configuration differs, so use the host’s current syntax. The conceptual configuration is an HTTP endpoint plus the credential mechanism supported by that host:

{
  "mcpServers": {
    "google-service": {
      "url": "https://SERVICE_ENDPOINT/mcp",
      "headers": {
        "Authorization": "Bearer ${GOOGLE_ACCESS_TOKEN}"
      }
    }
  }
}

Do not commit access tokens, client secrets, or API keys to this file. Prefer the host’s secret store or environment-variable substitution. If the host only supports stdio entries, it may not support this remote server directly; use a host version with remote MCP support or the service’s documented adapter.

6. Discover tools before calling them

MCP discovery tells the host what a server can do. Servers may implement some or all of tools/list, prompts/list, and resources/list. A typical JSON-RPC request over an HTTP-capable client looks like this:

POST /mcp HTTP/1.1
Host: SERVICE_ENDPOINT
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}

For the Developer Knowledge server, discovery should reveal the documented search_documents capability when available. Read each tool’s input schema instead of guessing parameter names.

cURL discovery example

curl -sS 'https://SERVICE_ENDPOINT/mcp' \
  -H 'Authorization: Bearer ACCESS_TOKEN' \
  -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

Python discovery example

import os
import requests

endpoint = os.environ['MCP_ENDPOINT']
token = os.environ['GOOGLE_ACCESS_TOKEN']
payload = {'jsonrpc': '2.0', 'id': 1, 'method': 'tools/list', 'params': {}}
r = requests.post(endpoint, headers={'Authorization': f'Bearer {token}'}, json=payload, timeout=60)
r.raise_for_status()
print(r.json())

Node.js discovery example

const endpoint = process.env.MCP_ENDPOINT;
const token = process.env.GOOGLE_ACCESS_TOKEN;
const res = await fetch(endpoint, {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${token}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'tools/list', params: {} })
});
if (!res.ok) throw new Error(`${res.status} ${await res.text()}`);
console.log(await res.json());

7. Call a tool safely

After discovery, send the tool name and an arguments object that matches its schema. Start with a read-only call and inspect the returned content. Keep write-capable tools out of an agent’s tool list until the identity, resource scope, and approval workflow are correct.

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "TOOL_NAME_FROM_DISCOVERY",
    "arguments": {}
  }
}

Remote Google servers versus Cloud Run

Use a Google-managed endpoint when Google operates the service and its tool implementation meets your needs. Deploy a custom MCP server to Cloud Run when you need to own the server code, add your own tools, or place application logic behind a Google-hosted URL.

Cloud Run supports Streamable HTTP for hosted MCP servers and does not support stdio transport. Google’s deployment guide uses source deployment:

gcloud run deploy YOUR_SERVICE_NAME --source .

Authentication for a Cloud Run server depends on where the client runs. This is a deployment path for a server you develop or select; it is separate from Google’s already-hosted product endpoints.

Google Cloud CLI remote MCP server

Google documents a separate remote server for Cloud CLI operations. It is marked Preview and is enabled with the Cloud CLI Execution API. It supports gcloud and bq commands in a remote sandbox. Preview behavior and terms can change, so verify the current documentation before production use.

Security and governance considerations

  • Use a dedicated identity when an agent should not inherit a developer’s full access.
  • Limit both roles/mcp.toolUser and underlying resource roles.
  • Store tokens and secrets outside source control and rotate them according to your organization’s policy.
  • Review the tool list before exposing a server to an autonomous agent.
  • Google documents optional Model Armor protection. Its routing behavior in unsupported jurisdictions can affect data-residency compliance.
  • When Model Armor logging is enabled, logs can include the full payload. Confirm that payload contents are acceptable for your logging policy.

Troubleshooting

Symptom Likely cause Fix
404 or endpoint not found Wrong service URL, path, or regional endpoint Copy the endpoint from that product’s current MCP reference; do not reuse another service’s URL.
401 unauthenticated Missing, expired, or malformed credential Refresh the OAuth or ADC credential, check the Authorization header, and confirm the host supports that method.
403 permission denied Missing roles/mcp.toolUser or underlying resource permission Grant the MCP role and the least-privilege service role at the correct scope.
API not enabled The product API is disabled in the selected project Enable the API named by the service documentation and retry.
No tools appear Server or host does not support tools/list, or the request used the wrong transport Check the server capabilities and use a host that supports remote HTTP MCP.
Host tries to launch a command The client configuration is for local stdio Use the host’s remote-server configuration or an HTTP-to-stdio adapter documented by the host.
Tool call schema error Arguments were guessed or are outdated Run discovery again and send exactly the fields and types in the current input schema.
Cloud Run deployment works but client cannot connect Ingress or authentication blocks the client Check Cloud Run ingress, service identity, and the authentication method expected by the client.

Performance, reliability, and cost planning

Remote MCP adds network latency and an authentication step compared with a local process. Keep tool calls focused, cache stable discovery results where your host permits it, and set client timeouts that match the service’s documented behavior. Do not infer an availability guarantee or latency target from the fact that a server is Google-hosted; use the service’s own terms and current documentation.

Costs are service-specific. Enabling an API, running Cloud Run, executing BigQuery queries, or using another underlying product can incur charges according to that product’s pricing. The MCP protocol itself does not provide a universal price or quota.

Or skip the browser setup

If your agent needs screenshots of Google Cloud consoles, documentation pages, or any other URL, ScreenshotNeo provides a one-call website screenshot API and an MCP server. Cookie and consent banners, newsletter popups, and chat widgets are removed before the shot. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and the response identifies the result with X-Page-Verdict and X-Billed headers. AI agents can use the take_screenshot, get_page_info, and capture_pdf tools through MCP.

See the ScreenshotNeo API documentation for all options. cURL:

curl -G 'https://api.screenshotneo.com/v1/shot' -d access_key=YOUR_API_KEY --data-urlencode url=https://cloud.google.com -o shot.webp

Python:

import requests
r = requests.get('https://api.screenshotneo.com/v1/shot', params={'access_key': 'YOUR_API_KEY', 'url': 'https://cloud.google.com'}, timeout=90)
open('shot.webp', 'wb').write(r.content)

Node.js:

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://cloud.google.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo includes full-page and element capture, device presets, custom headers and cookies, waits, blocking rules, custom JavaScript and CSS, PDFs, caching, signed links, async jobs, bulk capture, and a usage API. Every feature is on every plan. The Free plan includes 1,000 shots each month with no card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.

FAQ

Do I need an MCP server running locally?

No. A Google-hosted server is remote. You need an MCP-capable client that can connect over HTTP or Streamable HTTP.

Can one Google identity access every MCP server?

No. Each server and underlying product defines its own authentication and permissions.

Is roles/mcp.toolUser enough?

No. It authorizes MCP tool calling; you also need permissions on the resources the tool operates on.

When should I deploy to Cloud Run?

Use Cloud Run for a custom server you operate. It is not required for Google’s managed service endpoints.

Are all Google MCP services generally available?

No. Availability and launch stage vary. The Cloud CLI remote MCP server is documented as Preview, and service catalogs can change.