How to connect RunPod to Hermes Agent

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.

Reconnect RunPod from the dashboard, then start a fresh chat if the runtime still has the old tool catalog loaded.

RunPod tool schemas load on demand the first time a tool runs and are cached after that, so this error usually clears on its own: wait a few seconds and retry the same request. If every RunPod call keeps failing with it in a fresh chat, reconnect from the dashboard, and contact support if it still persists — that pattern points to a configuration problem on our side, not something you can fix by reconnecting again.

Two usual causes. The connected account may not have access to the specific workspace, inbox, store, or project in the request — check that first. If access looks right, the agent may have sent a placeholder value (like "YOUR_ID" or an example id from documentation) instead of a real one: ask it to run a list or search tool first, then retry the action with a real id from those results. Most failures at this stage are one of these two, not ClawLink bugs.

The causes the engines teach for this error are the real ones, and they replace the workspace-and-inbox theory that used to sit here, RunPod has no such concepts. First, the key's permissions: RunPod launched fine-grained scoped API keys, and a key without the permission for an action fails exactly that action. Second, team roles: Billing cannot connect to existing Pods, Basic cannot create or start them, and Dev and Admin have broader permissions, so the account behind the key decides what the agent can do. Third, ownership: a pod, endpoint, or cluster owned by another team fails like a permission error rather than a not-found. Then the hosted-flow causes: a placeholder id, a pod or endpoint id from documentation instead of from runpod_get_pod or runpod_get_myself, and SSH key configuration where pod access is involved, a fingerprint pasted instead of the public key, or the ssh-ed25519 prefix omitted.

Ask the agent to diagnose it:

Call runpod_get_myself and tell me which RunPod account and role this connection acts as, then quote the exact error and the id from the failed call. Do not retry it yet.

The fixes search results give for this symptom assume a locally configured MCP server, editing a client config file and restarting, which does not exist in this setup. Two hosted-flow causes cover it instead: schemas load on demand, so the opening RunPod call in a fresh session can arrive before the catalog and needs one retry, and if Hermes shows no RunPod tools at all the pairing is incomplete, so confirm the plugin was installed with --enable and that both hermes clawlink begin and hermes clawlink finish ran. If most tools work and a single name fails, the name is wrong rather than missing, and the error lists the closest real ones.

Ask the agent to diagnose it:

List the RunPod tools you actually have access to. If there are none, say so plainly and tell me whether `hermes clawlink test` passes. If one name failed, quote it and the closest names from the error.

The engines teach two causes for this shape and both are key-entry mistakes: the fingerprint was pasted where the public key belongs, or the public key was added without its ssh-ed25519 prefix, which makes the key unparsable. The fix is RunPod-side, adding the key correctly to the pod, not reconnecting this connection. If the key looks correct, the remaining cause is ownership: the pod belongs to a team the connected account cannot reach, which surfaces as a permissions error on the pod tools while the rest of the connection works.

Ask the agent to diagnose it:

Tell me which pod and which tool failed, and quote the exact error. If the error mentions a key, tell me whether the key starts with ssh-ed25519 and whether you added it as a public key or a fingerprint.

Double-check that the API key for RunPod has the right scopes or account access. A valid key can still be too limited for some reads or writes.

Yes. ClawLink is the fastest way to connect Hermes to RunPod: link your RunPod account once in the browser and Hermes Agent can call the RunPod API through 13 ready-made tools — no custom code or token handling.

Install the plugin with hermes plugins install ClawLink-HQ/hermes-plugin --enable, then pair once: run hermes clawlink begin, approve the link in your browser, and run hermes clawlink finish. Connect RunPod in the dashboard and Hermes can use it from the next message — no config files, and the RunPod key you paste is stored server-side instead of in your environment.

About two minutes. Sign in, click Connect next to RunPod in the dashboard, authenticate, and Hermes Agent can use it from the next chat message.

The alternative to ClawLink is usually manual API key setup plus your own token handling, permission troubleshooting, and tool plumbing for Hermes Agent. That is fine if you want to build and maintain the integration yourself. Most teams just want RunPod working from chat.

The official server is the unanimous answer to every "best RunPod MCP" query, and it deserves the name check: npx -y @runpod/mcp-server@latest runs a server that needs your RUNPOD_API_KEY in your own environment, and you maintain that setup per machine and per client. Underneath, both routes hit the same RunPod API. Here the key is pasted once on a hosted setup page and stored server-side, the tools appear after the pairing handshake, and there is no server process, config file, or environment variable for you to maintain. Choose on how much you want to run, not on which API the tools talk to.

Account-level infrastructure: runpod_create_cluster and runpod_get_pod for compute, runpod_save_endpoint and runpod_save_template for the serving layer, runpod_create_secret and runpod_save_registry_auth and runpod_update_registry_auth for credentials and image pull access, and runpod_get_gpu_types and runpod_list_cpu_types for capacity planning, with runpod_get_myself reporting which account the connection acts as. Reads come first in the tool set, which is the right shape: know what the account has before creating anything.

No, and naming that is the honest part of this page. The setup search engines teach for running models, a pod serving Ollama or vLLM that Hermes points at as an OpenAI-compatible provider, is a different flow from this one and this connection does not replace it. What this connection does is manage the RunPod account from chat: pods, clusters, endpoints, templates, secrets, and registry auth. If your goal is Hermes calling a model on a RunPod pod, the manual model-host route is what the engines teach; if your goal is managing the RunPod account itself, that is this page.

The engines' safety answers all land on the same controls: scoped keys, spend limits, least privilege, and human approval on destructive actions. On this connection the key is stored server-side rather than in an env file on a machine, disconnecting from the dashboard revokes the agent's use of it immediately, and the agent acts with the permissions of the RunPod user the key belongs to, so a key from an account without billing or admin access is itself a ceiling. RunPod's own scoped keys are a taught practice for manual setups; whatever key you paste here is the one the agent inherits.

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.