Render Useful MCP

Written in TypeScript. Every API tool is generated from Render's own OpenAPI document, so coverage is complete by construction and stays that way.

212 tools: all 207 operations of the Render Public API (spec version 1.0.0), plus 5 workflow tools for the sequences the raw API makes tedious.

Most API wrappers stop at a curated subset of endpoints, which drifts out of date and leaves you stuck the moment you need something the author skipped.

- Complete, by construction.Every operation in Render's own OpenAPI document becomes a tool. Everything the API allows your key to do is reachable out of the box — no opt-in required.
- Usable by a model.Names resolve to ids fuzzily, your workspace id is filled in automatically, deploys can be waited on in one call, and failures come back with a hint instead of a bare status code.
- Narrowable when you want it.Every toolset is on by default;RENDER_MCP_TOOLSETSandRENDER_MCP_READ_ONLYexist to restrict the surface deliberately, not to gate it.
- Honest about risk.MCP destructive/read-only/idempotent annotations are derived from real HTTP semantics, so clients can make sensible auto-approval decisions — including thePUTs that replace a whole collection, where everything the caller omits is deleted. Secrets are redacted from logs.

Both buttons prefill the config with a placeholder API key — replace it after install.

Claude Code— install it globally, so it is there in every project:

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

--scope useris the part that matters. Claude Code defaults tolocalscope, which registers the server for the current directory only — so it works where you installed it and is missing everywhere else, which is the usual reason a freshly added server seems to disappear. The three scopes are:

Confirm withclaude mcp list, and re-run the command with--scope userifrenderis not listed from an unrelated directory.

Claude Code, as a plugin — this wires up the server and its docs in one step, and plugins are installed globally by nature:

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

Desktop installs default to theservices,logsandenv-groupstoolsets rather than the whole catalogue, because every tool definition costs context in every conversation. Set theToolsetsfield toall, or to any comma-separated list, to change that.

Requires Node.js ≥ 20.11 for every install route except the desktop extension.

Or run it without installing, which is what most MCP client configs do:

Get an API key fromRender Dashboard → Account Settings → API Keys.

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

AddRENDER_WORKSPACE_IDthe same way if you know it:

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

Claude Desktop / any client usingmcpServers— add to the config file:

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:

oneOfbranches keep their names, and say which one applies.Dereferencing a$refnormally throws away the schema's name, which leavesserviceDetailsonrender_create_serviceas five structurally similar anonymous objects with nothing to say which one goes with whichtype. Each branch now carries its name from Render's spec as atitle, socron_job→cronJobDetailsPOSTandruntime: docker→dockerDetailsare decisions a model can actually make.

Creating a cron job that runs a Docker image

The case that motivated all three. A cron job is a service, so:

// 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 for cron jobs "plan": "starter", "region": "oregon", "envSpecificDetails": { // the dockerDetails branch, because runtime is docker "dockerfilePath": "./Dockerfile", "dockerContext": ".", "dockerCommand": "python report.py", }, }, }

npm install npm run generate # rebuild the tool catalogue from the OpenAPI spec npm run docs # re-render every doc that quotes the catalogue npm run build npm test npm run check # generate + docs + lint + typecheck + test

- 47 5 , not0 6 1.GitHub queues scheduled workflows best-effort and drops them under load; the top of the hour is the most contended slot there is. The one observed scheduled run started nearly four hours late. Daily, at an unremarkable minute, makes a dropped run cost a day rather than a fortnight — and a run that finds no catalogue change exits early, so the cost of daily is a few seconds of CI.
- .github/spec-sync-heartbeat.json.GitHub disables scheduled workflows in repositories that go 60 days without activity, and a disabled workflow cannot re-enable itself. The workflow commits a timestamp to that file whenever the recorded one is more than 20 days old — roughly 18 commits a year, which keeps the clock well clear of the limit and leaves a visible record in the git log that the routine is alive.

To do it by hand, or to check right now:

npm run sync-spec # fetch the current spec into spec/render-openapi.json npm run generate # rebuild the catalogue from it git diff src/generated/operations.json npm test

Render does not serve its OpenAPI document from a stable URL — the documented.jsonand.yamlendpoints 404 — soscripts/fetch-spec.tsextracts it from the docs HTML. That is fragile by nature, so it validates what it extracts (title, server, minimum operation count) and fails loudly rather than overwriting a good spec with a truncated one. If Render changes their docs platform, the sync workflow goes red instead of quietly reporting "no changes" forever.

The generator refuses to emit a catalogue it cannot fully understand — an unmapped tag, a name collision, a cyclic$ref, a path parameter missing from its template, or a body property that would shadow a query parameter all fail the build. CI additionally asserts that the committed catalogue matches what the spec produces, so a spec update without a regenerate cannot merge.

npm version patch # or minor / major git push --follow-tags

Pushing avtag runs.github/workflows/publish.yml, which verifies the tag matchespackage.jsonand that the generated catalogueand documentationare current, works out which of the two targets still need this version, then lints, type-checks, tests, builds and publishes. It also builds the.mcpbbundle and attaches it to the GitHub Release, which is the only place the desktop extension is distributed from.

If a release fails for a reason outside the code, re-run it from the Actions tab viaRun workflow, selecting the tag underUse workflow from*. Each target is checked independently, so a retry after a half-finished release skips whatever already succeeded instead of failing on npm's immutable versions. The workflow rejects dispatches from a branch, so a published version always corresponds to a tag.

server.jsonis the registry's copy of this server's metadata. Two of its fields are load bearing and both are asserted bytest/server-json.test.ts:

- namemust beio.github.LuSrodri/.... The registry derives the namespace you may publish to from the OIDC token'srepository_ownerclaim and compares it case sensitively, so the lowercased spelling is rejected with a 403.
- mcpNameinpackage.jsonmust equal that same name. It is the ownership proof described above; without it the registry refuses the package.

The version fields trackpackage.json—npm versionkeeps them in step via theversionlifecycle script, somcp-publisher publishalso works from a clean local checkout. CI stamps them from the tag again before publishing, so the tag is what decides what ships.

Not affiliated with Render.spec/render-openapi.jsonis Render's published API description, vendored so builds are reproducible.

This is a web browser that enables your coding agent, such as Claude Code, to visit websites on your behalf and assist you in identifying bugs or creating UI test cases.

Create crafted UI components inspired by the best 21st.dev design engineers.

Bring agent evaluations, observability, and synthetic test set generation directly into your IDE for free with Galileo's new MCP server

An MCP server to help AI assistants to answer questions and generate AccelByte Extend SDK code more effectively .

MCP server for AI Diagram Maker — generate beautiful software engineering diagrams directly inside Cursor, Claude Desktop, Claude Code, or any MCP-compatible AI agent