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

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

BigQuery enforces several separate quotas and the message usually names which one, so read it before retrying. Concurrent interactive queries, query bytes scanned per day, and table update operations per day are the ones agents meet most often, and they behave differently: a concurrency limit clears in seconds, whereas a daily bytes-scanned cap does not clear until the quota window rolls over. Retrying immediately makes the first case worse and does nothing for the second. The durable fix is query shape rather than pacing — filter on the partition column, select named columns instead of star, and have the agent check a table's schema with googlebigquery_get_table_schema before writing a query against it rather than exploring with repeated full scans.

Ask the agent to diagnose it:

Quote the exact quota name from the error. Then show me the query you ran and tell me which columns and partitions it touched. Do not re-run it yet.

BigQuery permissions are layered, and the layer that fails tells you what to fix. Project-level access controls whether jobs can run at all; dataset-level and table-level access control what those jobs can read. So an account that can run a query but not read one table produces exactly this error while everything else works, and the fix is granting access to that dataset in Google Cloud rather than reconnecting. Check the connected identity first — if several Google accounts have access to the project, the one you connected may not be the one you were thinking of. The other cause, invisible to search results but real here, is a placeholder: a project or dataset id copied from documentation fails as a permission error rather than a not-found.

Ask the agent to diagnose it:

Run googlebigquery_list_datasets and tell me which project and datasets this connection can actually see, and which Google account it is acting as. Do not retry the failed query yet.

Schemas load on demand rather than shipping with the plugin, so the very first BigQuery call in a fresh session can arrive before the catalog does. Wait a moment and retry and it normally resolves. If every call fails in a brand-new chat, the connection itself needs attention — reconnect from the dashboard. This is a different failure from the one most search results describe, which is a local MCP server missing from a client config file; there is no local server here and no file to edit.

Try reconnecting Google BigQuery 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 Google BigQuery: link your Google BigQuery account once in the browser and Hermes Agent can call the Google BigQuery API through 63 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 Google BigQuery 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 Google BigQuery 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 Google BigQuery working from chat.

No, and avoiding it is the main practical gain. The standard BigQuery setup has you create a service account in Google Cloud, download a JSON key, and put it somewhere the agent can read — a long-lived credential in a file, which is the thing security reviews object to and the thing that gets committed by accident. ClawLink connects through Google's OAuth consent screen instead, so the credential lives on the ClawLink server and the agent acts with the access your Google account already has in that project.

Yours, and this is worth understanding before you let an agent write queries. BigQuery bills on-demand queries by the volume of data scanned, not by how long they take or how many rows come back, so a SELECT * against a large partitioned table can cost real money in seconds while looking like a harmless question. The habits that matter are the usual BigQuery ones: select only the columns you need, always filter on the partition column, and ask for a dry run or a limit when exploring. An agent will happily write the expensive version if nobody tells it not to.

Both, and the toolset is broader than reporting: alongside queries and schema reads there are tools to create datasets, routines, connections, reservations, capacity commitments, and data-exchange listings. That breadth is useful and it is also the reason to think about which Google account you connect. The agent inherits that account's IAM permissions exactly, so if it should not be able to create reservations, connect an account that cannot. IAM is the real control surface here, not the prompt.

The connection is Google's own OAuth flow, so you approve it on Google's screen, no key file exists on your machine, and revoking from the ClawLink dashboard stops further calls. Two risks are worth planning for beyond the mechanism. The first is cost rather than access, since a badly shaped query is expensive rather than dangerous — the mitigations above are the answer. The second is that query results are data the model then reasons over, so if a table contains text written by other people, treat it as untrusted input and keep a human in the loop before the agent acts on what it read.

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.