How do I create a Render cron job with an AI assistant?

A Render cron job is a service, so it is created with render_create_service using type cron_job. Its serviceDetails must match the cronJobDetailsPOST branch and include schedule, a five-field cron expression in UTC. For a Docker cron job, set runtime to docker and give envSpecificDetails a dockerfilePath, dockerContext and dockerCommand. render_create_job is different: it runs a one-off command on an existing service.

How does it stay up to date with the Render API?

Every tool is generated from Render's own OpenAPI document. A scheduled GitHub Actions workflow re-fetches that document daily, regenerates the tool catalogue and the documentation, and opens a pull request when the set of tools actually changes.

render-useful-mcp — a complete MCP server for the Render API

Q: How do I install an MCP server globally in Claude Code?

Pass --scope user. For this server: claude mcp add render --scope user -e RENDER_API_KEY=rnd_your_key -- npx -y render-useful-mcp. Claude Code defaults to local scope, which registers the server for the current directory only, which is why a server added without the flag appears to be missing in other projects.

Q: Is render-useful-mcp official?

No. It is an independent, unofficial open-source project and is not affiliated with Render. Render publishes its own Claude Code plugin, which takes a different approach; the two are complementary.

Q: Does render-useful-mcp send my Render API key anywhere?

No. The server runs on your machine and contacts exactly one host, Render's API. The key is read from the environment, never written to disk, and redacted from log output. There is no telemetry, no analytics and no backend.

Install

Claude Code — globally

claude mcp add render --scope user \
  -e RENDER_API_KEY=rnd_your_key \
  -- npx -y render-useful-mcp

--scope user is the part that matters. Claude Code defaults to local scope, which registers the server for the current directory only — so it works where you installed it and is missing everywhere else. That is the usual reason a freshly added MCP server seems to disappear. Confirm with claude mcp list from an unrelated directory.

Scope	Flag	Where it lives	Available in
User (global)	`--scope user`	your user configuration	every project, every directory
Project	`--scope project`	`.mcp.json`, committed	anyone who checks the repo out
Local	none (default)	per-directory user state	the directory it was added from

Claude Code — as a plugin

Wires up the server and its docs in one step. Plugins are installed for your user, so this is global by nature.

/plugin marketplace add LuSrodri/render-useful-mcp
/plugin install render-useful-mcp@lusrodri-render

Export RENDER_API_KEY in the shell that launches Claude Code; the plugin reads it from the environment rather than storing it.

Claude Desktop, and any client using `mcpServers`

{
  "mcpServers": {
    "render": {
      "command": "npx",
      "args": ["-y", "render-useful-mcp"],
      "env": {
        "RENDER_API_KEY": "rnd_your_key_here",
        "RENDER_WORKSPACE_ID": "tea_your_workspace_id"
      }
    }
  }
}

Claude for macOS and Windows — desktop extension

Download the .mcpb bundle from the latest release and open it. Claude installs it and asks for the API key in a form. The bundle ships its own dependencies, so it needs neither npm nor a Node install.

Get an API key from Render Dashboard → Account Settings → API Keys. Everything except the desktop extension needs Node.js 20.11 or newer. Setting RENDER_WORKSPACE_ID is optional but recommended: many Render endpoints need an ownerId the model cannot guess, and setting it removes a lookup from nearly every session.

Creating a Docker cron job

The case models most often got wrong, and the one this server works hardest to make obvious. A Render cron job is a service, so it is created with render_create_service:

{
  "type": "cron_job",
  "name": "nightly-report",
  "ownerId": "tea-…",
  "repo": "https://github.com/acme/reports",
  "branch": "main",
  "serviceDetails": {              // the cronJobDetailsPOST branch
    "runtime": "docker",
    "schedule": "0 3 * * *",       // five-field cron, UTC, required
    "plan": "starter",
    "region": "oregon",
    "envSpecificDetails": {        // dockerDetails, because runtime is docker
      "dockerfilePath": "./Dockerfile",
      "dockerContext": ".",
      "dockerCommand": "python report.py"
    }
  }
}

For a prebuilt image instead of a build, drop repo/branch, set image to {"ownerId": "tea-…", "imagePath": "docker.io/acme/reports:latest"}, use "runtime": "image", and give envSpecificDetails only the dockerCommand. Change the schedule later with render_update_service; trigger an off-schedule run with render_run_cron_job. render_create_job is a different thing — a one-off command on an existing service.

Built to be used by a model

A generated tool is only as good as what the spec says about it, and Render's spec describes shapes rather than usage. Three things close that gap.

`oneOf` branches keep their names

Inlining a $ref normally discards the schema's name, leaving serviceDetails as five anonymous, structurally similar objects. Each branch now carries its name from Render's spec, so cron_job → cronJobDetailsPOST is a decision a model can actually make.

Hand-written usage notes

A small set of operations carry an appended Usage: paragraph — a full worked example for creating a service, a warning that env-var updates replace the whole set. The build fails if a note names an operation Render has withdrawn.

