WitCloud

The BigQuery schema of one table — fields, types and modes. Takes the full suffixed `tableId` from list_tables (for a custom-source table, its `fullyQualifiedName`). Field descriptions are left out to keep the response lean; describe_columns returns them for the columns you name.

get_table_schema

The project's active data sources, in the same shape as `load_project.dataSources`. Use it to refresh the catalogue mid-session — for example after a solution run produced new tables.

list_data_sources

List the reference documentation for this project: what a table holds, what its columns mean, which SQL a given analysis uses, what a setup step involves. Returns summaries (no content) so it is cheap on tokens. Filter by slug prefix or free-text search. Slugs are path-like: - `introduction` — the project master document - `aio/introduction`, `aio/tables/<baseTableName>` — All-in-One - `solutions/<type>/introduction`, `solutions/<type>/tables/<baseTableName>`, `solutions/<type>/analysis/<name>` — a solution and its analyses - `onboarding/introduction`, `onboarding/stages/<step>`, `onboarding/audits/<area>` — project setup and its audit areas - `project/...` — documentation the client wrote for this project: their metric definitions, conventions, notes and saved playbooks (`source: "project"`). `project/introduction` is their overview of the project, with an index of the rest; `project/sources/<slug>/introduction` and `project/sources/<slug>/tables/<table>` describe their custom data sources. WitCloud's documents (`source: "witcloud"`) are authoritative on how the platform builds its tables; the client's own documents are authoritative on what their data means for their business.

list_documents

Start here. Read the `introduction` document in the same turn — read_document("introduction") — it is the master document for this data: what a project contains, how to run a session, and what the tables and columns actually mean. It is one call and it applies to every project. Every WitCloud project the user has access to: its `id` (what every other tool takes as `project_id`), its name, its BigQuery dataset id, and whether it has been provisioned yet. Every other tool needs one of these ids, so a session starts here.

list_projects

BigQuery tables in the project dataset, each classified to the data source it belongs to, with its full `tableId` (always suffixed) and its `partitioning`. Tables matching no data source are omitted. Tables of custom data sources (`source: "custom"`) live outside the project dataset: they carry a `fullyQualifiedName` — use it as-is in queries and as the tableId for the schema tools — and a `status`; one that is not "ok" or "location-mismatch" cannot be read right now (`error` says why). "location-mismatch" tables sit in another BigQuery location, so they cannot be joined with All-in-One or solution tables in one query. run_query needs both of those: the full tableId, and the partition column to filter on.

list_tables

Read `introduction` before you query anything — read_document("introduction"). It is the master document for this data. Everything a session needs about one project, in a single call: its identifiers, its data sources, its business contexts and its channel groupings — the ids every other tool takes, so nothing else has to go looking for them. For cross-project work, call it once per project. Each entry in `dataSources` carries a `rootDocumentPath`: the document describing that source, its tables and its query patterns. Read it once the user has picked a source, before the first query. Sources with `kind: "custom"` are tables the client registered themselves; their `status` says whether they can be read right now. If a `setup` block comes back, the project has nothing to analyse yet: `reason` says which part of setup is still open and `nextAction` says what to do — a normal state for a project still being set up, not an error. Follow `nextAction`. The block is absent once the project has data.

load_project

Read the full markdown content of one reference document by its slug — the documentation for the project, a data source, a table, an analysis or a setup step. Slugs are path-like, e.g. 'aio/introduction'; the client's own documents start with 'project/'. Use list_documents to discover slugs.

read_document

Recompute the channel_grouping columns on historical All-in-One data after a grouping change. New data does not need this — only history. ALWAYS call with mode="estimate" first: it is a free dry-run returning `totalBytesProcessed` and `estimatedCostUsd`. Show those to the user and get explicit confirmation before calling mode="execute", which costs real money. Scope it like the app panel: full=true for all history, or an explicit start_date/end_date range.

reprocess_channel_grouping

Run a SELECT against the project BigQuery dataset. list_tables supplies the two things a query needs — the full suffixed tableId and the table's `partitioning`. - Fully qualified names: `googleCloudProjectId.datasetId.tableId`; a custom-source table already comes with its `fullyQualifiedName` — use that - ALWAYS filter the partition column, per `partitioning` from list_tables: "_PARTITIONTIME" → filter `_PARTITIONTIME` or `_PARTITIONDATE`; any other field → filter that exact column; null → no filter needed - SELECT only, DML is rejected - Only the project dataset and registered custom-source tables can be read - Cross-source JOINs work within one BigQuery location — custom tables marked "location-mismatch" must be queried on their own

run_query

Save a document to the client's own project documentation — create it, or replace the one with the same slug. For knowledge worth keeping across sessions: how the client defines a metric, which filter a report always needs, what a column really holds in their data — or an analysis the user wants to repeat, saved as a playbook: its steps and SQL, and a `description` saying which question it answers, since the description is all list_documents shows of it. - Only after the user has read and confirmed the exact content: this writes to their documentation, visible to everyone on the project. - To change a document, read it first and send the whole new content — this replaces it. - Slugs live under `project/` (the prefix is added when missing), e.g. 'metrics/revenue'. `project/sources/` is reserved: custom data sources are documented from the app. - To file it in a folder, pass `folder` and keep `slug` to the document's own name. Name each level either as the folder is titled (the project introduction's headings) or as it appears in slugs — 'Analizy/Sprzedaż' and 'analizy/sprzedaz' reach the same folder. Levels that do not exist are created, so reuse an existing folder where one fits, and start a new one only when the user agreed to it. - `project/introduction` is the client's overview of the project; an index of the other project documents is appended to it automatically, so do not list them in it. - WitCloud's own documents cannot be changed.

upsert_project_document