The Google Cloud MCP server gives an agent read and management access to GCP resources: projects, IAM policies, compute instances and the surrounding configuration. It is aimed at the questions that are annoying to answer through the console, particularly anything that spans more than one project.
What it actually does
The server authenticates through OAuth and wraps GCP APIs as tools. Claude can enumerate projects, read IAM bindings, look at compute resources and inspect configuration. The strongest use is interrogation rather than change: asking who has access to what, or which resources are running where, and getting an answer assembled from the actual API rather than from memory.
Practical patterns:
- ‘Who has edit access to this project, and through which groups?’
- ‘List every compute instance across my projects and flag the ones with public IPs.’
- ‘What changed in the IAM policy on this bucket?‘
Why use it
IAM is the canonical example of something humans are bad at auditing. Permissions arrive through nested groups and inherited roles, and the effective answer to “can this person read that bucket” takes real work to derive. Something that can query the policy directly and explain it in a sentence is genuinely useful, and it is the kind of task where an agent’s patience beats yours.
Gotchas
OAuth means the server inherits your account’s reach, which for an administrator is everything. A dedicated service account with a viewer role is a much better starting point than your own credentials. The server is community-maintained rather than official, and Google’s first-party MCP support has been changing, so verify coverage before depending on it. As with AWS, start read-only and add write access only for a specific job.
