以下为本文档的中文说明

Render 云平台自动化技能是一个通过 Rube MCP 和 Composio 平台实现 Render 云服务操作自动化的工具。它的核心功能涵盖服务管理、部署管理和项目管理等 Render 平台的核心运维任务。使用场景主要面向使用 Render 作为云托管平台的开发团队，特别是需要频繁部署、扩缩容或管理多个服务的场景。该技能的工作流程与同类 Rube MCP 工具一致：首先验证 Rube MCP 连接状态，然后通过 RUBE_MANAGE_CONNECTIONS 建立与 Render 服务的连接并进行 OAuth 认证，确认连接激活后即可执行自动化工作流。核心特点在于标准化的集成模式和工具优先原则。与其他基于 Rube MCP 的自动化技能一样，它在执行任何工作流前必须获取最新的工具架构，确保操作接口与 Render 平台 API 保持同步。设计原则强调可重复性和安全性，每次操作前都验证连接状态，避免在认证失效的情况下执行失败的操作。对于使用 Render 进行应用托管的开发团队来说，这显著提升了部署和管理效率，尤其适合持续集成和持续部署流程的自动化。从技术实现角度来看，该技能采用了业界成熟的最佳实践和设计模式，确保了代码质量和系统稳定性。通

---

Render Automation via Rube MCP

Automate Render cloud platform operations through Composio’s Render toolkit via Rube MCP.

Prerequisites

• Rube MCP must be connected (RUBE_SEARCH_TOOLS available)
• Active Render connection via RUBE_MANAGE_CONNECTIONS with toolkit render
• Always call RUBE_SEARCH_TOOLS first to get current tool schemas

Setup

Get Rube MCP: Add https://rube.app/mcp as an MCP server in your client configuration. No API keys needed — just add the endpoint and it works.

1. Verify Rube MCP is available by confirming RUBE_SEARCH_TOOLS responds
2. Call RUBE_MANAGE_CONNECTIONS with toolkit render
3. If connection is not ACTIVE, follow the returned auth link to complete Render authentication
4. Confirm connection status shows ACTIVE before running any workflows

Core Workflows

1. List and Browse Services

When to use: User wants to find or inspect Render services (web services, static sites, workers, cron jobs)

Tool sequence:

1. RENDER_LIST_SERVICES - List all services with optional filters [Required]

Key parameters:

• name: Filter services by name substring
• type: Filter by service type (‘web_service’, ‘static_site’, ‘private_service’, ‘background_worker’, ‘cron_job’)
• limit: Maximum results per page (default 20, max 100)
• cursor: Pagination cursor from previous response

Pitfalls:

• Service types must match exact enum values: ‘web_service’, ‘static_site’, ‘private_service’, ‘background_worker’, ‘cron_job’
• Pagination uses cursor-based approach; follow cursor until absent
• Name filter is substring-based, not exact match
• Service IDs follow the format ‘srv-xxxxxxxxxxxx’
• Default limit is 20; set higher for comprehensive listing

2. Trigger Deployments

When to use: User wants to manually deploy or redeploy a service

Tool sequence:

1. RENDER_LIST_SERVICES - Find the service to deploy [Prerequisite]
2. RENDER_TRIGGER_DEPLOY - Trigger a new deployment [Required]
3. RENDER_RETRIEVE_DEPLOY - Monitor deployment progress [Optional]

Key parameters:

• For TRIGGER_DEPLOY:
  • serviceId: Service ID to deploy (required, format: ‘srv-xxxxxxxxxxxx’)
  • clearCache: Set true to clear build cache before deploying
• For RETRIEVE_DEPLOY:
  • serviceId: Service ID
  • deployId: Deploy ID from trigger response (format: ‘dep-xxxxxxxxxxxx’)

Pitfalls:

• serviceId is required; resolve via LIST_SERVICES first
• Service IDs start with ‘srv-’ prefix
• Deploy IDs start with ‘dep-’ prefix
• clearCache: true forces a clean build; takes longer but resolves cache-related issues
• Deployment is asynchronous; use RETRIEVE_DEPLOY to poll status
• Triggering a deploy while another is in progress may queue the new one

3. Monitor Deployment Status

When to use: User wants to check the progress or result of a deployment

Tool sequence:

1. RENDER_RETRIEVE_DEPLOY - Get deployment details and status [Required]

Key parameters:

• serviceId: Service ID (required)
• deployId: Deployment ID (required)
• Response includes status, createdAt, updatedAt, finishedAt, commit

Pitfalls:

• Both serviceId and deployId are required
• Deploy statuses include: ‘created’, ‘build_in_progress’, ‘update_in_progress’, ‘live’, ‘deactivated’, ‘build_failed’, ‘update_failed’, ‘canceled’
• ‘live’ indicates successful deployment
• ‘build_failed’ or ‘update_failed’ indicate deployment errors
• Poll at reasonable intervals (10-30 seconds) to avoid rate limits

4. Manage Projects

When to use: User wants to list and organize Render projects

Tool sequence:

1. RENDER_LIST_PROJECTS - List all projects [Required]

Key parameters:

• limit: Maximum results per page (max 100)
• cursor: Pagination cursor from previous response

Pitfalls:

• Projects group related services together
• Pagination uses cursor-based approach
• Project IDs are used for organizational purposes
• Not all services may be assigned to a project

Common Patterns

ID Resolution

Service name -> Service ID:

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

Deployment lookup:

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

Deploy and Monitor Pattern

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

Pagination

• Use cursor from response for next page
• Continue until cursor is absent or results are empty
• Both LIST_SERVICES and LIST_PROJECTS use cursor-based pagination
• Set limit to max (100) for fewer pagination rounds

Known Pitfalls

Service IDs:

• Always prefixed with ‘srv-’ (e.g., ‘srv-abcd1234efgh’)
• Deploy IDs prefixed with ‘dep-’ (e.g., ‘dep-d2mqkf9r0fns73bham1g’)
• Always resolve service names to IDs via LIST_SERVICES

Service Types:

• Must use exact enum values when filtering
• Available types: web_service, static_site, private_service, background_worker, cron_job
• Different service types have different deployment behaviors

Deployment Behavior:

• Deployments are asynchronous; always poll for completion
• Clear cache deploys take longer but resolve stale cache issues
• Failed deploys do not roll back automatically; the previous version stays live
• Concurrent deploy triggers may be queued

Rate Limits:

• Render API has rate limits
• Avoid rapid polling; use 10-30 second intervals
• Bulk operations should be throttled

Response Parsing:

• Response data may be nested under data key
• Timestamps use ISO 8601 format
• Parse defensively with fallbacks for optional fields

Quick Reference

Task	Tool Slug	Key Params
List services	RENDER_LIST_SERVICES	name, type, limit, cursor
Trigger deploy	RENDER_TRIGGER_DEPLOY	serviceId, clearCache
Get deploy status	RENDER_RETRIEVE_DEPLOY	serviceId, deployId
List projects	RENDER_LIST_PROJECTS	limit, cursor

When to Use

This skill is applicable to execute the workflow or actions described in the overview.

Limitations

• Use this skill only when the task clearly matches the scope described above.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.