Render MCP Server

You can install the latest version of the Render MCP Server by running the official installation script via curl. The script automatically detects your operating system (Linux or macOS/Darwin) and architecture (amd64 or arm64), downloads the appropriate binary from GitHub releases, and installs it to a local directory.

Installation Locations

• Root/Sudo users: The binary is installed to /usr/local/bin/render-mcp-server.
• Standard users: The binary is installed to $HOME/.local/bin/render-mcp-server.

Prerequisites

The following commands must be installed on your system:

• curl
• sed
• unzip

Post-Installation Setup

If the installation directory is not already in your PATH, you must add it to your shell configuration file (e.g., .bashrc or .zshrc) to use the command globally:

export PATH=$PATH:$HOME/.local/bin

To verify the installation immediately without updating your PATH, run:

$HOME/.local/bin/render-mcp-server --version

curl -fsSL https://raw.githubusercontent.com/render-oss/render-mcp-server/refs/heads/main/bin/install.sh | sh

Use the Key Value tools to manage in-memory data stores.

• list_key_value: Lists all Key Value instances.
• get_key_value: Gets details for a specific keyValueId.
• create_key_value: Creates a new instance. Requires name and plan (e.g., free, starter, standard, pro, pro_plus).

Configuration Options:

• maxmemoryPolicy: Eviction policy (e.g., allkeys_lru, volatile_ttl, noeviction).
• persistenceMode: Data persistence behavior (journal_snapshot, snapshot, or off).

### Key Value instances

- **list_key_value** - List all Key Value instances in your Render account

  - No parameters required

- **get_key_value** - Get details about a specific Key Value instance

  - `keyValueId`: The ID of the Key Value instance to retrieve (string, required)

- **create_key_value** - Create a new Key Value instance
  - `name`: Name of the Key Value instance (string, required)
  - `plan`: Pricing plan for the Key Value instance (string, required). Accepted values: [free, starter, standard, pro, pro_plus]
  - `region`: Region for deployment (string, optional). Accepted values: [oregon, frankfurt, singapore, ohio, virginia]
  - `maxmemoryPolicy`: Eviction policy for the Key Value store (string, optional). Accepted values: [noeviction, allkeys_lfu, allkeys_lru, allkeys_random, volatile_lfu, volatile_lru, volatile_random, volatile_ttl]
  - `persistenceMode`: Data persistence behavior for the Key Value store (string, optional). Accepted values: [journal_snapshot, snapshot, off]

The get_metrics tool allows you to fetch performance data for services, Postgres databases, and Key Value stores.

Parameters:

• resourceId: The ID of the resource (service, Postgres, or Key Value ID).
• metricTypes: An array of metrics to fetch.
  • All Resources: cpu_usage, cpu_limit, cpu_target, memory_usage, memory_limit, memory_target, instance_count.
  • Services Only: http_request_count, http_latency, bandwidth_usage.
  • Databases/KV Only: active_connections.
• startTime / endTime: RFC3339 format. Must be within the last 30 days.
• resolution: Time resolution in seconds (minimum 30s, defaults to 60s).
• cpuUsageAggregationMethod: AVG (default), MAX, or MIN.
• httpLatencyQuantile: Quantile for http_latency (e.g., 0.5, 0.95, 0.99). Defaults to 0.95.
• aggregateHttpRequestCountsBy: host or statusCode.
• httpHost / httpPath: Filters for HTTP-specific metrics.

### Metrics

