OWOX Data Marts

Get the current status of a report run, identified by report_id and run_id. The run_id may come from run_report or from add_report when initial_run.status is "queued". Report runs routinely take several minutes, so keep polling while should_poll is true and stop when should_poll is false; terminal statuses are "success", "failed", "cancelled", "interrupted", and "restricted". If you can wait between tool calls, poll about every 15 seconds; otherwise call again immediately. The message field tells you what to do next, including when to warn that a run is taking longer than usual and when to treat it as stuck and stop polling. stop_reason is set only when status is still "running" but should_poll is false, such as queued_too_long or running_too_long. queued_at is when the run was created; started_at is null until execution starts, including the brief worker-claimed state before the start time is recorded. raw_status exposes the backend status, and error is populated only for failed runs.

get_report_run_status

List data marts available to the current OWOX project member. Defaults to published data marts; use status=draft only to browse draft metadata, because other MCP data-mart tools accept published data marts only. Use only when the user explicitly asks to list or browse data marts; for a concrete analytical question use get_relevant_data_marts_by_prompt instead, and for open-ended orientation use summarize_data_catalog.

list_data_marts

List destinations in the active OWOX project to target when creating a report. Also the only way to learn the destination_id and connected Google account for a google_sheets destination just created via add_destination, since that call does not return an id synchronously — see its description. When matching that destination, never pick by createdAt/recency — someone else may create a destination at the same time, so the newest entry is not reliably the right one. Filter by connectedGoogleAccount matching who the user expected instead; if exactly one entry matches, use it, and if more than one still matches, ask the user which one they mean rather than guessing. Destinations created via add_destination start unshared: the creator can use them in their own reports right away, but other project members cannot until a human shares them (Configure destination → Sharing) — this tool does not report sharing status, so if the report is for someone other than the destination's creator, confirm with the user that it has been shared rather than assuming it.

list_destinations

Lists every scheduled REPORT_RUN trigger (report run schedule) in the current OWOX project that the current MCP user can see, in a single response. Each item includes trigger_id — pass it to update_report_run_schedule to modify that specific schedule or delete_report_run_schedule to remove it — plus the report and data mart it belongs to. To add another schedule for a report, call create_report_run_schedule; creating never replaces existing schedules.

list_report_run_schedules

Query an OWOX data mart and return its data rows in a compact, header-once table, plus server-side totals computed over all matching rows (ignoring the row limit). Each call costs credits. Call get_data_mart_details_by_id first to get the data mart's exact field names and joinable/blended fields, then copy field names verbatim into fields — unless you already have that schema in context. Field names must be exact; never guess or invent them. When building the query: - Request only the fields relevant to the user's question — never request all fields. - Use limit to control how many rows come back (1–1000, default 20). There is no offset/pagination: the tool returns a bounded subset. - aggregations: SUM, COUNT, COUNT_DISTINCT, AVG, MIN, MAX, and percentiles P25/P50/P75/P95 — but each data mart's output controls decide which functions a given field allows, so some may be rejected (pick another, or ask an admin to enable it). Group-by is implied by the non-aggregated fields you select. - date_buckets: bucket a date/timestamp field by DAY/WEEK/MONTH/QUARTER/YEAR (e.g. "revenue by month"). - fields must list every column the query uses, INCLUDING any field named in aggregations or date_buckets — a field you aggregate or bucket but omit from fields is rejected. Example — "revenue by month": fields ["ts", "revenue"], aggregations [{field: "revenue", function: "SUM"}], date_buckets [{field: "ts", unit: "MONTH"}]. (Filters are the exception: a filter may reference a field that is not in fields.) Choosing between slices and filters (both are row-level predicates applied to raw values BEFORE any aggregation — neither can threshold an aggregated total; there is no HAVING): - slices (pre-join): narrow a JOINED data mart before it is blended in — criteria on a joined data mart's own fields only. Slices do NOT apply to the main data mart. More efficient — they reduce the joined volume before the join. - filters (post-join): row-level criteria on the blended result — use for anything on the MAIN data mart's fields or on a joined field. A filter on a field you also aggregate restricts which raw rows feed the aggregate (e.g. filter revenue > 0 → SUM over positive rows), NOT the group total. - Rule: pre-narrowing a joined data mart's rows → slices; any other raw-row criterion → filters. - Filtering by an aggregated total (e.g. "groups whose SUM(revenue) > 100") is NOT supported — return all groups with their totals and let the caller compare. - Example — "orders in the last 3 months" where orders is a joined data mart: the date range narrows the joined orders before the join → slices. Using the results: - Use metrics and totals from the response directly — never recompute a value already present (totals are computed server-side over all matching rows, so they stay correct even when rows are truncated). - The totals block is separate from the rows. - When you use aggregations, the rows include an extra "Row Count" column — the number of underlying rows in each group. It is grouping metadata, not one of your requested fields; ignore it unless the user asked how many rows a group contains. If truncated is true, not all matching rows were returned: narrow the query (fewer fields, tighter slices/filters) or raise limit (up to 1000).

query_data_mart

Start an existing report by report_id and deliver fresh data to its push destination. Use this for a later rerun or when add_report returned initial_run.status="failed_to_queue". Do not call it when add_report already returned a queued run_id. Returns immediately with report_id and run_id; it does not wait for final status. Poll get_report_run_status with those ids until should_poll is false, waiting up to 15 seconds between checks when possible. Each call starts a new billed Report Run; concurrent runs are rejected as "Report is already running or pending".

run_report

Returns a high-level summary input for the current OWOX project published Data Mart catalog so the LLM can orient the user. Use when the user asks open-ended questions like "what data is available here?", "what can I analyze?", or "where should I start?". The tool returns counts and top published Data Marts ranked by configured relationship connectivity, with shortened descriptions and basic usage metadata. It does not query actual data rows, compute data freshness, or generate a natural-language summary.

summarize_data_catalog

Update an existing report: rename it and/or replace which data mart fields it exports. Provide at least one of name or fields; anything not provided stays unchanged.

update_report

Updates one existing report run schedule identified by trigger_id (get it from list_report_run_schedules). This changes cron_expression, and optionally time_zone and is_active; it does not change the report target and does not create another schedule. To add another schedule for the same report, call create_report_run_schedule instead. time_zone must be a valid IANA timezone (e.g. "Europe/Kyiv"); if omitted, the schedule keeps its current timezone. If is_active is omitted, the schedule keeps its current active state.

update_report_run_schedule