List the configured BigQuery environments and which one is the default.

Call this when the user names an environment you have not seen, or when a question could plausibly be about more than one. Free — reads only this server's configuration.

List the BigQuery datasets available in the data platform project.

Call this first to discover what data exists. Free — scans no data.

Args: environment: Which configured BigQuery environment to use. Omit to use the default. Call list_environments to see what exists.

List tables and views inside a dataset. Free — scans no data.

Args: dataset_id: The dataset to inspect, e.g. "events_raw". environment: Which configured BigQuery environment to use. Omit to use the default. Call list_environments to see what exists.

Get a table's columns, partitioning, size and freshness. Free — scans no data.

Call this before writing a query, for two reasons beyond column names:

• partitioning says whether a WHERE clause can actually limit the scan. A date-shaped column name does NOT mean the table is partitioned; if this field is null, every query reads the whole table.

• Nested columns are expanded to dotted paths and flagged repeated, which is what tells you a column needs UNNEST.

Args: dataset_id: The dataset, e.g. "events_raw". table_id: The table or view name. environment: Which configured BigQuery environment to use. Omit to use the default. Call list_environments to see what exists.

Report when tables were last written, to catch stale or dead sources.

Several plausible-looking tables on this platform stopped being updated without being dropped, so a query against one silently returns old data. Check before trusting a table you have not used before.

Free — reads table metadata only, scanning no data.

Args: dataset_id: The dataset to check, e.g. "events_raw". table_id: A single table to check. Omit to report every table in the dataset, which is the faster way to spot a dead one. environment: Which configured BigQuery environment to use. Omit to use the default. Call list_environments to see what exists.

List scheduled queries: what they write, when they run, and their state.

Use this to answer "what populates this table?" and "why is this table stale?" — a disabled or failing scheduled query is the usual cause, and check_table_freshness can see the staleness but not the reason.

The SQL is not included here; call get_scheduled_query for one of them.

Args: dataset: Only queries writing into this destination dataset. contains: Only queries whose name contains this text. include_disabled: Keep disabled queries in the result. They are the most likely explanation for a table that stopped updating, so this defaults to True. environment: Which configured environment to look in. Scheduled queries are regional, so this must be the environment whose location holds them.

Get one scheduled query in full: its SQL, destination, and recent runs.

Call this after list_scheduled_queries to see why a query is failing, or what SQL actually produces a table.

Args: query: The scheduled query's name, or the id from list_scheduled_queries. runs: How many recent runs to include, newest first. environment: Which configured environment to look in.

List Colab notebooks and saved queries in BigQuery Studio.

Use this for anything the user calls a Colab notebook, Colab Enterprise notebook, "colab script", BigQuery notebook, saved query or data canvas -- BigQuery Studio stores all of them as code assets and this lists them all.

Free -- this reads metadata only and never opens an asset. Bodies are what cost quota, so filter here first and open individual assets afterwards.

Args: environment: Which configured environment to read. Omit for the default. asset_type: Restrict to one of 'sql', 'notebook', 'data_canvas'. Saved queries usually outnumber notebooks by a wide margin, so this is the difference between a readable answer and 600 rows. name_contains: Case-insensitive substring match on the display name. limit: Maximum assets to return.

Return one Colab notebook or saved query's contents, by name or id.

Notebook outputs are stripped -- across 52 real notebooks they were 77% of the bytes, and none of the logic.

Args: asset: Display name (as shown in BigQuery Studio) or the asset id. environment: Which configured environment to read. Omit for the default.

Find which Colab notebooks and saved queries reference a table.

The question to ask before changing or dropping a table: list_scheduled_queries says what writes it, this says who reads it.

Unlike the other tools here this one opens every asset it considers, which costs Dataform read quota. It is bounded by max_assets and reports how much of the project it actually covered -- a result is evidence about the assets scanned, never proof that nothing else uses the table.

Args: table: Table name to search for. A bare name matches any qualification; 'dataset.table' or a fully-qualified name narrows it. environment: Which configured environment to read. Omit for the default. asset_type: Restrict to 'sql', 'notebook' or 'data_canvas'. max_assets: Ceiling on how many bodies to read.

List scheduled Colab notebooks with how many recent runs passed or failed.

This is the health overview for scheduled notebook work: what is scheduled, whether it is active or paused, and — the part that is otherwise invisible — how its actual runs have been going.

Do not read a schedule's own state as health. A schedule reports its last scheduled run as "OK" when it successfully launched the notebook, whether or not the notebook then failed; on this platform every schedule says OK while hundreds of runs have failed. The pass/fail numbers here come from the execution jobs, which is the only place the outcome exists.

Args: environment: Which configured environment to read. Omit for the default. state: Restrict to 'active' or 'paused'. A paused schedule that used to fail is a common find — someone paused it instead of fixing it. name_contains: Case-insensitive substring match on the schedule name. lookback_days: How far back to read runs for the pass/fail counts. Defaults to 30 so monthly schedules show at least one run. Larger windows cost proportionally more (90 days is roughly 23 API pages). Set to 0 to skip run history entirely and just list what exists.

List individual scheduled-notebook runs, by default the failed ones.

Use this for "what has been failing?" across every scheduled notebook at once, rather than per schedule. Runs are returned newest first.

Outcome cannot be filtered server-side — the API rejects a jobState filter — so this reads the runs in the window and filters here. That makes lookback_days the cost control: each 100 runs is one API call.

Args: status: 'failed' (default), 'succeeded', 'running', or 'all'. environment: Which configured environment to read. Omit for the default. schedule: Restrict to one schedule, by its name or id. lookback_days: How far back to read. Defaults to 30. limit: Maximum runs to return.

Get one scheduled notebook in full: its cron, its notebook, and recent runs.

Call this after list_notebook_schedules to see why a scheduled notebook is failing. The error text for each failed run is included, and notebook_id is a code asset id — pass it to get_code_asset to read the code that failed.

Args: schedule: The schedule's name or its id from list_notebook_schedules. runs: How many recent runs to include, newest first. environment: Which configured environment to read. Omit for the default.

Run a read-only (SELECT/WITH) SQL query against BigQuery and return rows.

Cost safety: the query is ALWAYS dry-run first to estimate how much data it will scan. If that estimate is above the warning threshold, the query does NOT run — instead this returns status: "confirmation_required" with the estimated size and cost. Stop there, tell the user the estimated scan and cost, and ask. Only re-call with confirm_expensive=true once they have agreed: that flag records the user's decision, not yours. Queries above the hard cap never run, even with confirmation.

Always fully-qualify tables as <project>.<dataset>.<table>, and check get_table_schema first — a WHERE clause only limits the scan on a table that is actually partitioned.

Args: sql: A SELECT (or WITH ... SELECT) query. max_rows: Max rows to return, to keep responses small. 0 (the default) uses the server's configured limit. confirm_expensive: Set True only after the user has agreed to a query previously flagged as costly. Leave False for the first attempt. environment: Which configured BigQuery environment to query. Omit to use the default. Call list_environments to see what exists.