Server instructions

Id prefixes, resolve-the-name-first, which workflow tool replaces which raw sequence — sent once at initialize, rather than duplicated into every tool description that needs it.

Toolsets

Every toolset is enabled by default — the server exposes everything your API key is allowed to reach. Toolsets exist to narrow the surface on purpose, via RENDER_MCP_TOOLSETS, not to gate it. RENDER_MCP_READ_ONLY=true hides every mutating tool outright.

Toolset	Tools	Covers
`services`	42	Services, deploys, custom domains, one-off jobs, cron job runs and events
`metrics`	23	CPU, memory, bandwidth, HTTP, disk and connection metrics, plus metrics streams
`postgres`	21	Postgres instances, users, exports, recovery and query insights
`workflows`	15	Render Workflows and workflow tasks (public beta)
`env-groups`	13	Environment groups, their variables and secret files
`projects`	12	Projects and environments
`webhooks`	11	Webhooks and notification settings/overrides
`logs`	10	Log queries, label discovery and log stream configuration
`static-sites`	9	Header rules and redirect/rewrite routes for static sites
`deprecated`	8	Legacy Redis endpoints that Render has superseded by the Key Value API
`key-value`	8	Key Value (Redis-compatible) instances and connection info
`workspaces`	8	Workspaces, members, the authenticated user and audit logs
`disks`	7	Persistent disks and their snapshots
`blueprints`	6	Blueprints and Blueprint syncs
`network`	5	Dedicated outbound IP sets
`registry`	5	Container registry credentials
`maintenance`	4	Scheduled maintenance runs

Workflow tools

Always available, in any toolset configuration. They exist because the equivalent raw sequence is several calls a model usually gets wrong on the first try.

Tool	What it does
`render_find_service`	Resolves a service name — including a partial or approximate one — to a single Render service, returning its id plus close alternatives.
`render_recent_logs`	Fetches recent log lines for a service, resolving the service name and workspace id for you.
`render_service_status`	One-call triage for a service: its configuration, latest deploys, running instances and most recent error-level logs.
`render_toolsets`	Lists every Render toolset with its tool count and whether it is currently enabled.
`render_wait_for_deploy`	Polls a deploy until it reaches a terminal state (live, build_failed, update_failed, canceled, deactivated) or the timeout expires.

Configuration

Variable	Default	Description
`RENDER_API_KEY`	—	Required. Your Render API key.
`RENDER_WORKSPACE_ID`	—	Workspace id used wherever an `ownerId` is needed and none was given.
`RENDER_MCP_TOOLSETS`	`all`	Narrow the surface to a comma-separated list of toolsets.
`RENDER_MCP_READ_ONLY`	`false`	Expose only non-mutating tools.
`RENDER_MCP_DYNAMIC_TOOLSETS`	`true`	Register `render_toolsets`, which reports the toolsets and their state.
`RENDER_MCP_TIMEOUT_MS`	`60000`	Per-request timeout.
`RENDER_MCP_MAX_RETRIES`	`3`	Retries for rate limits and transient server errors.
`RENDER_MCP_MAX_RESPONSE_BYTES`	`400000`	Larger tool results are truncated with a note.
`RENDER_MCP_LOG_LEVEL`	`info`	`debug`, `info`, `warn`, `error`, `silent`. Logs go to stderr.
`RENDER_API_BASE_URL`	`https://api.render.com/v1`	Override for proxies or testing.

Questions

Why did my MCP server disappear after I changed directory?

It was installed in local scope, which is Claude Code's default and is per-directory. Re-run the install with --scope user to register it globally.

Is this official?

No. It is an independent open-source project and is not affiliated with Render. Render publishes its own Claude Code plugin at render-oss/render-plugin-claude-code, which takes a different approach — hand-written skills and agents for common workflows. This one is generated from Render's OpenAPI document and exposes the complete API surface, so the two are complementary rather than alternatives.

Where does my API key go?

To Render, and nowhere else. The server runs on your machine and contacts exactly one host. The key is read from the environment, never written to disk, and redacted from log output. No telemetry, no analytics, no backend — see PRIVACY.md.

How does it keep up with the Render API?

A scheduled GitHub Actions workflow re-fetches Render's published API description daily, regenerates the tool catalogue and this documentation, and opens a pull request when the set of tools actually changes — with a summary of what was added, removed or reshaped. Nothing merges automatically, because a new Render endpoint can be a breaking change.

Can I stop an agent from changing anything?

Set RENDER_MCP_READ_ONLY=true. Mutating tools are then not exposed at all, rather than merely discouraged. Short of that, every tool carries MCP readOnlyHint, destructiveHint and idempotentHint annotations derived from real HTTP semantics, so a client can make sensible auto-approval decisions.

For AI agents

This site publishes llms.txt and llms-full.txt, and registers WebMCP tools in supporting browsers so an agent reading this page can search the tool catalogue, produce an install command, or fetch a worked example directly. All of it is generated from the same catalogue the server ships.