cloud-run-mcp: deploying apps to Cloud Run from an AI agent

What cloud-run-mcp actually removes from the workflow

Deploying to Cloud Run by hand is a short sequence: build the image, push it, run gcloud run deploy, then read logs when the revision fails. The friction is not any single command, it is that the loop lives outside the editor or chat window where you are writing the code. cloud-run-mcp puts that loop behind the Model Context Protocol, so an MCP client can call deployment tools as function calls. The README frames the goal plainly: "Enable MCP-compatible AI agents to deploy apps to Cloud Run." The audience is developers already using Gemini CLI, an AI-assisted IDE such as Cursor or Windsurf, a desktop assistant such as Claude Desktop, or an agent SDK like the Google Gen AI SDK or the Agent Development Kit. If you do not use an MCP client, this project has nothing to offer you.

The tool surface: deploy, list, inspect, read logs

The server exposes a small set of tools rather than a general gcloud passthrough. deploy-file-contents takes file contents directly and deploys them. deploy-local-folder deploys a folder from disk. list-services, get-service and get-service-log cover the read side: what exists in a project and region, what a specific service looks like, and what it logged. Two of the tools only appear when the server runs locally: deploy-local-folder, list-projects and create-project. That distinction matters, because create-project will create a GCP project and attach it to the first available billing account, optionally with a project ID you specify. A remote or hosted instance of this server does not expose that. The README also documents two prompts, deploy and logs, described as natural language shortcuts that run tool calls with pre-filled arguments. If no service name is given, they fall back to the DEFAULT_SERVICE_NAME environment variable, or to the name of the current working directory. That fallback is convenient and also the easiest way to deploy to the wrong service name by accident.

Installing cloud-run-mcp and running a first deploy

The README recommends the local Node.js setup over the Docker route for IDE and desktop use. You need the Google Cloud SDK installed and authenticated first, then application default credentials, because the server acts as you.

gcloud auth login
gcloud auth application-default login

With Node.js installed, the MCP client configuration is a single entry. The README gives this exact block for the client config file:

"cloud-run": {
  "command": "npx",
  "args": ["-y", "@google-cloud/cloud-run-mcp"]
}

Optionally you can pin defaults so the agent does not have to guess the project, region or service name:

"cloud-run": {
  "command": "npx",
  "args": ["-y", "@google-cloud/cloud-run-mcp"],
  "env": {
    "GOOGLE_CLOUD_PROJECT": "PROJECT_NAME",
    "GOOGLE_CLOUD_REGION": "PROJECT_REGION",
    "DEFAULT_SERVICE_NAME": "SERVICE_NAME"
  }
}

If you use Gemini CLI instead, the README documents installing the repository as an extension:

gemini extensions install https://github.com/GoogleCloudPlatform/cloud-run-mcp

After a client restart you should see the Cloud Run tools listed. A reasonable first call is list-projects, then list-services, to confirm the server sees the projects and services you expect before you let it deploy anything. The repository ships example-sources-to-deploy/ if you want a known payload to try against your own project.

Credentials, IAM checks and the SKIP_IAM_CHECK default

This is the part of the project that deserves the most scrutiny. The server runs on your local Google Cloud credentials, so anything the agent is asked to do happens with your permissions. There is no separate service account described in the README, and no per-user authorization model for the local setup. The environment table lists SKIP_IAM_CHECK, which controls whether the server checks IAM permissions for a Cloud Run service. It is true by default, and the README describes that as "a recommended way to make the service public." Read that carefully: the default configuration is the one that produces a publicly reachable service, and you set the variable to false to enable permission checks. If you are deploying internal services, that default is the wrong side of the switch for you, and you should set it explicitly rather than inherit it. The .env.example file shows the same server can be run as a networked HTTP service with OAuth enabled, using GOOGLE_OAUTH_CLIENT_ID, GOOGLE_OAUTH_CLIENT_SECRET and a redirect URI, with GCP_STDIO set to false and a PORT of 3000. That is a different deployment shape from the npx-in-your-client setup, and the README does not walk through it.

Host validation is off by default, and that is a real decision

The README documents ENABLE_HOST_VALIDATION as disabled by default, with the stated purpose of preventing DNS rebinding attacks by validating the Host header. When you turn it on, ALLOWED_HOSTS takes a comma-separated list, defaulting to localhost,127.0.0.1,::1. For a stdio server spawned by a local client, disabled host validation is a defensible default. For the HTTP mode implied by .env.example, where the server listens on a port and speaks OAuth, leaving Host header validation off is a choice you should make deliberately rather than by omission. The project does ship a SECURITY.md and a REVIEWING.md, so there is a documented process, but the README itself does not tell you which mode it considers production-ready.

When cloud-run-mcp is the wrong tool

The tool list is the limitation. There is no rollback tool, no traffic-splitting tool, and no way to pin a deploy to a specific revision. The README does not document rollback at all. If your release process requires progressive rollout, canary traffic or an approval step before a revision serves traffic, this server does not model any of that, and you would be bolting it on outside the agent. The read side is also narrower than Cloud Run's own surface: get-service-log returns logs and error messages, but there is no documented metric or alerting tool. And because the server acts with your credentials, an agent that misreads a service name can deploy to the wrong service; the DEFAULT_SERVICE_NAME fallback to the current working directory name makes that more likely, not less. Teams that treat deployment as a gated pipeline step rather than an interactive action should keep gcloud in CI and leave this out of the loop.

How it compares to calling gcloud directly

The honest alternative is not another MCP server, it is gcloud run deploy, which is what the project's own deploy script uses: gcloud run deploy cloud-run-mcp --source . --no-invoker-iam-check. That command is deterministic, scriptable, and reviewable in a pull request. cloud-run-mcp trades that determinism for the ability to have an agent pick arguments from context: it can look at a folder, infer what to deploy, and run the call. The trade is real in both directions. A shell script cannot decide that the failing revision needs a config change and then redeploy; an agent can, but it can also decide wrong. If your work is one-off prototypes and demos, the agent path saves typing. If your work is a service with users, the gcloud command in CI is the safer primitive, and this server is a convenience layer on top of it rather than a replacement.

Maintenance, packaging and licence

The repository is not archived, and the last push was on 2026-09-10, so it is close to current. Releases are tagged regularly: v1.8.0 in January 2026, v1.9.0 in February, v1.10.0 in March, and package.json carries version 1.10.0. The package is published as @google-cloud/cloud-run-mcp and the binary is cloud-run-mcp pointing at mcp-server.js. Upgrade cost is low in the npx setup, because the client config pins no version and npx fetches the latest each launch, which also means you get whatever was published most recently without reviewing it. If you want reproducibility, pin the version in the args array yourself. The Dockerfile builds on node:22-slim, installs production dependencies only, and exposes port 3000. The licence is Apache-2.0, which permits commercial use and modification and requires you to preserve notices and state changes; the repository also carries a SECURITY.md and CONTRIBUTING.md that govern how patches are handled. That is a description of the terms, not advice on your situation.

Editorial conclusion

Adopt cloud-run-mcp if you already deploy to Cloud Run by hand and want an MCP client to run the same steps from a prompt, and if you are comfortable giving that client your application-default credentials. Skip it if you need per-user authorization, audit trails, or deploys that must pass a review gate, because the server is built around local credentials and the README does not describe a rollback tool. Before trusting it, run list-projects and get-service from your client and confirm the project and service it reports are the ones you expect, then check whether SKIP_IAM_CHECK being true by default matches your exposure requirements.

Frequently asked questions

Official sources

1. GoogleCloudPlatform/cloud-run-mcp on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases