How to connect Google BigQuery to OpenClaw

The ClawHub skill teaches OpenClaw about Google BigQuery, but the calls run through the ClawLink plugin and your connected account. Make sure Google BigQuery is connected in the dashboard, then start a fresh chat so OpenClaw reloads the tool catalog. If OpenClaw runs as a persistent gateway, restart it so the new tools register.

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 permissions are layered, and which layer failed tells you what to fix. Project-level access governs whether jobs can run at all; dataset-level and table-level access govern what those jobs may read. So an account that can run queries but cannot read one particular 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, because if several Google accounts have access to the project, the one you approved may not be the one you had in mind. The remaining cause, which search results never mention, 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 see, and which Google account it is acting as. Do not retry the failed query yet.

BigQuery enforces several distinct quotas and the message usually names the one you hit, so read it before retrying. Concurrent interactive queries, bytes scanned per day, and table update operations per day behave differently: a concurrency limit clears in seconds, while a daily bytes-scanned cap does not clear until its window rolls over. Retrying at once makes the first worse and does nothing for the second. The durable fix is query shape rather than pacing — filter on the partition column, name your columns, and have the agent read a table's schema with googlebigquery_get_table_schema before writing SQL against it instead of discovering the columns by repeatedly scanning.

Ask the agent to diagnose it:

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

Tool 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 clears. If every call fails in a brand-new chat, the connection itself needs attention and reconnecting from the dashboard is the fix. This differs from what most search results describe for this phrase, 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 OpenClaw to Google BigQuery: link your Google BigQuery account once in the browser and OpenClaw can call the Google BigQuery API through 63 ready-made tools — no custom code or token handling.

Paste the setup prompt from this page into OpenClaw. It installs the ClawLink Google BigQuery skill from ClawHub, then you click Connect in the dashboard to authorize Google BigQuery. OpenClaw calls the tools 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 OpenClaw 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 OpenClaw. That is fine if you want to build and maintain the integration yourself. Most teams just want Google BigQuery working from chat.

No, and skipping it is the main practical gain. The usual setup leaves a long-lived JSON credential sitting on whichever machine runs the agent — the thing security reviews object to and the thing that gets committed by accident. Here the connection uses Google's OAuth consent screen, the credential stays on the ClawLink server, and the agent acts with the access your own Google account already has in that project. Revoking is a click in the dashboard rather than hunting down a file.

You do, and it is worth understanding the shape of that bill before letting an agent write SQL. BigQuery charges on-demand queries by the volume of data scanned, not by how long they run or how many rows come back, so a SELECT * against a large partitioned table can cost real money in seconds while looking like an innocent question. The habits that matter are the ordinary BigQuery ones: select named columns, always filter on the partition column, and ask the agent to show you the SQL before it runs anything exploratory. It will happily write the expensive version if nobody asks it not to.

Both, and the surface is wider than reporting: alongside queries and schema reads there are tools for creating datasets, routines, connections, reservations, capacity commitments, and data-exchange listings. That breadth is a reason to think about which Google account you connect, because the agent inherits that account's IAM permissions exactly. If it should not be able to create reservations, connect an account that cannot — IAM is the real control surface here, not the wording of your 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 deserve planning beyond the mechanism. The first is cost rather than access — a badly shaped query is expensive rather than dangerous, and the habits above are the mitigation. The second is that query results become context the model reasons over, so if a table holds text written by other people, treat it as untrusted input before letting the agent act on what it read.

The ClawHub skill teaches OpenClaw about Google BigQuery, but the calls run through the ClawLink plugin and your connected account. Make sure Google BigQuery is connected in the dashboard, then start a fresh chat so OpenClaw reloads the tool catalog. If OpenClaw runs as a persistent gateway, restart it so the new tools register.