Cloud Run托管MCP上线：运维和AI终于能对话了

「这是第一个真正打通两个世界的东西。」Google Cloud工程师在NEXT '26现场这样评价新发布的托管MCP服务。当260多项公告淹没Gemini 3.1和TPU v8的头条时，Cloud Run角落里这个quietly GA的功能，可能正在改写基础设施管理的工作流。

对同时管机器又玩AI的人来说，这解决了个真实痛点：一边是SSH进虚拟机、凌晨两点盯报警的传统运维，一边是搭工具链、调上下文窗口的AI工程。两边工具链完全不互通，每次让AI做点基础设施操作都得手写API客户端。

现在，Cloud Run托管的MCP（模型上下文协议）服务器让AI代理直接获得部署服务、读日志、查健康度的能力——像个永不疲倦的初级SRE。

我们要搭什么

这篇实战指南会带你走完完整链路：

• 把内置Cloud Run MCP服务器接进Gemini CLI，用自然语言管部署

• 在Cloud Run上跑自定义MCP服务器，暴露基础设施健康检查工具

• 用ADK代理把两者结合，实现「过去一小时哪些服务报错」这类智能问答

开始前确认环境：Google Cloud项目已开计费、gcloud CLI已登录、Python 3.10+、Docker、Gemini CLI。前置设置好PROJECT_ID和REGION，后面命令直接复制可用。

IAM权限需要三个角色：run.admin、iam.serviceAccountUser、artifactregistry.writer。

第一阶段：开箱即用的托管MCP

Google在 https://run.googleapis.com/mcp 托管了完全托管的MCP服务器，零配置。暴露的工具包括list_services、get_service、deploy_service_from_image、deploy_service_from_archive。

认证走Google Cloud身份体系。先确保ADC（应用默认凭证）就位：

gcloud auth application-default login

然后配置Gemini CLI。打开或创建 ~/.gemini/settings.json，填入：

{
"mcpServers": {
"cloud-run": {
"url": "https://run.googleapis.com/mcp",
"transport": "http"
}
}
}

启动gemini，直接对话基础设施：

> List all my Cloud Run services in us-central1

底层自动调用list_services，返回服务列表、URL、状态——告别gcloud run services list --region us-central1 --format=json | jq...的管道体操。

更激进一点：

> Deploy the image us-docker.pkg.dev/cloudrun/container/hello to a new service called "hello-from-agent" in us-central1

代理会自动调用deploy_service_from_image完成部署。自然语言直接转化为基础设施变更，中间没有胶水代码。

第二阶段：自定义MCP服务器上云

内置工具覆盖标准CRUD，但真实场景需要定制——比如查询特定指标、执行健康检查、对接内部系统。这时要把自定义MCP服务器部署到Cloud Run。

设计思路：MCP服务器本质是暴露一组tools的HTTP服务，每个tool是带schema的函数。Cloud Run托管后，AI代理通过标准MCP协议远程调用。

项目结构示例：

infrastructure-agent/
├── server.py # FastMCP服务入口
├── tools/
│ ├── health.py # 健康检查工具
│ └── metrics.py # 指标查询工具
├── requirements.txt
└── Dockerfile

server.py核心逻辑：初始化FastMCP实例，注册tools目录下的函数，启动HTTP服务。Cloud Run要求监听8080端口，所以绑定host="0.0.0.0", port=8080。

health.py示例工具：check_service_health接收service_name和region参数，调用Cloud Monitoring API拉取error_count指标，返回健康状态。metrics.py同理封装list_recent_errors，支持按时间窗口过滤。

部署到Cloud Run的标准流程：gcloud builds submit打包镜像，gcloud run deploy指定服务名、镜像、允许未认证调用（因为MCP协议自带认证）。注意设置--no-cpu-throttling保持服务器常驻，避免冷启动延迟影响代理体验。

部署完成后拿到服务URL，这就是自定义MCP服务器的端点。

第三阶段：ADK代理整合双源

现在有两个MCP源：Google托管的标准操作端点，以及你自己的定制工具端点。ADK（Agent Development Kit）代理可以同时连接两者，做智能编排。

代理配置结构：在agent.py中定义两个MCP工具集，分别指向两个URL。系统提示词明确分工——标准端点负责部署和列表查询，定制端点负责健康诊断和错误分析。

关键代码模式：用adk.Tool定义工具集，通过mcp_session建立连接。代理的推理循环会自动选择合适工具，用户只需用自然语言提问。

实战对话示例：

> 我us-central1区域过去一小时哪些服务报错了？

代理调用定制端点的list_recent_errors工具，返回错误服务列表。继续追问：

> 把出问题的服务重启一下

代理切换到标准端点，调用get_service确认状态，再调用deploy_service_from_image执行滚动更新。全程无需人工指定用哪个API。

架构取舍与边界

托管MCP不是万能药。当前版本有明确边界：只支持Cloud Run生态，无法直接操作GCE或GKE；工具调用是同步阻塞的，长耗时操作会占用代理上下文窗口；认证依赖Google Cloud IAM，跨云场景需要额外代理层。

但相比自己维护API客户端和凭证轮转，这已经把基础设施即代码的门槛降到自然语言级别。对于内部平台团队，可以把定制MCP服务器作为「基础设施DSL」——用Python定义领域专属操作，暴露给全公司的AI助手。

下一步

Google路线图显示Q3将支持MCP服务器自动扩缩容和跨项目访问。现在就可以开始：把重复性运维操作封装成MCP工具，让AI代理接管值班第一响应。

代码已整理至GitHub，包含完整server.py、agent.py和部署脚本。从gcloud auth login到自然语言管基础设施，大约15分钟。