Install
openclaw skills install @ojusave/render-on-hermesUse whenever any other render-* skill loads, or any time the user asks you to do something on Render. Tells you that this Hermes container has the Render MCP server pre-registered with full MCP tool access for the provided API key and that the render CLI is NOT installed in this image, so skip every "install MCP", "install CLI", and "run render CLI" step that upstream render-* skills describe.
openclaw skills install @ojusave/render-on-hermesThis Hermes deployment is pre-wired for Render. The other render-* skills
(pulled from github.com/render-oss/skills) are written for generic AI coding
tools like Cursor and Claude Code, so they assume you might need to install the
CLI or configure MCP yourself. Skip all of that. Use this skill as the
source of truth for what is wired up here, what is NOT, and what to do when an
upstream skill assumes something that isn't true on this host.
| Capability | State on this container |
|---|---|
| Render MCP server | Registered in config.yaml as render |
| MCP transport | HTTP, https://mcp.render.com/mcp |
| MCP auth | Authorization: Bearer ${RENDER_MCP_API_KEY} (lazy-substituted) |
| MCP tool scope | Full MCP tool access for the provided API key |
| Render CLI | Not installed. See "About the render-cli skill" below |
| Skill bundle | github.com/render-oss/skills at a pinned commit, exposed via skills.external_dirs |
The render MCP server is registered without a tools.include filter. You
can see every MCP tool that the provided RENDER_MCP_API_KEY can use,
including tools that mutate resources (restart_service, update_service,
update_environment_variables, trigger_deploy, create_web_service,
query_render_postgres, etc.).
Selecting a workspace is required context for many MCP calls. If no workspace
is selected, call mcp_render_list_workspaces and choose the obvious workspace
if there is only one. If there are multiple plausible workspaces, ask the user
which one to use. Do not block inspection just because workspace selection is
needed.
If the user asks you to mutate Render resources, treat the request as allowed
by this setup, but be explicit about the effect before acting. The real
permission boundary is the Render role behind RENDER_MCP_API_KEY and who can
reach the Hermes dashboard.
render-cli skill (and why it's misleading here)The upstream skill bundle includes a render-cli skill that describes how to
use the render binary for things MCP can't do (live log streaming,
render psql, SSH into running instances, etc.). The CLI is not installed
in this container. If the upstream render-cli skill loads, treat its
commands as a reference for what the USER can run from their own machine,
not for what you can run yourself.
When the user asks you to do something the upstream skill says needs the CLI:
list_logs instead of render logs,
get_metrics instead of render metrics, etc.psql,
SSH session, image-backed service creation), draft the CLI command and
hand it to the user to run from their own shell. Don't try to run it
from your terminal tool — the command will fail with "render: command
not found".RENDER_API_KEY. Download and inspect installer scripts
before running them.Hermes prefixes MCP tools with mcp_<server>_<tool>. So when an upstream
skill says "call list_services()", on Hermes you call:
mcp_render_list_services()
You usually don't need to type the prefix yourself — the agent picks the
right tool from descriptions. But when reading the upstream skill catalog,
mentally map every bare MCP tool name (list_services, get_metrics,
list_logs, query_render_postgres, etc.) to mcp_render_<name>.
When loading any other render-* skill, ignore these sections entirely —
they're already handled (or deliberately not handled):
render. If mcp_render_list_services
works, you're done.curl ... install.sh
→ CLI is deliberately NOT installed. See the section above.render login or set RENDER_API_KEY"
→ Neither applies. MCP uses RENDER_MCP_API_KEY and reads it lazily
from the gateway env via config.yaml substitution.mcp_render_get_selected_workspace first; if none is selected, call
mcp_render_list_workspaces, then mcp_render_select_workspace for the
only/obvious workspace. Ask the user only when multiple workspaces are
plausible.If anything looks broken, the only check that matters is whether MCP works:
mcp_render_list_services()
If that returns a list, MCP is wired up and the agent can read workspace
state. If it returns 401 or doesn't appear as a registered tool at all,
the gateway didn't see RENDER_MCP_API_KEY at startup. Tell the user to
add it under Environment in the Render Dashboard and Restart
gateway on the Hermes Status tab.
render-deploy, then render-blueprints if multi-servicerender-debugrender-monitorrender-web-services, render-background-workers, render-cron-jobs, render-static-sites, render-private-services, render-workflows skillrender-postgres or render-keyvaluerender-migrate-from-herokurender-cli for reference,
but don't try to run the commands yourself (see "About the render-cli skill" above)One subtlety: this Hermes container is itself a Render web service. If the user asks you to "look at this service" without naming one, they usually mean the very service you're running inside. Find it with:
mcp_render_list_services()
…and look for the service name they used when they deployed this template
(default: hermes). Don't suggest changes to that service casually. Restarting
it kills your own session.