Render Automation via Rube MCP

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

Toolkit docs: composio.dev/toolkits/render

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.

• Verify Rube MCP is available by confirming RUBE_SEARCH_TOOLS responds

• Call RUBE_MANAGE_CONNECTIONS with toolkit render

• If connection is not ACTIVE, follow the returned auth link to complete Render authentication

• 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:

• 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:

• 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 : 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:

• 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:

• 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

Powered by Composio