Cloud Run Admin API MCP server puts an agent in direct touch with the control plane behind Google Cloud Run, the service that runs containerized workloads without requiring a team to manage the underlying servers. Through Neotask, an agent can deploy a new service or job, configure settings like environment variables, memory limits, or scaling behavior, and inspect the revisions a service has gone through over time. It can also update an existing service, rolling out a new container image or adjusting configuration without a person stepping through the console for each change. For teams shipping containers frequently, this means routine deployment and configuration work, checking which revision is currently serving traffic, confirming a rollback happened cleanly, or adjusting a job's schedule, can be handled directly by an agent that already has the deployment instructions rather than a person repeating the same console steps release after release across dozens of services. Because Cloud Run bills for actual usage rather than idle capacity, keeping configuration tight, correct memory limits, sensible concurrency, no stray old services, is itself an ongoing task the agent can take on.
| Deploy service | Create or update a Cloud Run service using a given container image, region, and configuration. |
| List revisions | Retrieve the revision history for a service, including which one is currently active and its traffic split. |
| Update service config | Change settings like memory, concurrency, or environment variables on an existing service. |
| Create job | Set up a Cloud Run job for a task that runs to completion rather than serving requests continuously. |
| Roll back traffic | Shift traffic to a previous revision when a new deployment causes problems in production. |
| Inspect service status | Check the current health, readiness, and recent request errors of a running service. |
Right after a new revision goes out, error rates spike and the on-call engineer asks the agent to check what changed before things get worse. The agent lists the recent revisions, confirms the new one is the only difference from the previously stable configuration, and shifts traffic back to that prior revision. It then reports the rollback is complete, notes the timestamp and revision ID for the incident log, and flags the problematic revision for the engineer to investigate separately before the deploy is attempted again with a fix.
A data team wants a nightly job that processes the day's uploads, but doesn't want it running as a standing service that sits idle most of the day. The agent sets up a Cloud Run job configured with the appropriate container image, memory, and concurrency limits, tests it against a manual trigger using a sample batch of files, and confirms it completes successfully and within the expected time. Once the team is satisfied with the test run, they wire it into their nightly schedule using their own external scheduler, and ask the agent to check the job's execution history each morning for the first week to catch any silent failures early.
It deploys based on the instructions and image you give it. Whether that goes straight to production or through a staging step first depends entirely on how the surrounding workflow is set up.
No, it deploys and configures services from an existing image. Building the image is a separate step handled elsewhere in the pipeline, typically by a build system feeding a registry.
Yes, shifting traffic to a previous revision is one of its core capabilities, which makes it especially useful the moment an incident starts and speed matters.
A service handles incoming requests continuously and scales with traffic, while a job runs a task to completion and stops, and the agent can create and manage both kinds of workload.
Yes, updating concurrency and instance limits on an existing service is part of what this integration covers, so capacity can be raised without a full redeploy.
Its focus is the services, jobs, and revisions themselves. Domain and networking configuration may be reachable depending on what the admin API exposes, but it isn't the primary purpose described here.
Yes, once asked to identify services that haven't received traffic in a defined period, the agent can list them and, with approval, remove the ones that are genuinely no longer needed rather than left running indefinitely.