- **get_metrics** - Get performance metrics for any Render resource (services, Postgres databases, key-value stores). Metrics may be empty if the metric is not valid for the given resource
  - `resourceId`: The ID of the resource to get metrics for (service ID, Postgres ID, or key-value store ID) (string, required)
  - `metricTypes`: Which metrics to fetch (array of strings, required). Accepted values:
    - `cpu_usage`: CPU usage metrics (available for all resources)
    - `cpu_limit`: CPU resource constraints (available for all resources)
    - `cpu_target`: CPU autoscaling thresholds (available for all resources)
    - `memory_usage`: Memory usage metrics (available for all resources)
    - `memory_limit`: Memory resource constraints (available for all resources)
    - `memory_target`: Memory autoscaling thresholds (available for all resources)
    - `instance_count`: Instance count metrics (available for all resources)
    - `http_request_count`: HTTP request count metrics (services only)
    - `http_latency`: HTTP response time metrics (services only)
    - `bandwidth_usage`: Bandwidth usage metrics (services only)
    - `active_connections`: Active connection metrics (databases and key-value stores only)
  - `startTime`: Start time for metrics query in RFC3339 format (e.g., '2024-01-01T12:00:00Z'), defaults to 1 hour ago. The start time must be within the last 30 days (string, optional)
  - `endTime`: End time for metrics query in RFC3339 format (e.g., '2024-01-01T13:00:00Z'), defaults to the current time. The end time must be within the last 30 days (string, optional)
  - `resolution`: Time resolution for data points in seconds. Lower values provide more granular data. Higher values provide more aggregated data points. API defaults to 60 seconds if not provided, minimum 30 seconds (number, optional)
  - `cpuUsageAggregationMethod`: Method for aggregating CPU usage metric values over time intervals (string, optional). Defaults to `AVG`. Accepted values:
    - `AVG`: Average CPU usage over time intervals
    - `MAX`: Maximum CPU usage over time intervals
    - `MIN`: Minimum CPU usage over time intervals
  - `aggregateHttpRequestCountsBy`: Field to aggregate HTTP request count metrics by (string, optional). When not specified, returns total request counts. Accepted values:
    - `host`: Aggregate by request host
    - `statusCode`: Aggregate by HTTP status code
  - `httpLatencyQuantile`: The quantile/percentile of HTTP latency to fetch. Only supported for http_latency metric. Common values are 0.5 (median), 0.95 (95th percentile), 0.99 (99th percentile). Defaults to 0.95 if not specified (number, optional, min: 0.0, max: 1.0)
  - `httpHost`: Filter HTTP metrics to specific request hosts. Supported for http_request_count and http_latency metrics. Example: 'api.example.com' or 'myapp.render.com'. When not specified, includes all hosts (string, optional)
  - `httpPath`: Filter HTTP metrics to specific request paths. Supported for http_request_count and http_latency metrics. Example: '/api/users' or '/health'. When not specified, includes all paths (string, optional)

You can create and manage various types of services on Render using the MCP server.

Web Services

Use create_web_service to deploy applications.

• Supported Runtimes: node, python, go, rust, ruby, elixir, docker.
• Docker Support: If using docker, you can specify dockerfilePath, dockerContext, and dockerCommand.
• Note: Deploying prebuilt images from a container registry is not supported.

Static Sites

Use create_static_site for frontend applications. Requires name, buildCommand, and optionally repo, branch, autoDeploy, and publishPath.

Cron Jobs

Use create_cron_job for scheduled tasks. Requires a schedule using standard 5-field cron syntax (e.g., 0 0 * * * for daily at midnight) and a runtime.

Updating Services

Note: Direct updates to Web Services, Static Sites, and Cron Jobs are not supported via the MCP server. Using the update tools for these services will return a link to the Render Dashboard where changes must be made manually or via the Render API.

However, you can update environment variables for any service using update_environment_variables by providing the complete list of envVars.

### Services

- **list_services** - List all services in your Render account

  - `includePreviews`: Whether to include preview services, defaults to false (boolean, optional)

- **get_service** - Get details about a specific service

  - `serviceId`: The ID of the service to retrieve (string, required)

