OWOX Data Marts

List data marts available to the current OWOX project member. 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 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.

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.

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).

Start an existing report by report_id and deliver fresh data to its push destination (Google Sheets, Email, Slack, Microsoft Teams, or Google Chat). Returns immediately with report_id and run_id; it does not wait or report final status. Then poll get_report_run_status with those ids until should_poll is false, waiting up to 15 seconds between checks when possible. Do not call run_report again for the same report while that run is in progress; each call starts a new billed Report Run, and concurrent runs are rejected as "Report is already running or pending".

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.

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.

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.