Render on Hermes

This 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.

What's already done for you

Default scope: full MCP access

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.

About the 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:

• If an MCP equivalent exists, use that. list_logs instead of render logs, get_metrics instead of render metrics, etc.
• If no MCP equivalent exists (live log streaming, interactive 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".
• If the user really needs the agent to drive the CLI, ask before installing anything or adding RENDER_API_KEY. Download and inspect installer scripts before running them.

How MCP tools appear

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>.

Steps to skip in other render-* skills

When loading any other render-* skill, ignore these sections entirely — they're already handled (or deliberately not handled):

• "Set up Render MCP" / "Add to ~/.cursor/mcp.json" / "claude mcp add" → MCP is already configured as render. If mcp_render_list_services works, you're done.
• "Install Render CLI" / "brew install render" / curl ... install.sh → CLI is deliberately NOT installed. See the section above.
• "Run 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.
• "Pick a workspace" → Still applies. Call 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.

Quick verification

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.

When to load which skill

• Deploying something new → render-deploy, then render-blueprints if multi-service
• A live service is misbehaving → render-debug
• Health/metrics dashboards → render-monitor
• Picking the right resource type (web vs worker vs cron, etc.) → the matching render-web-services, render-background-workers, render-cron-jobs, render-static-sites, render-private-services, render-workflows skill
• Picking the right datastore → render-postgres or render-keyvalue
• Networking / domains / disks / scaling → the same-named skill
• Migrating off Heroku → render-migrate-from-heroku
• "How do I do X from the command line" → consult render-cli for reference, but don't try to run the commands yourself (see "About the render-cli skill" above)

You are running ON Render

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.