WitCloud

Append a new entry to the Context Log spreadsheet for the chosen business context. Only works for contexts with type="context_log". Use when the user asks to record a business event. Requires `business_context_id` — there is NO automatic selection. If the user has not picked one yet, ask them which context to log against (options come from load_project.businessContexts, filter by type="context_log").

add_context_log_entry

Read-only pre-check before complete_onboarding_step, for the two steps that have one: - connect-google-cloud-project: the GCP project ids the WitCloud service account can currently see. Call it after the user says they granted IAM access, to confirm the grant took effect. Use the returned list — never ask the user to type their project id; one result, confirm it and proceed, several, ask them to pick. - choose-a-location-to-store-your-data: the available BigQuery regions. Any other step returns an error — go straight to complete_onboarding_step.

check_onboarding_step

Perform or acknowledge one onboarding step — the same code path as the app's "Next" button. Returns {success: true}, or {success: false, code, message}: relay `message` and look up `code` in that step's onboarding/stages/* document. Re-run get_onboarding_status afterwards. "choose-a-location-to-store-your-data" is WRITE-ONCE — get the user's explicit confirmation of the exact region before calling. The last four steps perform nothing: they only verify the audit already shows the step ok and record it, so do the real work with the dedicated tools first.

complete_onboarding_step

Create (omit `business_context_id`) or update (include it) a business context, in any of its three forms: inline `content`, a Google Doc (`content_doc_url`), or a `context_log` Google Sheet (`context_log_spreadsheet_url` with type="context_log"). Both Google forms must be shared with the project service account first — Viewer for a Doc, Editor for a Sheet. This tool checks that before saving and refuses if it cannot read the file, telling you the exact address to share with; the address is in load_project.project.serviceAccountEmail, so give it to the user before asking for a link. The user creates the file themselves — we cannot, it would land in the wrong Drive. For inline content: do NOT invent it. Interview the user, then show your draft and get approval before saving; if they dictate the text, save it verbatim. `onboarding/stages/business-context` documents what a good context covers, which is worth reading before the interview.

upsert_business_context

Create (omit `grouping.id`) or update (include it) a whole channel grouping in one call. New ones are always custom (category "other"); the seeded "Marketing Channels" and "Market" cannot be created, renamed or deleted — pass their existing `id` to edit their channels. Simulate the impact with run_query and confirm with the user before saving. Saving changes config only: new data follows the new rules, HISTORY needs reprocess_channel_grouping. `onboarding/stages/channel-grouping` documents the available fields, operators and matching rules — read it before composing a grouping.

upsert_channel_grouping

Business descriptions of a table's columns — what a column holds, what an enum value stands for, which field to join on. Name the columns you need: a full set of descriptions can be very large.

describe_columns

Return one business context by id. What comes back depends on its type: • type="text" — the company/product description (name, description, content). • type="context_log" — the Context Log: a timeline of business events (rebrands, launches, campaigns, structural changes), with the optional date/category filters applied. `business_context_id` is required — there is no automatic selection. The options, with their `type`, are in load_project.businessContexts. One case needs no asking: when a solution instance in load_project.dataSources carries a `businessContext` in its `parameters`, that is the context its analyses were built against.

get_business_context

The full configuration of ONE channel grouping by id: name, index, category and every channel with its condition rules. Raw config, no data analysis — and the exact shape to edit and pass back to upsert_channel_grouping. The ids are in load_project.channelGroupings.

get_channel_grouping

Connector run history, live from the job event stream — answers "is connector X working?", "why did it fail?", "has it run recently?". Raw runs, no verdict: you judge them. Two things you will get wrong otherwise: - `attemptCount` > 1 with `status: "SUCCESS"` = failed, then passed on retry. NOT a broken connector, and its `errors` are transient. Only "FAILED" never succeeded. - The window is when jobs RAN, not which dates they collected (`runDate` can be far older — backfills). So no runs means "nothing ran in the last N days", never "this never ran". Says nothing about whether data reached All-in-One — jobs can succeed and deliver nothing. For that use get_onboarding_status. `onboarding/audits/integrations` documents how to read the runs and the per-connector quirks behind each error.

get_integration_status

Live setup status for a project: an ok/warning/missing/error verdict per foundation step (GCP, data location, currency, integrations, All-in-One, channel grouping, business context), the ordered `checklist`, and `nextStep` — the first step not yet acknowledged. Cheap and idempotent, so it can be re-run after every change. Each item carries two different things: `auditStatus` (the live fact) and `status` (whether the step was explicitly acknowledged). It also returns a `products` block, which is out of scope for now. `onboarding/introduction` documents how the steps fit together and which document covers each one.

get_onboarding_status