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

ClickHouse 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 ClickHouse 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 old "workspace or inbox access" explanation never applied to ClickHouse; the real causes are grants, roles, and policies, and Perplexity's answer to this query is the map. A missing SELECT grant on the table is the first thing to check, and the diagnostics are two SQL statements the agent can run: SHOW GRANTS to see exactly what the connected user holds, and SELECT currentUser() to confirm which user the connection actually is, because pasting a key for user A while assuming user B is a classic hosted mistake. Beyond grants: RBAC roles that are not enabled for the user, row policies that silently filter or reject rows, host and network restrictions on the credential, and a wrong database or role in use for the session. Each of those has a different fix, so the agent should quote the error and run the diagnostics before anything is reconnected.

Ask the agent to diagnose it:

Run SELECT currentUser() and SHOW GRANTS through clickhouse_execute_query and tell me exactly which user and grants this connection carries. Then quote the failing query's error. Do not retry the failing query yet.

ClickHouse Cloud documents platform rate limits on its Management API (the key-and-secret administration surface) and can return HTTP 429 when traffic exceeds what the plan allows; a self-managed server instead hits whatever its own settings cap, like max_concurrent_queries. An agent running one query per table across a large inventory is the traffic shape to watch, and the fix is to batch: schema reads before row reads, LIMIT on exploratory queries, and clickhouse_get_database_schema instead of ad-hoc SHOW runs. The 429 tells the agent when to retry, so have it report the response rather than hammering.

Ask the agent to diagnose it:

Tell me how many queries you ran in the last minute and what you were inventorying. Quote the exact 429 or connection error. Do not query ClickHouse again until I reply.

The engines' answer to this symptom is self-hosted MCP mechanics: uv not on PATH, missing environment variables, not restarting the client. None of that exists in this flow, because there is no local MCP server to hydrate. The hosted causes are the two real ones: the connection or pairing is incomplete (confirm the plugin installed with --enable, both pairing commands ran, and ClickHouse shows as connected), or schemas load on demand, so the first ClickHouse call in a fresh session can arrive before the catalog and needs one retry. If most tools work and one name fails, that name is wrong rather than missing, and the error lists the closest real ones.

Ask the agent to diagnose it:

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

A connection that works but returns nothing is usually a scoping problem, not a network one. The credentials may belong to a user whose grants cover the catalog but not the data: SHOW DATABASES succeeds while SELECT on a table the user cannot read returns an empty or filtered set, often because a row policy is silently constraining it. The second cause is the classic one with ClickHouse: querying the wrong database or cluster, or a schema that changed since the agent's last clickhouse_get_table_schema call, so its column list is stale. Have the agent re-run the schema tool and SELECT currentUser() before reconnecting, because neither of these fixes on the connection side.

Ask the agent to diagnose it:

Run clickhouse_list_databases and tell me what the connection can see, then SELECT count() from the table in question and quote the exact result or error. Do not reconnect yet.

Re-enter the credentials carefully and verify the account-level permissions for ClickHouse. Basic and token-based integrations tend to fail on formatting mistakes or limited account roles.

Yes. ClawLink is the fastest way to connect Hermes to ClickHouse: link your ClickHouse account once in the browser and Hermes Agent can call the ClickHouse API through 6 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 ClickHouse in the dashboard and Hermes can use it from the next message — no config files, and the ClickHouse key you paste is stored server-side instead of in your environment.

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

The alternative to ClawLink is usually manual credential 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 ClickHouse working from chat.

ClickHouse's auth is not a single key. ClickHouse Cloud uses Key ID + Key Secret, sent as HTTP Basic credentials, generated in the Cloud Console under Organization Settings; a self-managed server uses a username and password instead. Both work here: paste whichever pair fits your setup into the hosted connect form once. This is why the page says a credential pair rather than "one key": anyone telling you ClickHouse takes a single API key is describing a different product. The pair is stored server-side, never written to a local env file, and re-pasting is the entire rotation story.

The engines ask this question back at searchers, because the two answer differently. ClickHouse Cloud is a hosted service where you create Key ID and Key Secret pairs in the console and connect over port 8443. Self-managed ClickHouse is software you run, connected with a username and password over port 8123 (HTTP) or 9000 (native), and it uses users.xml or SQL-based RBAC for access. This integration works with both, and the tool surface is the same; what differs is where the credentials come from and which permission model you are governed by.

The six tools are the industry-standard query surface, not a toy set: clickhouse_list_databases and clickhouse_list_tables for inventory, clickhouse_get_database_schema and clickhouse_get_table_schema for structure, clickhouse_execute_query for SQL, and clickhouse_get_play_interface for the web SQL surface. Everything is query-shaped, which keeps the integration honest: the agent reads schemas, lists objects, and runs SQL with the account's permissions. For a database the size ClickHouse is built for, that small, well-defined surface is usually the right scope.

The connection carries the permissions of the credentials you pasted, so the honest answer is: the agent can do whatever those credentials can do. If you paste a key pair with write and DDL rights, the agent can run write and DDL statements, and a malformed prompt is all it takes. The least-privilege setup is a credential pair scoped to SELECT, which makes the integration read-only in practice, and on ClickHouse Cloud that scoping happens through SQL grants on the key's user rather than anything in the connect form. Decide which user the pair belongs to before you paste it.

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.