Give your coding agent a local cloud environment with MCP

LocalCloud gives AI coding agents a free cloud dev. environment for building, testing, and debugging Google Cloud applications. It provides MCP server for agent to connects for service discovery, SDK configuration, resource inspection, supported feature, readiness, and diagnostics, etc...

I'm sharing a practical setup and three small integration tests you can run locally. The application uses standard Google Cloud SDKs pointed at the discovered local endpoints.

Website · MCP setup guide · Source and releases

Install and connect your agent

Install LocalCloud CLI 0.1.9 or newer, keep Docker running.

On macOS, or Linux with Homebrew:

brew install LocalGCloud/tap/localcloud
lc --version
lc doctor
lc mcp install --client cursor

Reload Cursor and enable the localcloud MCP server. The bridge starts or reuses your local runtime. Its first connection can take longer while Docker downloads the image.

For an existing Homebrew installation, run brew update and brew upgrade localcloud. CLI and runtime versions are independent; an existing older runtime needs an explicit upgrade using the same data volume/configuration. The guide explains that process, the website installer, and setup for Claude Code/Desktop, Codex, VS Code, Cline, Gemini CLI, Antigravity, and Windsurf.

Give the agent an observable task

Try this prompt:

Use LocalCloud MCP to list local services, check readiness, and obtain SDK settings. Check compatibility before writing a small Cloud Storage, Pub/Sub, and BigQuery integration test. Use only the returned local endpoints and uniquely named test resources. Assert the actual results and clean up only resources created by this test. Stop if a required operation is unavailable; do not fall back to real Google Cloud.

The initial calls are localcloud_list_services, localcloud_check_readiness, and localcloud_get_env with {"format":"json"}. Returned SDK settings account for the runtime's actual port mappings.

Three workflows with real assertions

Cloud Storage: create a uniquely named bucket, upload a known string, download it, and assert an exact content match. Remove that test bucket in cleanup.

Pub/Sub: create a topic and subscription, publish a known message, pull it, check the exact bytes, and acknowledge it. Delete only that test's subscription and topic, including when an assertion fails.

BigQuery: run SELECT 1 AS mcp_smoke, then check that it returns exactly one row with value 1. The runnable example checks this through both localcloud_query_data and the standard BigQuery SDK.

These tests exercise application behavior as well as the MCP connection.

Run the complete example

Start an independent runtime for the three services. Dynamic ports let it run beside an everyday environment:

lc start --image agentcloud/localcloud:0.1.5 \
  --data-volume localcloud-mcp-demo \
  --services gcs,pubsub,bigquery --local-only --accept-dynamic-ports

Run the example from the public repository with its optional SDK dependencies using uv:

git clone https://github.com/LocalGCloud/localcloud-cli.git
cd localcloud-cli
uv run --with mcp==2.0.0 --with google-cloud-storage \
  --with google-cloud-pubsub --with google-cloud-bigquery \
  examples/mcp_workflows.py --data-volume localcloud-mcp-demo

The script obtains SDK settings through MCP, rejects non-loopback hosts, supplies anonymous local credentials, and removes its own bucket/topic/subscription. Its observed output was:

PASS MCP: localcloud_list_services
PASS MCP: localcloud_check_readiness
PASS MCP: localcloud_check_compatibility
PASS MCP: localcloud_get_diagnostics
PASS MCP: SDK configuration validates against its output schema
PASS MCP: BigQuery query returns the expected row
PASS Cloud Storage: upload and read back the exact content
PASS Pub/Sub: publish, pull, verify, and acknowledge
PASS BigQuery: SELECT 1 returns the expected row
Cleanup complete: only uniquely named example resources were removed

When finished, stop the example runtime:

lc stop --data-volume localcloud-mcp-demo

The named volume remains available for reuse.

Inspect a failure before changing the test

Ask the agent to check readiness, diagnostics, and recent requests, then rerun the failing assertion. A service can be present in the catalog while disabled in the running environment, so check current readiness and compatibility.

The default data volume is shared. Use test-owned resources and explicit cleanup; choose a separate named volume for an independent runtime. MCP management writes and destructive actions require explicit runtime settings. SDK operations can change local application data.

The example passed against the exact Linux ARM64 release image and the AMD64 image under emulation, through the published macOS ARM64 CLI. Google Cloud production validation and native hardware verification on every platform remain separate.

LocalCloud MCP is also active in the official MCP Registry, with a native desktop bundle.

Website · MCP guide · Original walkthrough and recorded demo