cloud-run-mcp: An MCP Server That Puts Cloud Run Deploys Inside Your AI Agent

The Gap cloud-run-mcp Fills Between an AI Client and Cloud Run

An AI coding agent can write a container-ready app and still stall at the last step, because publishing it requires a shell, a gcloud session, and a project choice. cloud-run-mcp closes that gap by exposing deployment as MCP tools the agent can call directly. The README frames the goal plainly: "Enable MCP-compatible AI agents to deploy apps to Cloud Run." The intended users are developers working inside AI-assisted IDEs such as Cursor, desktop assistants such as Claude, CLI agents such as Gemini CLI, and agent SDKs including the Google Gen AI SDK and the Agent Development Kit. The project is JavaScript, licensed Apache-2.0, and published as @google-cloud/cloud-run-mcp on npm. It is not a hosting product. The README draws that line itself, pointing readers who want to host MCP servers on Cloud Run to separate Cloud Run documentation. This repository is the client-side bridge, nothing more.

Seven Tools, and Two Deployment Paths That Behave Differently

The server exposes a small tool surface. Four tools work in any deployment: deploy-file-contents, which takes file contents directly rather than a path; list-services; get-service; and get-service-log, which returns logs and error messages for a named service. Three more are marked in the README as available only when running locally: deploy-local-folder, list-projects, and create-project. That split is the most consequential design detail in the project. A remote or containerized instance of the server can push file contents but cannot read your disk or enumerate your projects, so the folder-based workflow that most developers actually want depends on running the server on the same machine as the code. create-project is narrower than it sounds: it creates a project and attaches it to the first available billing account, with an optional project ID. There is no way to select a billing account. On top of the tools sit two prompts, deploy and logs, described as shortcuts that pre-fill arguments. Both fall back to the DEFAULT_SERVICE_NAME environment variable, and if that is unset, to the name of the current working directory. That fallback is convenient and slightly risky, since a directory named after an existing production service would target it.

Credentials Come From gcloud, Not From the Server

There is no credential store here. The server relies on Google Cloud credentials already present on the machine. The README's setup path is two commands: gcloud auth login, then gcloud auth application-default login. The second is the one that matters, because Application Default Credentials are what the server's underlying calls consume. This has two practical consequences. First, the server inherits whatever project and account your ADC is pointed at, so a stale ADC from another engagement will deploy to the wrong place with no prompt. Second, team members cannot share a single authenticated server instance in any meaningful way, because the identity is per-machine. The Gemini CLI extension route keeps the same requirement: install with gemini extensions install followed by the repository URL, then run both auth commands. The README recommends the local Node.js setup over other options, which is consistent with the local-only tool split described above.

Configuration Keys and the Defaults Worth Changing

Five environment variables control behavior. GOOGLE_CLOUD_PROJECT and GOOGLE_CLOUD_REGION set the default project and region. DEFAULT_SERVICE_NAME names the service used by the deploy and logs prompts. SKIP_IAM_CHECK is the one to read carefully. The README states it "Controls whether to check for IAM permissions for a Cloud Run service," that setting it to false enables checks, and that it is true by default, described as "a recommended way to make the service public." In other words, out of the box the server skips the IAM check and deploys services publicly. That is a defensible default for demos and a poor one for anything internal, and the README does not present it as a decision point. ENABLE_HOST_VALIDATION is disabled by default and, when enabled, guards against DNS rebinding by validating the Host header. ALLOWED_HOSTS takes a comma-separated list for that validation and defaults to localhost,127.0.0.1,::1. A minimal client entry is the JSON block the README gives: an mcpServers object whose cloud-run entry runs npx with args ["-y", "@google-cloud/cloud-run-mcp"], with optional env keys for the three defaults. Docker is offered as an alternative, with the README pointing at Docker's MCP catalog.

Where This Server Is the Wrong Tool

The tool list defines the ceiling. There is no rollback, no traffic splitting, no revision pinning, no domain mapping, no secret or environment variable management, and no IAM policy editing beyond the check that SKIP_IAM_CHECK toggles. If your release process depends on shifting traffic gradually between revisions, this server cannot express it. The deploy-file-contents path also means the agent is transmitting file contents through the MCP channel rather than pointing at a build context, which suits small apps and gets awkward as a project grows. Host validation being off by default is a real exposure for anyone running the server as a networked service rather than a local stdio process, and the README does not explain when that matters. Finally, create-project attaching to the first available billing account is a blunt instrument in any organization with more than one billing account; a mis-targeted project creation is not something the tool set can undo.

How It Compares With Just Calling gcloud

The obvious alternative is gcloud run deploy, invoked by the agent or by a human. The difference is not capability, since the MCP server is a wrapper around the same Cloud Run surface, but interface shape. gcloud gives you the full flag set: traffic allocation, revision suffixes, service accounts, VPC connectors, and every other deploy option. cloud-run-mcp gives an agent a narrow, typed set of calls with defaults baked in, which reduces the chance of a malformed command and raises the chance of an unintended default. A second alternative is a CI pipeline that builds and deploys on merge. That approach is reproducible and auditable, and it is the right answer when a deploy must be traceable to a commit. cloud-run-mcp sits between the two: more structure than raw gcloud, far less than a pipeline. The prompts, deploy and logs, are the clearest expression of its intent. They target the repetitive case, not the release-engineering case.

Maintenance Cost and Licence Terms

The project ships frequently. Releases v1.8.0, v1.9.0, and v1.10.0 landed between late January and early March 2026, and the last push to main is dated 2026-09-10, so the codebase is active. Running via npx with the -y flag, as the README shows, means you always fetch the latest published version, which keeps you current and also means an upstream change can alter agent behavior between sessions. Pinning a version in your MCP client config is the way to avoid that, and the README does not discuss it. The Apache-2.0 license permits commercial and private use with the usual notice and patent terms; the repository does not include a separate NOTICE file in the material reviewed here, so check the repository itself if your process requires one. Nothing in the README addresses upgrade migrations, which is unsurprising for a tool this thin but worth noting if you build prompts around specific tool names.

Editorial conclusion

Adopt cloud-run-mcp if your team already authenticates with gcloud and wants an AI client to handle routine Cloud Run deploys, especially for demos and internal services. Skip it if you need reproducible, version-controlled deploy pipelines, because the tool set has no rollback, no traffic splitting, and no revision pinning. Before first use, confirm your Application Default Credentials point at the intended project and decide explicitly whether SKIP_IAM_CHECK should stay at its default of true, since that default makes deployed services public.

Official sources

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