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

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

This is a Postgres error, and it means the acting role has no policy permitting the insert. Two mechanics trip people up. First, an insert checks both the INSERT policy and the SELECT policy on the table, because Postgres must be able to read back what it wrote; a table with an INSERT policy but no SELECT policy fails on this exact error. Second, the acting role matters: the read tools run as supabase_read_only_user, and a write attempt through supabase_beta_run_sql_query runs as the role the connection maps to, so a policy written for authenticated users may not cover either. The fix is a policy change in the Supabase dashboard, and it is the one error in this list that no reconnect will cure, because the connection is not bypassing RLS on purpose.

The manual-flow answers teach key mechanics: wrong key type (anon vs service_role), malformed apikey header, or a key revoked on the dashboard. None of those exist here, because no key is stored on your side. A 401 on a connected account means the OAuth grant is stale: it was revoked in your Supabase account, the refresh failed, or the account was changed. Reconnect Supabase from the ClawLink dashboard to re-run the consent flow and replace the grant. If reads work but one specific tool 401s, check that tool's requirement instead, since some platform endpoints expect project-level access the grant may not carry.

Both of these are errors from the manual MCP + OAuth setup, and their presence is how you can tell which world you are in. "redirect_url not allowed" is Supabase refusing a callback URL that was not registered on the OAuth app, which is exactly the localhost callback pain the search results teach. "Required parameter: client_secret" is the token exchange failing because the secret never made it into the local config, which is the known pain point behind the NousResearch hermes-agent GitHub issue titled "MCP OAuth fails with Supabase". A hosted connection cannot produce either error, because there is no OAuth app to register and no callback URL in the flow. If your agent reports them, you are running a local MCP setup and this page's flow is the alternative.

Search results blame an expired OAuth session, silent authentication failures, or missing access tokens in a local MCP configuration. There is no local MCP configuration here, so the cause is lazy schema loading: Supabase tool schemas hydrate on demand the first time a tool runs, and a call in a fresh chat can arrive before the catalog does. Retrying once resolves it. If the same name fails twice, the name is wrong rather than missing, and the error message lists the closest real tools. Reconnect from the dashboard if every Supabase call keeps failing in a fresh chat.

Try reconnecting Supabase and complete the consent flow in the same browser session. Partial OAuth approvals or switching accounts mid-flow can leave the connection incomplete.

Yes. ClawLink is the fastest way to connect Hermes to Supabase: link your Supabase account once in the browser and Hermes Agent can call the Supabase API through 116 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 Supabase in the dashboard and Hermes can use it from the next message — no config files or API keys to manage.

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

The alternative to ClawLink is usually manual OAuth app 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 Supabase working from chat.

Neither. The anon key and service_role key are the two credentials of the manual setup: you paste one into an env file and hope it never leaks, and the service_role key in the wrong hands is the danger every safety answer warns about. This connection is an OAuth grant against your Supabase account, so no key string ever sits in a file next to your agent. The data tools use their own narrow roles: supabase_run_read_only_query and supabase_select_from_table execute as the supabase_read_only_user role with read-only operations, and supabase_beta_run_sql_query runs the SQL you send against the project database. There is nothing to leak, because there is no key.

Yes, and this is the sentence the engines keep omitting: a connected account does not bypass row-level security. The read tools run as the supabase_read_only_user role, and Postgres applies RLS policies to that role exactly as it does to any other. If a query returns no rows when you expect data, or an insert fails with "new row violates row-level security policy", the missing piece is a policy for that role, not a broken connection. Supabase's default is deny-all when RLS is enabled with no matching policy, so an empty result is frequently the policy working as designed.

The standard answer is "yes if you use strict RLS and never expose the service_role key", and this connection removes the second condition by never holding the key in the first place. What you get instead is an account-level grant, which is broader than a narrow database role: the agent can administer projects, deploy edge functions, run migrations, and manage branches through the platform tools, while table data stays guarded by RLS. Treat the connection as admin-level, keep RLS strict, and treat prompt injection the same way you would for any agent that can write: the agent reading a database row is reading text written by someone, and that text can contain instructions aimed at it.

No. The connection targets supabase.com hosted projects through Supabase's platform OAuth. A self-hosted Supabase instance needs its own database credentials and a network path to it, which this flow does not provide.

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.