About render-automation
render-automation is a skill for operating Render through Composio’s Render toolkit via Rube MCP. It helps users inspect services and projects, trigger deployments, and check deployment status, while emphasizing verification of the target and final state.
Key features
- 01List and filter Render services
- 02Browse projects with cursor pagination
- 03Trigger deployments with optional cache clearing
- 04Retrieve deployment status and details
- 05Resolve service names to service IDs
Use cases
- 01Find a service before deployment
- 02Manually deploy or redeploy a service
- 03Check whether a deployment is live or has failed
- 04Browse projects and their related services
MCP support
Uses Rube MCP to access Composio’s Render toolkit. An active Render connection and current tool schemas are required before workflows.
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ sickn33/ agentic-awesome-skills --skill render-automationAfter installing, type/render-automationin Claude Code to confirm it loaded.
Details
From the project READMERender 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_CONNECTIONSwith toolkitrender - Always call
RUBE_SEARCH_TOOLSfirst to get current tool schemas
Setup
Get Rube MCP: Add https://rube.app/mcp as an MCP server in your client configuration. Verify current MCP and service authentication; adding an endpoint alone does not establish an authenticated connection.
- Verify Rube MCP is available by confirming
RUBE_SEARCH_TOOLSresponds - Call
RUBE_MANAGE_CONNECTIONSwith toolkitrender - If connection is not ACTIVE, follow the returned auth link to complete Render authentication
- Confirm connection status shows ACTIVE before running any workflows
Effect boundary
Resolve exact account/environment and IDs before acting. Read-only listing does not authorize paid deployment triggering. Preview the specific effect and perform only the user-authorized action; record returned identity/status, reconcile ambiguous writes before retries and verify final state rather than treating request acceptance as completion.
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:
RENDER_LIST_SERVICES- List all services with optional filters [Required]
Key parameters:
name: Filter services by name substringtype: 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
cursoruntil 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:
RENDER_LIST_SERVICES- Find the service to deploy [Prerequisite]RENDER_TRIGGER_DEPLOY- Trigger a new deployment [Required]RENDER_RETRIEVE_DEPLOY- Monitor deployment progress [Optional]
Key parameters:
- For TRIGGER_DEPLOY:
serviceId: Service ID to deploy (required, format: 'srv-xxxxxxxxxxxx')clearCache: Settrueto clear build cache before deploying
- For RETRIEVE_DEPLOY:
serviceId: Service IDdeployId: Deploy ID from trigger response (format: 'dep-xxxxxxxxxxxx')
Pitfalls:
serviceIdis required; resolve via LIST_SERVICES first- Service IDs start with 'srv-' prefix
- Deploy IDs start with 'dep-' prefix
clearCache: trueforces 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:
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
serviceIdanddeployIdare 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:
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
cursorfrom response for next page - Continue until
cursoris absent or results are empty - Both LIST_SERVICES and LIST_PROJECTS use cursor-based pagination
- Set
limitto 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
datakey - 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.