render-automation

通过 Rube MCP 实现 Render 自动化

通过 Rube MCP 使用 Composio 的 Render 工具包，自动执行 Render 云平台操作。

前提条件

• 必须已连接 Rube MCP（可使用 RUBE_SEARCH_TOOLS）
• 通过 RUBE_MANAGE_CONNECTIONS 建立有效的 Render 连接，并指定工具包 render
• 始终先调用 RUBE_SEARCH_TOOLS，以获取当前工具架构

设置

获取 Rube MCP：在客户端配置中将 https://rube.app/mcp 添加为 MCP 服务。请确认当前的 MCP 和服务身份验证状态；仅添加端点并不会建立经过身份验证的连接。

1. 确认 RUBE_SEARCH_TOOLS 有响应，以验证 Rube MCP 可用
2. 调用 RUBE_MANAGE_CONNECTIONS，并指定工具包 render
3. 如果连接状态不是 ACTIVE，请通过返回的身份验证链接完成 Render 身份验证
4. 在运行任何工作流之前，确认连接状态显示为 ACTIVE

操作影响边界

执行操作前，先确定准确的账户、环境和 ID。只读列表操作并不代表获准触发付费部署。预览具体影响，并且仅执行用户授权的操作；记录返回的身份标识和状态，在重试前核实有歧义的写入操作，并确认最终状态，不要将请求已受理视为操作已完成。

核心工作流

1. 列出和浏览服务

适用场景：用户希望查找或检查 Render 服务（Web 服务、静态网站、工作进程、定时任务）

工具调用顺序：

1. RENDER_LIST_SERVICES - 列出所有服务，可选使用筛选条件 [必需]

关键参数：

• name：按名称子字符串筛选服务
• type：按服务类型筛选（'web_service'、'static_site'、'private_service'、'background_worker'、'cron_job'）
• limit：每页最多返回的结果数（默认值为 20，最大值为 100）
• cursor：上一响应中的分页游标

注意事项：

• 服务类型必须与枚举值完全一致：'web_service'、'static_site'、'private_service'、'background_worker'、'cron_job'
• 分页使用基于游标的方式；持续使用 cursor，直到该字段不存在
• 名称筛选基于子字符串，而非完全匹配
• 服务 ID 的格式为 'srv-xxxxxxxxxxxx'
• 默认限制为 20；如需完整列表，请设置更高的值

2. 触发部署

适用场景：用户希望手动部署或重新部署服务

工具调用顺序：

1. RENDER_LIST_SERVICES - 查找要部署的服务 [前提条件]
2. RENDER_TRIGGER_DEPLOY - 触发新部署 [必需]
3. RENDER_RETRIEVE_DEPLOY - 监控部署进度 [可选]

关键参数：

• 对于 TRIGGER_DEPLOY：
  • serviceId：要部署的服务 ID（必需，格式：'srv-xxxxxxxxxxxx'）
  • clearCache：设为 true 可在部署前清除构建缓存
• 对于 RETRIEVE_DEPLOY：
  • serviceId：服务 ID
  • deployId：触发响应中的部署 ID（格式：'dep-xxxxxxxxxxxx'）

注意事项：

• 必须提供 serviceId；请先通过 LIST_SERVICES 确定该 ID
• 服务 ID 以 'srv-' 为前缀
• 部署 ID 以 'dep-' 为前缀
• clearCache: true 会强制执行全新构建；耗时更长，但可解决与缓存相关的问题
• 部署为异步操作；请使用 RETRIEVE_DEPLOY 轮询状态
• 如果有其他部署正在进行，触发新部署可能会使其进入队列

3. 监控部署状态

适用场景：用户希望检查部署进度或结果

工具调用顺序：

1. RENDER_RETRIEVE_DEPLOY - 获取部署详情和状态 [必需]

关键参数：

• serviceId：服务 ID（必需）
• deployId：部署 ID（必需）
• 响应包含 status、createdAt、updatedAt、finishedAt、commit

注意事项：

• 必须同时提供 serviceId 和 deployId
• 部署状态包括：'created'、'build_in_progress'、'update_in_progress'、'live'、'deactivated'、'build_failed'、'update_failed'、'canceled'
• 'live' 表示部署成功
• 'build_failed' 或 'update_failed' 表示部署出错
• 请以合理的间隔（10-30 秒）轮询，以避免触发速率限制

4. 管理项目

使用场景：用户想要列出并组织 Render 项目

工具调用顺序：

1. RENDER_LIST_PROJECTS - 列出所有项目 [必需]

关键参数：

• limit：每页最大结果数（最大 100）
• cursor：来自上一次响应的分页游标

注意事项：

• 项目用于将相关服务分组在一起
• 分页采用基于游标的方式
• 项目 ID 用于组织管理目的
• 并非所有服务都会分配到某个项目

常见模式

ID 解析

服务名称 -> 服务 ID：

1. Call RENDER_LIST_SERVICES with name=service_name
2. Find service by name in results
3. Extract id (format: 'srv-xxxxxxxxxxxx')

部署查询：

1. Store deployId from RENDER_TRIGGER_DEPLOY response
2. Call RENDER_RETRIEVE_DEPLOY with serviceId and deployId
3. Check status for completion

部署与监控模式

1. RENDER_LIST_SERVICES -> find service by name -> get serviceId
2. RENDER_TRIGGER_DEPLOY with serviceId -> get deployId
3. Loop: RENDER_RETRIEVE_DEPLOY with serviceId + deployId
4. Check status: 'live' = success, 'build_failed'/'update_failed' = error
5. Continue polling until terminal state reached

分页

• 使用响应中的 cursor 获取下一页
• 持续进行，直到 cursor 不存在或结果为空
• LIST_SERVICES 和 LIST_PROJECTS 都使用基于游标的分页
• 将 limit 设为最大值（100）以减少分页轮次

已知注意事项

服务 ID：

• 始终以 'srv-' 为前缀（例如 'srv-abcd1234efgh'）
• 部署 ID 以 'dep-' 为前缀（例如 'dep-d2mqkf9r0fns73bham1g'）
• 始终通过 LIST_SERVICES 将服务名称解析为 ID

服务类型：

• 过滤时必须使用精确的枚举值
• 可用类型：web_service、static_site、private_service、background_worker、cron_job
• 不同服务类型的部署行为不同

部署行为：

• 部署是异步的；始终轮询以确认完成
• 清除缓存的部署耗时更长，但可解决过期缓存问题
• 失败的部署不会自动回滚；上一个版本会保持在线
• 并发触发的部署可能会排队

速率限制：

• Render API 有速率限制
• 避免快速轮询；使用 10-30 秒的间隔
• 批量操作应进行限流

响应解析：

• 响应数据可能嵌套在 data 键下
• 时间戳使用 ISO 8601 格式
• 对可选字段使用防御性解析并提供回退值

快速参考

任务	工具 Slug	关键参数
列出服务	RENDER_LIST_SERVICES	name, type, limit, cursor
触发部署	RENDER_TRIGGER_DEPLOY	serviceId, clearCache
获取部署状态	RENDER_RETRIEVE_DEPLOY	serviceId, deployId
列出项目	RENDER_LIST_PROJECTS	limit, cursor

使用时机

本技能适用于执行概述中描述的工作流或操作。

限制

• 仅当任务明确匹配上述范围时使用本技能。
• 不要将输出视为环境特定验证、测试或专家审查的替代品。
• 如果缺少必需的输入、权限、安全边界或成功标准，请停止并请求澄清。