Google Is Turning gcloud Into an API for AI Agents

Granola for face-to-face conversations. Now on Apple Watch.

Some important conversations happen away from your laptop. Start a Granola note from your wrist, stay present, and finish with the context you need.

Start a note from your wrist. Keep eye contact. Leave with notes.

Free 1 month with the code SCOOP

Try Granola Today

Google Cloud has introduced the Google Cloud CLI remote MCP server, currently in public preview. At first glance, it sounds like another MCP integration. It is more consequential than that.

Instead of building a separate collection of carefully defined tools for Compute Engine, networking, logging, IAM, BigQuery administration, and dozens of other services, Google is exposing much of the existing gcloud and bq command-line surface through just two MCP tools: run_gcloud_command and run_bq_command. The commands execute inside a Google-managed, network-isolated environment rather than inside the agent’s own container or laptop.

The architectural shift is essentially:

Natural language → agent reasoning → MCP → Google Cloud CLI → Google Cloud APIs

That gives agents something unusually powerful: a mature operational interface that humans have already used for years to provision infrastructure, inspect logs, manipulate networking, operate BigQuery, diagnose incidents, and perform administrative work.

And that may be more important than giving an agent hundreds of individually designed API tools.

The interesting idea isn’t MCP. It’s using the CLI as the agent abstraction

Most agent integrations today follow roughly this model:

Agent
  │
  ├── create_vm()
  ├── list_instances()
  ├── get_logs()
  ├── update_firewall()
  └── restart_service()
        │
        ▼
   Cloud APIs

Every capability needs to be exposed as a tool with its own schema.

Google’s new architecture looks more like this:

Agent
  │
  ▼
run_gcloud_command
  │
  ▼
gcloud compute ...
gcloud logging ...
gcloud run ...
gcloud container ...
gcloud projects ...
...
  │
  ▼
Google Cloud APIs

Google specifically argues that CLI commands are useful agent abstractions because commands already encode higher-level workflows, validation logic, and operations that otherwise might require several API interactions. Google also points out that language models have seen large quantities of public CLI documentation and examples during training, making command syntax something models tend to understand relatively well.

That second point is easy to underestimate.

An API may require an agent to learn an exact JSON schema:

createNetwork({
  project: "...",
  routingMode: "...",
  subnetMode: "...",
  ...
})

But models have likely encountered thousands of examples resembling:

gcloud compute networks create my-network \
  --subnet-mode=auto \
  --project=my-project

Instead of inventing an agent-native cloud interface, Google is effectively saying:

The interface AI already understands may be the interface cloud engineers already use.

Why moving gcloud off the agent machine matters

Until now, giving an agent CLI access usually meant installing the Cloud SDK wherever the agent ran.

That architecture looks something like:

┌───────────────────────────┐
│ Agent execution container │