How to connect Prisma 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 Prisma from the dashboard, then start a fresh chat if the runtime still has the old tool catalog loaded.

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

Every engine answers this for the wrong product: ChatGPT cites Prisme.ai's docs three out of three runs, and the rest of the search results teach Prisma Cloud token mechanics, JWTs that expire in minutes. Neither applies here. On this connection the credential is a Prisma Data Platform key pasted once and held server-side, and the failure that matches your symptom is a credential that went stale: expired, rotated, or revoked at the platform, which makes every tool 401 while the dashboard still shows a connection. The fix is the one ChatGPT lands on for its own wrong product, disconnect and reconnect from the ClawLink dashboard, which re-issues the credential. If only some calls fail, the credential is valid and the error is permission, see the 403 card.

Ask the agent to diagnose it:

Call prisma_list_projects and quote exactly what it returns including the status code. Do not retry the failing tools until we have that result.

The engines answer this with Prisma Cloud semantics, role configuration and feature licenses for a security platform, which does not describe this integration. For the Data Platform the real causes line up as: workspace and project membership, the connected account can only see workspaces and projects it belongs to, so a project from another workspace fails as a permission error rather than not-found; and placeholder ids, a project or database id from documentation, which fail exactly the same way because the object is not in the connected scope. If the agent can list some projects and not others, it is almost always membership: the missing project lives in a workspace the connected account does not have access to.

Ask the agent to diagnose it:

Call prisma_list_workspaces and prisma_list_projects and tell me which succeeds and which ids you can see. Then quote the exact error from the failed call and which id it involved.

If Hermes shows no Prisma tools, the connection or pairing is incomplete: confirm the plugin was installed with --enable, both hermes clawlink begin and hermes clawlink finish ran, and Prisma shows as connected in the dashboard. If most tools work and a single name fails, the name is wrong, and the error lists the closest real ones. There is also the first-call timing case unique to this setup: schemas load on demand, so the opening Prisma call in a fresh session can arrive before the catalog and needs one retry. The standard advice for this symptom, which assumes a locally declared MCP server in a client config, does not apply.

Ask the agent to diagnose it:

List the Prisma tools you actually have access to. If there are none, say so plainly. If there are, tell me which one lists projects and use that exact name.

Double-check that the API key for Prisma 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 Prisma: link your Prisma account once in the browser and Hermes Agent can call the Prisma API through 22 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 Prisma in the dashboard and Hermes can use it from the next message — no config files, and the Prisma key you paste is stored server-side instead of in your environment.

About two minutes. Sign in, click Connect next to Prisma 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 Prisma working from chat.

Three products share the name and it costs a searcher a real amount of time. This page is the Prisma Data Platform: Prisma's managed Postgres, Accelerate, and the cloud console where projects, databases, and backups live. Palo Alto Networks' Prisma Cloud is a cloud security platform, and it is what Google answers with for "prisma api 401", "prisma api 403", and "prisma api rate limit" queries, none of which describe this integration. Prisme.ai is an unrelated French automation vendor, and ChatGPT's invalid-token answer cites its docs (docs.prisme.ai) three out of three runs. If you arrived looking for either of the other two, neither is this page.

The setup search results teach is a connection string with the API key inside it, prisma://accelerate...?api_key=, placed in an environment file, and ChatGPT's no-credentials answer is to build a server-side tool wrapper so the agent "never receives" that string at all. That wrapper is what the hosted flow is: a Prisma Data Platform API key is pasted once into the dashboard and held server-side, and the agent calls the tools instead of holding a connection string. You still own the account and the key, you just do not manage the key's journey to the agent.

Only through one specific tool, and it is important to know which. prisma_execute_sql_query is SELECT-only, which is the tool for every read question. prisma_execute_sql_command executes SQL that modifies database data or structure, and it is a write: it goes through the confirmation gate like other writes in ClawLink, so the agent stops and you approve the exact statement before anything changes. The rest of the toolset is management reads and writes: creating databases and projects, restoring backups, transferring project ownership, all real changes with the same gate.

The mainstream answer to this shape is "don't give the agent real database access", and the tool split here is the practical version of that advice. Reads are the default: the agent lists, inspects, and runs SELECT queries, which covers the questions people actually ask (what tables exist, what the schema says, what is in this table). Writes exist but are narrow and gated: prisma_execute_sql_command for modifying SQL, plus create, restore, and transfer tools, all of which require confirmation. The hosted layer adds the credential benefit, one key held server-side and revoked from the dashboard, and the honest caveat: a SELECT-only agent can still read everything the connected account can read, so connect with the account whose access you actually want the agent to have.

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.