- **create_web_service** - Create a new web service in your Render account

  - `name`: A unique name for your service (string, required)
  - `runtime`: Runtime environment for your service (string, required). Accepted values: [node, python, go, rust, ruby, elixir, docker]
  - `buildCommand`: Command used to build your service (string, required unless runtime is `docker`)
  - `startCommand`: Command used to start your service (string, required unless runtime is `docker`)
  - `dockerfilePath`: Path to the Dockerfile relative to the repository root (string, optional). Defaults to `./Dockerfile`.
  - `dockerContext`: Build context directory relative to the repository root (string, optional). Defaults to `.`.
  - `dockerCommand`: Override for the image's startup command (string, optional).
  - `repo`: Repository containing source code (string, optional)
  - `branch`: Repository branch to deploy (string, optional)
  - `plan`: Plan for your service (string, optional). Accepted values: [starter, standard, pro, pro_max, pro_plus, pro_ultra]
  - `autoDeploy`: Whether to automatically deploy the service (string, optional). Defaults to `yes` ([yes, no]).
  - `region`: Geographic region for deployment (string, optional). Defaults to `oregon`. Accepted values: [oregon, frankfurt, singapore, ohio, virginia]
  - `envVars`: Environment variables array (array, optional)

Deployments

• list_deploys: View deployment history for a specific serviceId.
• get_deploy: Get details for a specific serviceId and deployId.
• trigger_deploy: Manually trigger a new deployment. Use clearCache: true to clear the build cache before deploying.

Logs

Use list_logs to query logs with various filters:

• Required: resource (array of strings).
• Optional Filters: level, type, instance, host, statusCode, method, path, text, startTime (RFC3339), endTime (RFC3339), direction, and limit.
• list_log_label_values: Lists all values for a specific label within filtered logs.

### Deployments

- **list_deploys** - List deployment history for a service

  - `serviceId`: The ID of the service to get deployments for (string, required)

- **get_deploy** - Get details about a specific deployment

  - `serviceId`: The ID of the service (string, required)
  - `deployId`: The ID of the deployment (string, required)

- **trigger_deploy** - Trigger a new deploy for a service.
  - `serviceId`: The ID of the service to deploy (string, required)
  - `clearCache`: Whether to clear the build cache before deploying (boolean, optional). Defaults to `false`.

Postgres Operations

• list_postgres_instances: Lists all PostgreSQL databases in your account.
• get_postgres: Retrieves details for a specific postgresId.
• create_postgres: Creates a new database. Requires name and plan (e.g., free, basic_256mb, pro_4gb, etc.). Optionally accepts region, version (e.g., 15), and diskSizeGb.
• query_render_postgres: Read-only SQL execution. Run a query against a specific postgresId using the sql parameter.

### Postgres Databases

- **query_render_postgres** - Run a read-only SQL query against a Render-hosted Postgres database

  - `postgresId`: The ID of the Postgres instance to query (string, required)
  - `sql`: The SQL query to run (string, required)

- **list_postgres_instances** - List all PostgreSQL databases in your Render account

  - No parameters required

- **get_postgres** - Get details about a specific PostgreSQL database

  - `postgresId`: The ID of the PostgreSQL database to retrieve (string, required)

- **create_postgres** - Create a new PostgreSQL database
  - `name`: Name of the PostgreSQL database (string, required)
  - `plan`: Pricing plan for the database (string, required). Accepted values: [free, basic_256mb, ..., accelerated_1024gb]
  - `region`: Region for deployment (string, optional). Accepted values: [oregon, frankfurt, singapore, ohio, virginia]
  - `version`: PostgreSQL version to use (e.g., 14, 15) (number, optional)
  - `diskSizeGb`: Database capacity in GB (number, optional)

The Render MCP server allows you to manage and switch between different workspaces.

Important Note on Workspace Selection: While select_workspace exists, it is recommended to pass the workspaceId explicitly to every resource tool call. This ensures the target workspace remains consistent across MCP reconnects or session changes. Relying on the implicit session-based workspace selection is deprecated and will be removed in future versions.

Available tools:

• list_workspaces: Lists all workspaces you have access to.
• select_workspace: Sets the current workspace (uses ownerID parameter for backward compatibility; new code should use workspaceId in resource tools).
• get_selected_workspace: Retrieves the currently active workspace.

### Workspaces

- **list_workspaces** - List the workspaces that you have access to

  - No parameters required

- **select_workspace** - Select a workspace to use

  - `ownerID`: The ID of the workspace to select (string, required). Kept as `ownerID` so
    existing callers of this deprecated tool keep working; new code should pass `workspaceId`
    on each resource tool call much.