gcloud Skill 中的 Cloud CLI 远程 MCP Serverrun_gcloud_command 工具实战详解google-cloud-developer 插件【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills在google-cloud-developer插件的 gcloud Skill 中AI Agent 与 Google Cloud 的交互存在两种模式直接在本地 shell 中执行gcloud命令以及通过 Model Context ProtocolMCP调用结构化工具。本文聚焦后者——基于 mcp-usage.md 参考文档系统讲解 Cloud CLI 远程 MCP Server 的接入配置、IAM 权限要求、run_gcloud_command工具的参数语义尤其是 API 宿主项目与资源项目分离这一关键设计、响应结构解读以及沙箱环境下受支持/受禁止的 gcloud 命令范围。读完后你可以让任何兼容 MCP 的 Agent 客户端在无需本地gcloud安装、无需本地凭据落盘的前提下安全地以用户身份执行 gcloud 命令并正确判断命令执行结果。1. Cloud CLI 远程 MCP Server 是什么传统做法是让 Agent 在本地终端直接执行gcloud命令而远程 MCP 模式下gcloud 的执行被移到一个受管的远程沙箱环境中Agent 只需通过结构化工具调用structured tool calls下发命令。根据 SKILL.md 中 Execution Modes 一节的描述这两种方式是 Agent 操作 GCP 的主要途径MCP 方式的核心就是调用 Cloud CLI 远程 MCP Server 暴露的run_gcloud_command工具。该远程服务的关键事实如下来自 mcp-usage.md属性值Server Endpointhttps://cloudcli.googleapis.com/mcpTransportHTTPJSON-RPC 2.0底层 APICloud CLI Execution APIcloudcli.googleapis.com可用工具run_gcloud_command仅此一个run_gcloud_command的语义是在受管的远程环境中代表用户安全地执行单条 gcloud 命令。单条这一点与 SKILL.md 中 Execution Constraints 的约束相互印证——禁止命令链chaining、禁止 shell 管道与重定向、禁止命令替换每次只执行一条可被用户审阅的命令。值得注意的是当前插件自带的 mcp_config.json 中仅注册了developer-knowledge这一台远程 MCP ServerDeveloper Knowledge 服务器供 retrieving-developer-knowledge Skill 使用而gcloud-remote的cloudcli.googleapis.com/mcp条目是面向接入方 MCP 客户端文档以 Jetski 为例的配置范例——也就是说把 gcloud 能力接入你的 Agent 客户端时需要按下文第 2 节的方式自行添加该条目。2. 客户端接入mcp_config.json 配置与 google_credentials 认证要让 MCP 客户端连上远程 Cloud CLI MCP Server需要在客户端的mcp_config.json中添加如下服务条目{ mcpServers: { gcloud-remote: { serverUrl: https://cloudcli.googleapis.com/mcp, authProviderType: google_credentials } } }其中authProviderType: google_credentials是强制字段其含义是指示 MCP 客户端在请求上附加 Application Default CredentialsADC并使用https://www.googleapis.com/auth/cloud-platformOAuth scope。如果省略该字段客户端将发送未认证请求直接得到401 Unauthorized错误。这一配置模式并非孤例。从当前仓库的插件元数据看gemini-extension.json 对 Developer Knowledge MCP Server 的注册同样显式写明了authProviderType: google_credentialsmcpServers: { developer-knowledge: { httpUrl: https://developerknowledge.googleapis.com/mcp, authProviderType: google_credentials } }从源码结构看这是整个google-cloud-developer插件对Google 官方远程 MCP Server的统一认证约定凡是*.googleapis.com/mcp端点都依赖客户端侧的 ADC 完成 OAuth 授权而不是在请求体中传递任何长期凭据。3. 前置条件API 启用与双重 IAM 权限在使用 Cloud CLI 远程 MCP Server 前目标项目与调用身份必须同时满足两个硬性前置条件。缺任何一项端点在工具发现tools/list和工具调用tools/call两个阶段都会返回403 Forbidden——这比401更隐蔽因为它发生在身份认证已通过之后容易让排错方向跑偏。3.1 前置条件一启用 Cloud CLI Execution APIcloudcli.googleapis.com必须在承载该 API 的项目上启用两种方式任选其一通过 Google Cloud Console进入APIs Services→Library搜索Cloud CLI Execution API在右上角项目选择器中选中目标项目后点击Enable。通过gcloudCLIgcloud services enable cloudcli.googleapis.com --project{project_id}这里{project_id}是API 宿主项目后文project参数所指与被查询/修改的资源所在项目可以不同。3.2 前置条件二两层角色要求调用身份需要持有两类权限缺一不可MCP Access Role工具层调用身份必须在目标项目上拥有MCP Tool User角色即roles/mcp.toolUser。该角色授予mcp.tools.call权限是调用任何远程 MCP 工具的前提。Downstream Resource Roles资源层调用身份还必须对命令实际查询/修改的底层资源持有标准 IAM 权限例如只读查询 Compute 资源需要roles/compute.viewer部署 Cloud Run 服务需要roles/run.developer。这一双角色设计意味着即便你有roles/mcp.toolUser也只能合法地调用工具能否看到/改动具体资源仍由资源层 IAM 决定——与本地直接执行gcloud时的鉴权行为保持一致远程化没有放大权限面。4. run_gcloud_command 工具参数详解对run_gcloud_command的调用接受三个参数参数类型必填说明commandstring是要执行的完整gcloud命令行字符串例如gcloud compute instances list --project{resource_project} --formatjsonprojectstring是承载 Cloud CLI Execution API 的项目资源名格式为projects/{api_project}例如projects/my-api-projectinput_fileslist of objects否在远程执行环境中运行命令前先预置的文件。每项包含相对path和字符串contents4.1 核心规则API 宿主项目 ≠ 资源项目这是整个工具参数设计中最容易出错的一点文档用 IMPORTANT 级别专门强调顶层project参数projects/{api_project}严格只用于cloudcli.googleapis.comAPI 本身的配额quota、计费billing与 API 启用判断它不会成为被执行命令的项目上下文。对于项目作用域命令必须在command字符串中显式携带--project{resource_project}且{resource_project}不必等于承载 Cloud CLI Execution API 的项目。对于非项目作用域命令如 billing、organization 类查询若底层 API 需要配额项目则必须在command字符串中携带--billing-project{billing_project}。这一设计与 SKILL.md Project and Location Scoping (Critical) 一节的原则完全对齐不要依赖任何隐式默认项目所有资源操作与查询命令都要显式指定--project以保证命令是确定性的、非交互式的、指向正确环境的。在本地 CLI 模式下Agent 依赖本地gcloud config的默认项目上下文而远程 MCP 模式下没有任何本地配置可言因此显式--project从最佳实践升级为唯一途径。4.2 示例一基本命令执行{ command: gcloud compute instances list --projectmy-resource-project --formatjson, project: projects/my-cloudcli-api-project }注意两个项目 ID 不同my-cloudcli-api-project承载 Cloud CLI Execution API负责配额与计费而命令实际查询的是my-resource-project中的 VM 实例。同时命令自带--formatjson符合数据缩减约束。4.3 示例二携带输入文件执行input_files参数解决了一个沙箱环境的经典痛点远程执行环境里并没有你本地的文件。例如要执行gcloud run services replace service-config.yaml可以先把 YAML 内容通过工具参数投递进远程环境{ command: gcloud run services replace service-config.yaml --regionus-central1 --projectmy-resource-project, project: projects/my-cloudcli-api-project, input_files: [ { path: service-config.yaml, contents: apiVersion: serving.knative.dev/v1\nkind: Service\nmetadata:\n name: my-service\n... } ] }执行引擎会先按input_files中声明的相对path将文件内容物化到远程工作目录再运行command。这让部署配置文件这类原本依赖本地文件系统的操作在纯远程、无 TTY 的 MCP 会话中成为可能。5. 响应结构与 exit_code 权威性工具返回一个执行响应对象包含四个字段exit_code命令执行的数字退出状态。这是判断命令成功/失败的首要且权威指标。stdout标准输出流。stderr标准错误流。output_files命令生成的任何输出文件。对 Agent 而言响应解读有三条硬性规则Exit Code Authority当且仅当exit_code 0时命令才算成功非零即失败。不要以输出看起来正常替代退出码判断。stderr 可能是纯信息性输出在gcloud中stderr经常承载标准状态消息、进度更新和异步跟踪 ID例如--async产生的操作 ID即使命令成功exit_code 0也可能非空。Agent 绝不能仅因stderr非空就判定命令失败——这是 Agent 集成中最常见的误判来源。失败诊断要双向检查当exit_code ! 0时诊断性错误信息可能出现在stderr也可能出现在stdout必须两个流都检查后才能理解失败原因并制定修正方案。这一规则与本地 CLI 模式下的调试经验一致但更值得强调MCP 场景下 Agent 是自动化的第一读者把stderr 非空 失败当作假设的 Agent会陷入假失败 → 重试 → 资源被重复创建的恶性循环。6. 沙箱环境受禁止与不受支持的命令清单Cloud CLI 远程 MCP Server 运行在一个沙箱化、非交互式的环境中。文档列出了部分不受支持的gcloud命令清单非穷尽且可能随时增删它们的共同特征是依赖本地机器状态命令禁止原因gcloud auth本地认证与凭据管理gcloud config本地 CLI 配置档案与属性gcloud iam service-accounts服务账号管理本地凭据上下文gcloud init交互式初始化向导gcloud survey用户反馈与问卷gcloud compute ssh/gcloud app instances ssh交互式 SSH shell可以推断判定逻辑围绕命令是否需要本地凭据库、本地配置文件、TTY 或交互式会话展开凡触碰 Agent 所在机器本地状态的命令组都被排除在远程执行之外。这也解释了第 4.1 节没有隐式默认项目的原因——远程环境里根本不存在gcloud config可依赖。此外SKILL.md 还维护了一份语义层面的Prohibited Operations拒绝清单IAM 策略变更、gcloud * delete、gcloud billing *、gcloud organizations *、gcloud kms *、gcloud infra-manager deployments apply等要求这些操作必须经过人工显式授权。两份清单互补前者界定技术上不支持执行后者界定技术上可执行但策略上禁止自主执行。7. 安全与执行准则Safety Execution Guidelines文档在结尾给出了四条面向 Agent 的安全准则它们同样是把本地 headless 执行 gcloud的经验映射到 MCP 场景变更类命令必须用户显式同意create、delete、update、patch等破坏性或状态变更命令在用户未明确授权前Agent 不得自主调用。这与 SKILL.md 的 CAUTION 级约束destructive actions MUST be explicitly authorized一致。长操作使用--async对耗时操作创建 VM 实例、GKE 集群、数据库实例等在command中追加--async以避免执行超时操作 ID 会出现在响应中按第 5 节规则通常位于stderr可用gcloud operations describe OPERATION_ID轮询状态。数据缩减防上下文膨胀在command中使用--formatjson、--filter、--limit约束输出量防止撑爆 LLM 上下文窗口。SKILL.md 将其升级为强制项任何list命令至少携带一个数据缩减标志且推荐用gcloud GROUP RESOURCE list --limit1 --formatjson先探测 schema 再构造投影。非交互式执行--quiet/-q对可能触发交互确认的命令一律携带--quiet。远程沙箱没有 TTY 与 stdin 处理器缺少该标志的命令会无限期挂起等待输入最终导致后台任务超时。8. 与插件其他部件的协作关系把本文内容放回google-cloud-developer插件见 plugin.json的整体语境中Cloud CLI 远程 MCP Server 只是安全执行这一大目标的一条腿gcloud Skill 本体SKILL.md负责命令怎么拼才对强制gcloud help leaf_command叶子级语法校验、禁止把父命令组 help 当作叶子命令的验证依据、禁止用网络搜索替代gcloud help。CLI 参考文档cli-usage.md负责本地模式怎么装、怎么认证、怎么管理配置档案其认证的 ADC / 服务账号密钥 / 身份模拟impersonation等流程正是远程 MCP 模式下客户端 ADC 授权的本地对应物。本文的 MCP 参考文档负责远程模式怎么连、怎么传参、怎么判成败。插件级的 rules/google-cloud-discovery.md 则说明本插件只安装了 Google Cloud 技能目录的一个小子集mcp-usage.md正是随 gcloud Skill 一起分发的深度参考。因此一个完整的远程 MCP 工作流是Agent 先用gcloud help本地或文档检索验证叶子命令语法 → 按第 4 节规则组装command/project/input_files参数 → 通过run_gcloud_command下发 → 按第 5 节规则以exit_code判定成败、双向检查输出流 → 对变更类操作确保已获得用户授权。9. 速查表事项要点端点https://cloudcli.googleapis.com/mcpHTTPJSON-RPC 2.0客户端配置mcpServers条目须带authProviderType: google_credentials否则401API 启用在 API 宿主项目启用cloudcli.googleapis.comConsole 或gcloud services enable权限调用身份需roles/mcp.toolUser 资源层角色如roles/compute.viewer缺一即403project参数仅用于 API 配额/计费格式projects/{api_project}项目上下文必须写在command内的--project{resource_project}非项目作用域命令需要时写--billing-project{billing_project}预置文件input_files: [{path, contents}]成败判定只看exit_code 0stderr非空不代表失败失败诊断stdout与stderr都查禁用命令auth/config/iam service-accounts/init/survey/交互 SSH 等本地状态类命令变更操作必须用户显式授权长操作加--asynclist必须带--limit/--filter/--format执行命令带--quiet以上所有配置、参数与规则均源自当前仓库 mcp-usage.md 文档原文认证模式与执行约束可对照 gemini-extension.json、SKILL.md 与 cli-usage.md 交叉验证。需要提醒的是受支持命令清单是动态的non-exhaustive and subject to the addition or removal of commands without notice在接入新的 gcloud 命令组前建议先以只读list类命令做一次端到端探测。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/14 7:35:03 · 阅读 1.2k gcloud Skill 中的 Cloud CLI 远程 MCP Server：run_gcloud_command 工具实战详解（google-cloud-developer 插件）
gcloud Skill 中的 Cloud CLI 远程 MCP Serverrun_gcloud_command 工具实战详解google-cloud-developer 插件【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills在google-cloud-developer插件的 gcloud Skill 中AI Agent 与 Google Cloud 的交互存在两种模式直接在本地 shell 中执行gcloud命令以及通过 Model Context ProtocolMCP调用结构化工具。本文聚焦后者——基于 mcp-usage.md 参考文档系统讲解 Cloud CLI 远程 MCP Server 的接入配置、IAM 权限要求、run_gcloud_command工具的参数语义尤其是 API 宿主项目与资源项目分离这一关键设计、响应结构解读以及沙箱环境下受支持/受禁止的 gcloud 命令范围。读完后你可以让任何兼容 MCP 的 Agent 客户端在无需本地gcloud安装、无需本地凭据落盘的前提下安全地以用户身份执行 gcloud 命令并正确判断命令执行结果。1. Cloud CLI 远程 MCP Server 是什么传统做法是让 Agent 在本地终端直接执行gcloud命令而远程 MCP 模式下gcloud 的执行被移到一个受管的远程沙箱环境中Agent 只需通过结构化工具调用structured tool calls下发命令。根据 SKILL.md 中 Execution Modes 一节的描述这两种方式是 Agent 操作 GCP 的主要途径MCP 方式的核心就是调用 Cloud CLI 远程 MCP Server 暴露的run_gcloud_command工具。该远程服务的关键事实如下来自 mcp-usage.md属性值Server Endpointhttps://cloudcli.googleapis.com/mcpTransportHTTPJSON-RPC 2.0底层 APICloud CLI Execution APIcloudcli.googleapis.com可用工具run_gcloud_command仅此一个run_gcloud_command的语义是在受管的远程环境中代表用户安全地执行单条 gcloud 命令。单条这一点与 SKILL.md 中 Execution Constraints 的约束相互印证——禁止命令链chaining、禁止 shell 管道与重定向、禁止命令替换每次只执行一条可被用户审阅的命令。值得注意的是当前插件自带的 mcp_config.json 中仅注册了developer-knowledge这一台远程 MCP ServerDeveloper Knowledge 服务器供 retrieving-developer-knowledge Skill 使用而gcloud-remote的cloudcli.googleapis.com/mcp条目是面向接入方 MCP 客户端文档以 Jetski 为例的配置范例——也就是说把 gcloud 能力接入你的 Agent 客户端时需要按下文第 2 节的方式自行添加该条目。2. 客户端接入mcp_config.json 配置与 google_credentials 认证要让 MCP 客户端连上远程 Cloud CLI MCP Server需要在客户端的mcp_config.json中添加如下服务条目{ mcpServers: { gcloud-remote: { serverUrl: https://cloudcli.googleapis.com/mcp, authProviderType: google_credentials } } }其中authProviderType: google_credentials是强制字段其含义是指示 MCP 客户端在请求上附加 Application Default CredentialsADC并使用https://www.googleapis.com/auth/cloud-platformOAuth scope。如果省略该字段客户端将发送未认证请求直接得到401 Unauthorized错误。这一配置模式并非孤例。从当前仓库的插件元数据看gemini-extension.json 对 Developer Knowledge MCP Server 的注册同样显式写明了authProviderType: google_credentialsmcpServers: { developer-knowledge: { httpUrl: https://developerknowledge.googleapis.com/mcp, authProviderType: google_credentials } }从源码结构看这是整个google-cloud-developer插件对Google 官方远程 MCP Server的统一认证约定凡是*.googleapis.com/mcp端点都依赖客户端侧的 ADC 完成 OAuth 授权而不是在请求体中传递任何长期凭据。3. 前置条件API 启用与双重 IAM 权限在使用 Cloud CLI 远程 MCP Server 前目标项目与调用身份必须同时满足两个硬性前置条件。缺任何一项端点在工具发现tools/list和工具调用tools/call两个阶段都会返回403 Forbidden——这比401更隐蔽因为它发生在身份认证已通过之后容易让排错方向跑偏。3.1 前置条件一启用 Cloud CLI Execution APIcloudcli.googleapis.com必须在承载该 API 的项目上启用两种方式任选其一通过 Google Cloud Console进入APIs Services→Library搜索Cloud CLI Execution API在右上角项目选择器中选中目标项目后点击Enable。通过gcloudCLIgcloud services enable cloudcli.googleapis.com --project{project_id}这里{project_id}是API 宿主项目后文project参数所指与被查询/修改的资源所在项目可以不同。3.2 前置条件二两层角色要求调用身份需要持有两类权限缺一不可MCP Access Role工具层调用身份必须在目标项目上拥有MCP Tool User角色即roles/mcp.toolUser。该角色授予mcp.tools.call权限是调用任何远程 MCP 工具的前提。Downstream Resource Roles资源层调用身份还必须对命令实际查询/修改的底层资源持有标准 IAM 权限例如只读查询 Compute 资源需要roles/compute.viewer部署 Cloud Run 服务需要roles/run.developer。这一双角色设计意味着即便你有roles/mcp.toolUser也只能合法地调用工具能否看到/改动具体资源仍由资源层 IAM 决定——与本地直接执行gcloud时的鉴权行为保持一致远程化没有放大权限面。4. run_gcloud_command 工具参数详解对run_gcloud_command的调用接受三个参数参数类型必填说明commandstring是要执行的完整gcloud命令行字符串例如gcloud compute instances list --project{resource_project} --formatjsonprojectstring是承载 Cloud CLI Execution API 的项目资源名格式为projects/{api_project}例如projects/my-api-projectinput_fileslist of objects否在远程执行环境中运行命令前先预置的文件。每项包含相对path和字符串contents4.1 核心规则API 宿主项目 ≠ 资源项目这是整个工具参数设计中最容易出错的一点文档用 IMPORTANT 级别专门强调顶层project参数projects/{api_project}严格只用于cloudcli.googleapis.comAPI 本身的配额quota、计费billing与 API 启用判断它不会成为被执行命令的项目上下文。对于项目作用域命令必须在command字符串中显式携带--project{resource_project}且{resource_project}不必等于承载 Cloud CLI Execution API 的项目。对于非项目作用域命令如 billing、organization 类查询若底层 API 需要配额项目则必须在command字符串中携带--billing-project{billing_project}。这一设计与 SKILL.md Project and Location Scoping (Critical) 一节的原则完全对齐不要依赖任何隐式默认项目所有资源操作与查询命令都要显式指定--project以保证命令是确定性的、非交互式的、指向正确环境的。在本地 CLI 模式下Agent 依赖本地gcloud config的默认项目上下文而远程 MCP 模式下没有任何本地配置可言因此显式--project从最佳实践升级为唯一途径。4.2 示例一基本命令执行{ command: gcloud compute instances list --projectmy-resource-project --formatjson, project: projects/my-cloudcli-api-project }注意两个项目 ID 不同my-cloudcli-api-project承载 Cloud CLI Execution API负责配额与计费而命令实际查询的是my-resource-project中的 VM 实例。同时命令自带--formatjson符合数据缩减约束。4.3 示例二携带输入文件执行input_files参数解决了一个沙箱环境的经典痛点远程执行环境里并没有你本地的文件。例如要执行gcloud run services replace service-config.yaml可以先把 YAML 内容通过工具参数投递进远程环境{ command: gcloud run services replace service-config.yaml --regionus-central1 --projectmy-resource-project, project: projects/my-cloudcli-api-project, input_files: [ { path: service-config.yaml, contents: apiVersion: serving.knative.dev/v1\nkind: Service\nmetadata:\n name: my-service\n... } ] }执行引擎会先按input_files中声明的相对path将文件内容物化到远程工作目录再运行command。这让部署配置文件这类原本依赖本地文件系统的操作在纯远程、无 TTY 的 MCP 会话中成为可能。5. 响应结构与 exit_code 权威性工具返回一个执行响应对象包含四个字段exit_code命令执行的数字退出状态。这是判断命令成功/失败的首要且权威指标。stdout标准输出流。stderr标准错误流。output_files命令生成的任何输出文件。对 Agent 而言响应解读有三条硬性规则Exit Code Authority当且仅当exit_code 0时命令才算成功非零即失败。不要以输出看起来正常替代退出码判断。stderr 可能是纯信息性输出在gcloud中stderr经常承载标准状态消息、进度更新和异步跟踪 ID例如--async产生的操作 ID即使命令成功exit_code 0也可能非空。Agent 绝不能仅因stderr非空就判定命令失败——这是 Agent 集成中最常见的误判来源。失败诊断要双向检查当exit_code ! 0时诊断性错误信息可能出现在stderr也可能出现在stdout必须两个流都检查后才能理解失败原因并制定修正方案。这一规则与本地 CLI 模式下的调试经验一致但更值得强调MCP 场景下 Agent 是自动化的第一读者把stderr 非空 失败当作假设的 Agent会陷入假失败 → 重试 → 资源被重复创建的恶性循环。6. 沙箱环境受禁止与不受支持的命令清单Cloud CLI 远程 MCP Server 运行在一个沙箱化、非交互式的环境中。文档列出了部分不受支持的gcloud命令清单非穷尽且可能随时增删它们的共同特征是依赖本地机器状态命令禁止原因gcloud auth本地认证与凭据管理gcloud config本地 CLI 配置档案与属性gcloud iam service-accounts服务账号管理本地凭据上下文gcloud init交互式初始化向导gcloud survey用户反馈与问卷gcloud compute ssh/gcloud app instances ssh交互式 SSH shell可以推断判定逻辑围绕命令是否需要本地凭据库、本地配置文件、TTY 或交互式会话展开凡触碰 Agent 所在机器本地状态的命令组都被排除在远程执行之外。这也解释了第 4.1 节没有隐式默认项目的原因——远程环境里根本不存在gcloud config可依赖。此外SKILL.md 还维护了一份语义层面的Prohibited Operations拒绝清单IAM 策略变更、gcloud * delete、gcloud billing *、gcloud organizations *、gcloud kms *、gcloud infra-manager deployments apply等要求这些操作必须经过人工显式授权。两份清单互补前者界定技术上不支持执行后者界定技术上可执行但策略上禁止自主执行。7. 安全与执行准则Safety Execution Guidelines文档在结尾给出了四条面向 Agent 的安全准则它们同样是把本地 headless 执行 gcloud的经验映射到 MCP 场景变更类命令必须用户显式同意create、delete、update、patch等破坏性或状态变更命令在用户未明确授权前Agent 不得自主调用。这与 SKILL.md 的 CAUTION 级约束destructive actions MUST be explicitly authorized一致。长操作使用--async对耗时操作创建 VM 实例、GKE 集群、数据库实例等在command中追加--async以避免执行超时操作 ID 会出现在响应中按第 5 节规则通常位于stderr可用gcloud operations describe OPERATION_ID轮询状态。数据缩减防上下文膨胀在command中使用--formatjson、--filter、--limit约束输出量防止撑爆 LLM 上下文窗口。SKILL.md 将其升级为强制项任何list命令至少携带一个数据缩减标志且推荐用gcloud GROUP RESOURCE list --limit1 --formatjson先探测 schema 再构造投影。非交互式执行--quiet/-q对可能触发交互确认的命令一律携带--quiet。远程沙箱没有 TTY 与 stdin 处理器缺少该标志的命令会无限期挂起等待输入最终导致后台任务超时。8. 与插件其他部件的协作关系把本文内容放回google-cloud-developer插件见 plugin.json的整体语境中Cloud CLI 远程 MCP Server 只是安全执行这一大目标的一条腿gcloud Skill 本体SKILL.md负责命令怎么拼才对强制gcloud help leaf_command叶子级语法校验、禁止把父命令组 help 当作叶子命令的验证依据、禁止用网络搜索替代gcloud help。CLI 参考文档cli-usage.md负责本地模式怎么装、怎么认证、怎么管理配置档案其认证的 ADC / 服务账号密钥 / 身份模拟impersonation等流程正是远程 MCP 模式下客户端 ADC 授权的本地对应物。本文的 MCP 参考文档负责远程模式怎么连、怎么传参、怎么判成败。插件级的 rules/google-cloud-discovery.md 则说明本插件只安装了 Google Cloud 技能目录的一个小子集mcp-usage.md正是随 gcloud Skill 一起分发的深度参考。因此一个完整的远程 MCP 工作流是Agent 先用gcloud help本地或文档检索验证叶子命令语法 → 按第 4 节规则组装command/project/input_files参数 → 通过run_gcloud_command下发 → 按第 5 节规则以exit_code判定成败、双向检查输出流 → 对变更类操作确保已获得用户授权。9. 速查表事项要点端点https://cloudcli.googleapis.com/mcpHTTPJSON-RPC 2.0客户端配置mcpServers条目须带authProviderType: google_credentials否则401API 启用在 API 宿主项目启用cloudcli.googleapis.comConsole 或gcloud services enable权限调用身份需roles/mcp.toolUser 资源层角色如roles/compute.viewer缺一即403project参数仅用于 API 配额/计费格式projects/{api_project}项目上下文必须写在command内的--project{resource_project}非项目作用域命令需要时写--billing-project{billing_project}预置文件input_files: [{path, contents}]成败判定只看exit_code 0stderr非空不代表失败失败诊断stdout与stderr都查禁用命令auth/config/iam service-accounts/init/survey/交互 SSH 等本地状态类命令变更操作必须用户显式授权长操作加--asynclist必须带--limit/--filter/--format执行命令带--quiet以上所有配置、参数与规则均源自当前仓库 mcp-usage.md 文档原文认证模式与执行约束可对照 gemini-extension.json、SKILL.md 与 cli-usage.md 交叉验证。需要提醒的是受支持命令清单是动态的non-exhaustive and subject to the addition or removal of commands without notice在接入新的 gcloud 命令组前建议先以只读list类命令做一次端到端探测。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考