Whatagraph

Delete overviews. **Destructive actions.** Every action of this tool: permanently deletes data. Breaks downstream: overview shares. Needs approval. A call to an action that needs approval returns a preview and performs no change; repeat the identical call with the `confirm_token` from that preview to execute it. Never confirm a destruction the user did not ask for — report the preview back to them instead. Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-deleting`.

delete-overviews

Delete or restore tabs within a report. Use `action` to choose the operation: - `delete` — soft-delete a tab (requires `report_id` and `tab_id`) - `restore` — restore a previously deleted tab and its widgets (requires `report_id` and `tab_id`) List the report's tabs first to find tab IDs. **Destructive actions.** `delete`: permanently deletes data. Breaks downstream: widgets, reports. Needs approval. A call to an action that needs approval returns a preview and performs no change; repeat the identical call with the `confirm_token` from that preview to execute it. Never confirm a destruction the user did not ask for — report the preview back to them instead. Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-deleting`.

delete-report-tabs

Delete reports. **Destructive actions.** Every action of this tool: permanently deletes data. Breaks downstream: report tabs, widgets, automations, shares, snapshots. Needs approval. A call to an action that needs approval returns a preview and performs no change; repeat the identical call with the `confirm_token` from that preview to execute it. Never confirm a destruction the user did not ask for — report the preview back to them instead. Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-deleting`.

delete-reports

Remove public share links from reports and overviews. Target a report with `report_id` or an overview with `overview_id` — one or the other, never both. **Destructive actions.** Every action of this tool: permanently deletes data. Breaks downstream: public links already handed out. Needs approval. A call to an action that needs approval returns a preview and performs no change; repeat the identical call with the `confirm_token` from that preview to execute it. Never confirm a destruction the user did not ask for — report the preview back to them instead. Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-deleting`.

delete-sharing

Delete report snapshots. Use `action` to choose the operation: - `delete` — delete a snapshot **Destructive actions.** Every action of this tool: permanently deletes data. Needs approval. A call to an action that needs approval returns a preview and performs no change; repeat the identical call with the `confirm_token` from that preview to execute it. Never confirm a destruction the user did not ask for — report the preview back to them instead. Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-deleting`.

delete-snapshots

Delete source groups. This removes the source group, its configs, sources, and the associated virtual integration source. This action cannot be undone. **Destructive actions.** Every action of this tool: permanently deletes data. Breaks downstream: widgets, blends, reports, transfers. Needs approval. A call to an action that needs approval returns a preview and performs no change; repeat the identical call with the `confirm_token` from that preview to execute it. Never confirm a destruction the user did not ask for — report the preview back to them instead. Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-deleting`.

delete-source-groups

Remove data sources from the team. This disconnects the source and removes its data from reports. Use `source_ids` to specify which sources to delete. Requires confirmation. **Destructive actions.** Every action of this tool: permanently deletes data. Breaks downstream: widgets, blends, reports, goals, source groups. Needs approval. A call to an action that needs approval returns a preview and performs no change; repeat the identical call with the `confirm_token` from that preview to execute it. Never confirm a destruction the user did not ask for — report the preview back to them instead. Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-deleting`.

delete-sources

Delete spaces. Cannot delete the "Home" space. If a user says "space", "folder", or "client", they mean a space. Use `action=delete` with a `client_id` to soft-delete a space and all its reports. **Destructive actions.** Every action of this tool: permanently deletes data. Breaks downstream: reports, overviews, member access. Needs approval. A call to an action that needs approval returns a preview and performs no change; repeat the identical call with the `confirm_token` from that preview to execute it. Never confirm a destruction the user did not ask for — report the preview back to them instead. Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-deleting`.

delete-spaces

Delete report templates. Does NOT delete reports created from the template. **Destructive actions.** Every action of this tool: permanently deletes data. Breaks downstream: linked reports. Needs approval. A call to an action that needs approval returns a preview and performs no change; repeat the identical call with the `confirm_token` from that preview to execute it. Never confirm a destruction the user did not ask for — report the preview back to them instead. Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-deleting`.

delete-templates

Delete custom themes and color palettes. **Destructive actions.** Every action of this tool: permanently deletes data. Breaks downstream: reports, templates, spaces. Needs approval. A call to an action that needs approval returns a preview and performs no change; repeat the identical call with the `confirm_token` from that preview to execute it. Never confirm a destruction the user did not ask for — report the preview back to them instead. Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-deleting`.

delete-themes

Delete, restore, or batch-delete widgets from report tabs. Use `action` to choose the operation: - `delete` — soft-delete a single widget (requires report_id, widget_id) - `restore` — restore a previously deleted widget (requires report_id, widget_id) - `batch_delete` — soft-delete multiple widgets at once (requires report_id, widget_ids) **Destructive actions.** `delete`, `batch_delete`: permanently deletes data. Needs approval. A call to an action that needs approval returns a preview and performs no change; repeat the identical call with the `confirm_token` from that preview to execute it. Never confirm a destruction the user did not ask for — report the preview back to them instead. Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-deleting`.

delete-widgets

Export all widgets in a report (or a single tab) as an Excel file. Returns a temporary download URL (expires in 1 hour) to an `.xlsx` file where each widget is a separate sheet with its own columns and data. Use shell tools (`head`, `cut`, `wc -l`) on the downloaded file to inspect specific parts without loading the entire dataset. Parameters: - `report_id` (required) — report to export - `tab_id` (optional) — limit to a single tab - `widget_ids` (optional) — limit to specific widgets - `from` / `till` (optional, YYYY-MM-DD) — fallback date range for widgets that don't have one configured Calendar and filter control widgets are skipped. Requires the `widget-csv-export` plan feature. Teams without it will get a permission error. This tool has a workflow playbook: run `list-skills` (or `load-skill` by the matching `whatagraph-<domain>` name) for its required fields, valid ID shapes, call sequence, and known gotchas before composing a call. Whatagraph's data model is specific, so a call assembled without the playbook often fails on a field name or ID.

export-report

Fetch marketing data from a connected source. Returns rows of metric values optionally grouped by dimensions for a date range. Use the `list-sources` tool first to discover available sources, report types, and field names. Important: if the response indicates data is not yet ready (rate-limited or processing), wait the indicated `retry_after` seconds and call again with the same parameters. Field IDs come in three families, and the valid set depends on the source AND report type: native dotted IDs (e.g. `metrics.cost_micros` on Google Ads), bare IDs (e.g. `sessions` on GA4), and custom-field IDs (`universal_metric_{id}` / `universal_dimension_{id}`). Never guess the family — copy the `external_id` verbatim from `list-sources` `action=list_dimensions_and_metrics` for the same `source_id` and `report_type` you pass here. `limit` sets the page size; the response is also capped at ~50 KB. When the full result exceeds either bound, rows are paginated — check `page.has_more` and pass `page.cursor` in the next call to get the next page. `page.estimated_total` is the true total row count, not just the rows returned. When comparison data is included, both primary and comparison rows paginate together in lockstep under one shared ~50 KB cap (a single cursor advances both blocks, each tracking its own position). This tool has a workflow playbook: run `list-skills` (or `load-skill` by the matching `whatagraph-<domain>` name) for its required fields, valid ID shapes, call sequence, and known gotchas before composing a call. Whatagraph's data model is specific, so a call assembled without the playbook often fails on a field name or ID.

fetch-data

Browse AI visibility monitors — brands tracked across AI answer engines (ChatGPT, Gemini, Claude, Google AI Overviews) via monitored prompts. Use `action` to choose the operation: - `list_monitors` — the team's monitors with brand, engines, prompt counts and probe stats - `show_monitor` — one monitor with its topics, prompts (id/status/type), 30-day visibility stats, a 30-day brand leaderboard (every brand named in its answers with mention count, average rank and registry role) and the 30-day cited domains (every domain the engines linked to, with citation count and surface type). Requires `monitor_id`. Rows at `unclassified` are the two curation worklists — brands missing from share of voice, domains missing from the review/forum/social/editorial split. - `list_answers` — recent captured AI answers for a monitor: engine, prompt, whether the brand was mentioned, and an answer preview (requires `monitor_id`; optional `engine` filter) - `show_answer` — one captured answer in full: the complete response text an engine gave, the live search queries it issued while answering (the query fan-out — content targets), every brand it named (with role, rank and sentiment), and every source it cited (with surface type and owner). Requires `monitor_id` and `answer_id` (an answer `id` from `list_answers`). This is the prompt-level drill-down — the full text `list_answers` only previews. Brand roles and citation surfaces resolve at read time, so a curated answer reflects the latest registry. Stored results are also a normal channel: use `fetch-data` on the monitor's source with report types `prompt_results`, `brand_mentions` or `citations` for metrics like visibility rate, share of voice and cited domains.

list-ai-visibility

List the canonical catalog of tools that custom agents can be configured with. Call this BEFORE `manage-agents` (action=create or action=update) to obtain valid `tool_name` values and pass them verbatim — do not invent or guess names. Optional `search` filters by tool_name/title/description; `category` filters by read / write / destructive. Returns each tool's `tool_name`, `title`, `category`, `default_permission`, a short `description`, and `skills` ({core_for, optional_for}) — the skills that need this tool as a core tool vs. use it only in optional sub-workflows.

list-agent-tools

Browse AI agents for the team. Use `action` to choose the operation: - `list` — list all agents for the team (excludes system agents and drafts). When an agent has a pending draft, the listed name/description/model/status reflect the draft, with `is_draft=true` and `has_draft=true`. - `show` — full details for one agent (requires `agent_ulid`). Returns the pending draft (`is_draft`/`changed_fields`) when one exists, else the live agent. `tools` lists every tool the registry offers, not only the ones this agent holds. Read `is_granted` before `permission`: `is_granted: false` means the agent does not have the tool and will refuse to call it, and `permission` is only the catalog default it would take if you granted it. Grant one with `manage-agents` `action=update`.

list-agents

List the files (assets) available to you. In an agent conversation this is the files owned by this conversation, your agent, or the team; otherwise those owned at the team level, at a space (client) you can access, or on a report under such a space. Returns a manifest with each asset's id, title, type, size, parse status and a short summary — never the full text. Use `read-document` with an asset id to read a text file's contents. Filter with `scope`, `kind` or `tag`. `filter_space_ids` / `filter_report_ids` narrow to assets owned EXACTLY at those space/report nodes. Omit all filters for the full manifest.

list-assets

Browse scheduled report delivery configurations. If a user says "schedule", "automated report", or "email delivery", they mean automation. Use `action` to choose the operation: - `list` — automation schedules for a specific report (requires `report_id`) - `list_all` — all automations across the account (no `report_id` needed), with cursor pagination. Supports `search` (by report name) and `frequency` filters - `show` — full automation details: schedule, timezone, compare type, PDF settings

list-automations

Browse data blends. Blends combine data from multiple sources into a single virtual data source for cross-channel reporting. Use `action` to choose the operation: - `list` — cursor-paginated list of blends with optional search/filter (pass `cursor` from `page.cursor` for next page) - `show` — full blend details with sub-sources, join configuration, and usage stats Each sub-source in `show` reports its own `filter`, which narrows that channel's rows before the join runs. Use `manage-filters` with `blend_sub_source_id` to change one. Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-blends`.

list-blends

Browse conversations across all three conversation domains. Pass `type` to choose the domain and `action` for the operation (valid actions depend on the type): - `type=inter_agent` — `list_roots` (top-level conversations), `list_children` (children of a parent, requires `parent_conversation_id`), `show` (transcript, requires `conversation_id`). - `type=user` — `list` (Chat conversations), `show` (transcript, requires `conversation_id`). - `type=builder` — `list` (Agent Builder conversations, optional `filter_context_agent_ulid`), `show` (transcript, requires `conversation_id`). `filter_status` and `limit` (default 50, max 200) apply to the list actions. `show` returns the conversation header plus a cursor-paginated transcript of the visible user/assistant messages (`role`, `author`, `content`, `turn`, `created_at`). Pass `include: ["thinking", "tools"]` to add thinking rows and tool calls (each paired with its result as one entry). Follow `page.cursor` to read the rest. On agent-to-agent conversations most activity is tool calls, so the default view can be very short — pass `include: ["tools"]` to see what the agent actually did. Scope: every conversation on the team, plus your own private ones. Conversations another member marked private are not returned.

list-conversations

Browse custom dimensions (universal dimensions). These are user-created dimensions that combine or transform data from connected sources. Use `action` to choose the operation: - `list` — cursor-paginated team custom dimensions with optional type/search filter (pass `cursor` from `page.cursor` for next page) - `list_with_premades` — cursor-paginated list including premade (system) dimensions alongside team ones - `show` — dimension details including rules: field mappings, condition maps (`data`), tag/source counts (`tag`), or AI prompt (`ai`) - `list_tags` — paginated tag values with assigned source IDs for a tag-type dimension (pass `cursor` from `page.cursor` for next page) - `usage` — how many widgets/reports use specific dimensions (bulk check) Both listings hide child dimensions by default, the same way the customer's own list does. Pass `parent_id` for one parent's children, or `include_children` for every dimension flat. Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-custom-dimensions`.

list-custom-dimensions

Browse custom metrics (universal metrics). These are user-created metrics that combine or transform data from connected sources using formulas or aggregations. Use `action` to choose the operation: - `list` — cursor-paginated team custom metrics with optional type/search filter (pass `cursor` from `page.cursor` for next page) - `list_with_premades` — cursor-paginated list including premade (system) metrics alongside team ones - `show` — full metric details - `usage` — how many widgets/reports use specific metrics (bulk check) Both listings hide child metrics by default, the same way the customer's own list does. Pass `parent_id` for one parent's children, or `include_children` for every metric flat. Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-custom-metrics`.

list-custom-metrics

View data transfers and destination types. Use `action` to choose the operation: - `list` — paginated list of transfers with optional filters by name, status, issue, or destination - `show` — full details for a specific transfer by ID, including its configs - `list_jobs` — paginated list of ETL jobs for a specific transfer, optionally filtered by config_id and state - `list_destination_types` — available destination types (BigQuery, Looker Studio, Whatagraph Storage) with their required components and locations

list-destinations

List the team's external MCP connectors so you can enable them on an agent you build. Returns two sets. `connectors` — already connected and grantable: each entry has an `assign_token` (e.g. `mcp:01J...`), which you pass verbatim as a `tool_name` (with `permission: always_allow`) in `manage-agents` `tools` (action=create/update) to grant the built agent the whole connector's tools. `available_to_add` — published catalog entries the team has NOT connected: these carry **no token and cannot be granted**. Never synthesise a token for one. The only route from `available_to_add` to grantable is the user connecting it, followed by a fresh call to this tool. If both sets are empty, read `no_match_guidance` — it distinguishes a filtered miss (re-call without `search`) from a genuine absence. Optional `search` filters both sets by name. This is a read-only catalog: you (the Agent Builder) cannot call these connectors' tools yourself — you only assign them. The built agent uses the connection resolved for its own acting user at runtime; `connected_for_you` is only an informational hint.

list-external-connectors

Browse unified filters. Filters are saved filter configurations that can be applied to data sources and widget configs to narrow down displayed data. Use `action` to choose the operation: - `list` — cursor-paginated list of team filters, filterable by name and channel (pass `cursor` from `page.cursor` for next page) - `show` — full filter details with options and values - `list_parameters` — list available filter parameters for a channel (e.g. attribution windows, granularity). These are channel-specific settings that affect how filtered data is queried from the provider API. Requires `channel_id` Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-filters`.

list-filters

Browse available integrations (channels) and connected accounts. If a user says "channel" or "integration", they mean this tool. Use `action` to choose the operation: - `list` — all implemented integrations - `list_grouped` — integrations grouped by category with source counts - `list_accounts` — connected accounts for a specific integration (requires `channel_id`) - `list_available_sources` — available sources for an account (requires `account_id`). For sub-source integrations (Google Sheets, BigQuery, Snowflake), returns parent sources with `has_sub_sources=true` - `list_available_sub_sources` — available sub-sources (e.g. sheet tabs, BQ tables) for a parent source (requires `account_id` and `source_external_id`)

list-integrations

Browse overviews (called 'measurements' in the backend) — KPI tracking dashboards that monitor specific metrics over time with visualizations. If a user says 'overview', they mean this tool. Use `action` to choose the operation: - `list` — cursor-paginated list of team overviews, supports search (pass `cursor` from `page.cursor` for next page) - `show` — full overview details with configs, applied filters, and share settings

list-overviews

Browse tabs (pages) within a report. Each report has one or more tabs, each containing widgets (data visualizations). Called "tabs" in the UI, stored as "report_pages" in the backend. Use the `list-reports` tool first to find the report, then this tool to explore its tabs. Use `action` to choose the operation: - `list` — list all tabs in a report (id, name, position, widget count). By default only visible tabs are returned; pass `include_hidden: true` to also list hidden tabs - `show` — full tab details with all widgets and their types Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-report-tabs`.

list-report-tabs

Browse reports within spaces (client folders). Reports contain pages of data visualization widgets. Use the `list-spaces` tool first to find the right space, then this tool to explore reports inside it. Use `action` to choose the operation: - `list` — cursor-paginated list of reports. Each item includes `space_name`, `pages_count` (tab count), and `sources_summary` (connected integration names like `["Google Ads", "Meta Ads"]`). Filterable by `search` (name), `semantic_search` (meaning-based), `filter_space_ids`, `filter_channel_ids` (accepts slugs like `"google-ads"`), or `filter_source_ids` - `show` — full report details: pages with widgets, date range, share settings - `list_sources` — flat list of all data sources on a report, each with `is_sample_data` boolean - `resolve` — resolve a live-report URL, share URL, or hash to a report_id. Pass the URL or hash in `url_or_hash` Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-reports`.

list-reports

CALL THIS FIRST — before any other tool — on the first turn of every new conversation, and again when entering a new domain. This discovers the workflow skills for the server: the step-by-step playbooks that carry the correct workflow, field IDs, and gotchas for each Whatagraph task (widgets, blends, filters, reports, automations, sources, and more). Skills are the operating manual — the other tools expose the raw API, and these playbooks tell you how to drive it, so loading the matching one before you build a call is what makes multi-step flows succeed instead of failing on a field name or ID. The index is small, cached, and read-only. Use `load-skill` to read a skill's full content; skill names follow a predictable `whatagraph-<domain>` convention, so a known domain can be loaded directly without listing first. A skill is listed even when this agent is missing a tool it needs — those tools are named in `missing_required_tools`, so you can read the playbook and tell the user which grant to ask the team owner for. Use `action` to choose the operation: - `list` — every skill on the server - `search` — find skills matching a query (requires `query` parameter). Supports natural language queries (e.g. "how to create a report") and keyword searches.

list-skills

Browse report snapshots — saved versions of a report's structure. Use `action` to choose the operation: - `list` — cursor-paginated snapshots for a report with timestamps and creator (pass `cursor` from `page.cursor` for next page) - `show` — snapshot details including tab/widget/source counts and creator

list-snapshots

Browse source groups. Source groups combine multiple data sources into a single aggregated source with unified report type configurations. Use `action` to choose the operation: - `list` — cursor-paginated list of source groups, supports search (pass `cursor` from `page.cursor` for next page) - `show` — full source group details: sources, plus each config's `id`, `output_name` (read-only, computed from the config's structure — not a create/update parameter), name, and `etl_config_ids` (the per-channel ETL config ids to re-pass when updating). Each entry in `etl_configs` carries `is_premade`: a premade channel is Whatagraph-managed and CANNOT be edited with `update_config` — build a new source group instead. - `source_issues` — list sources with disabled ETL configs (sync issues). Pass `group_id` to check a specific group, or omit it to check all groups at once - `list_output_names` — list valid `output_name` values for creating a source group (requires `source_ids`) Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-source-groups`.

list-source-groups

Browse data sources connected to your team. Data sources are specific accounts/properties connected from integrations (e.g. a specific Google Ads account, a specific GA4 property). Use `action` to choose the operation: - `list` — list all connected data sources (cursor-paginated, pass `cursor` from `page.cursor` for next page) - `show` — full details for one source (requires `source_id`) - `list_metadata` — list metadata for source management; use `scope` to fetch only what you need (integrations, accounts, spaces, users, tags, categories, or all) - `list_report_types` — list available report types for a source (requires `source_id`) - `list_dimensions_and_metrics` — list available dimensions and metrics (cursor-paginated, requires `source_id`, optionally `report_type`, `filter`, `is_universal`) - `resolve_fields` — semantic search for dimensions and metrics by natural language (requires `source_id` and `query`, e.g. "revenue", "how much did we spend"). Returns the best-matching fields ranked by relevance - `list_usage` — list usage counts for sources across reports, blends, transfers, source groups, and overviews (requires `source_ids`) - `health_summary` — aggregated counts by status (ok, error) and total — no pagination, one call for the whole account Each source item carries `requires_report_type`; when it is true, call `list_report_types` and pass the result to widget and fetch calls. The playbook lists the returned attributes and the aliases accepted in `fields` projections. Start here when you need to understand what data is available before fetching it. Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-sources-and-data`.

list-sources

Browse spaces (also known as "client folders"). Spaces are the top-level containers that organize reports and data sources. If a user says "space", "folder", or "client", they mean a space. Use `action` to choose the operation: - `list` — cursor-paginated list of spaces the user can access (pass `cursor` from `page.cursor` for next page) - `show` — full details for one space (report/measurement counts) - `children` — list sub-spaces under one space **Home space:** Every team has a default "Home" space that holds reports not assigned to a named space. `list` returns it alongside named spaces — it is the one with `is_home=true`.

list-spaces

Browse report templates — reusable report blueprints. Templates can be applied to create new reports. Linked reports auto-update when their template changes. Use `action` to choose the operation: - `list` — cursor-paginated list of team templates with tags and linked report counts (pass `cursor` from `page.cursor` for next page) - `show` — template details: pages with widget counts, theme settings - `linked_reports` — reports created from this template (auto-sync with template changes)

list-templates

Browse report visual themes and color palettes. Control branding, colors, and visual appearance of reports. Use `action` to choose the operation: - `list_themes` — cursor-paginated list of available themes. Pass `report_id` to see both report-level and team-level themes with active status; omit `report_id` for team-level themes only. Response includes `applied_theme_id`, `applied_theme_source` (`"team"`, `"report"`, `"system"`, or `null`), and `team_has_themes` - `list_colors` — cursor-paginated list of color palettes. Pass `report_id` to see both report-level and team-level palettes with active status; omit `report_id` for team-level palettes only. Response includes `applied_color_id`, `applied_color_source` (`"team"`, `"report"`, `"system"`, or `null`), and `team_has_colors`. Names and IDs only — read a palette's actual colors with `show_color` - `show_theme` — single theme details: name, header, footer, and style options (requires `report_id` and `theme_id`) - `show_color` — a single palette's actual colors: `widget_colors`, `chart_colors`, `additional_colors` (requires `color_id`). `list_colors` returns names and IDs only, so this is the only way to read what a palette looks like. Works on built-in premade palettes too — pass the `applied_color_id` a report reports as `"system"` to read it, or to copy it as the base for a new palette. When `applied_theme_source` is `"system"`, the active theme is a built-in premade theme not included in the list — `team_has_themes: false` with a non-null `applied_theme_id` is expected in this case. **Email (whitelabel) themes** control report-delivery email branding (separate from report visual themes). These require the `whitelabel` feature. - `list_email_themes` — the team's email themes with their web/email domains and options - `list_web_domains` — web domains available for email themes (team + premade) — pick an `id` for `web_domain_id` - `list_email_domains` — email domains available for email themes (team + premade) — pick an `id` for `email_domain_id`

list-themes

Browse widgets on report tabs. Widgets are visual data components — charts, tables, single values, funnels, media, goals, etc. — that display marketing data from connected sources. If a user says "chart", "graph", "table", "KPI card", or "visualization", they mean a widget. Use `action` to choose the operation: - `list` — list all widgets in a report (summaries grouped by tab) - `show` — full widget details: type, layout, and per-config `metrics` / `dimensions` / `report_types` in the same shape `manage-widgets` accepts back, plus `source` and `options` (display settings only — bindings are not duplicated there). Image widget URLs in `options.images[].url` are returned as full, directly-usable URLs. Offline widgets (types 125-136) bind no metric, so they return no bindings; each row reports `data_summary` instead — `headers` and `data_row_count` for table and time-series shapes, `entry_names` and `entry_count` for the rest - `csv_export` — export widget data as CSV rows. Response contains `csv_rows: string[][]` (first row is headers, rest are data rows), `data_status` (`ready` = data loaded, `warning` = source error or warming up — check `warning_message` and retry after `retry_after_seconds`, `no_data` = no data for the date range), and `title` (widget display name) - `list_premade` — cursor-paginated list of premade/template widgets (no report_id needed, pass `cursor` from `page.cursor` for next page). Requires `channel_id` to scope results to a specific integration - `chart_presets` — how to set up a Dynamic Chart widget (type 142). Returns `families`: the chart families you set with `manage-widgets` `chart_type` (scatter, bubble, heatmap, candlestick, combo, polar, pie family, …), each with what it needs bound. That is the normal path — the chart follows the widget's bindings, so the user can keep editing it in the drawer. Also returns `presets` with a runnable `example_chart_spec` for the escape hatch, `chart_spec`, which pins every column and stops the drawer changing what is plotted. No report_id needed - `currency_exchange` — list the money metrics on a widget that can be converted to a different currency, with each metric's current `external_id`, `original_currency`, `exchange_currency`, `default_currency`, and `is_converted` flag. Feed the `external_id` into `manage-widgets` action=convert_currency or restore with action=restore_currency. Requires the Data Transformation premium feature - `conditional_formats` — read how a table widget (type 102) colours its cells by value. Each metric reports a `mode`: `manual` (threshold rules, returned in `position` order — first match wins — with `operator`, `value`, `value_end`, `text_color`, `background_color`), `auto` (the whole column shaded in seven tints of `auto_color` across its own low-to-high range), or `none`. A metric is in one mode or the other, never both. Narrow with `metric_external_id`. Write with `manage-widgets` action=set_conditional_formats / add_conditional_formats / set_auto_colors. `action=show` also flags which metrics carry rules via `has_conditional_format` - `list_icons` — the icon library available to widget rows (KPI cards, list rows). No report_id needed. Narrow with `search` (matches name, tags and groups) or `icon_set`. Write the returned `icon` value verbatim into `rows[].options.icon` via `manage-widgets`; `action=show` reads it back as `rows[].icon` Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-widgets`.

list-widgets

Load a workflow skill — a step-by-step playbook for a Whatagraph task that carries the correct workflow, field IDs, and gotchas. Skill names follow a predictable `whatagraph-<domain>` convention (e.g. `whatagraph-widgets`, `whatagraph-blends`, `whatagraph-reports`), and each write tool names its own skill in its description, so a known domain can be loaded directly here; use `list-skills` to discover skills when the name is unknown. A skill loads even when you are missing a tool it needs — the missing tools are named in the response, and you should relay them to the user so the team owner can grant them. Use `action` to choose the operation: - `show` — full skill content (markdown) - `header` — description + first 200 characters preview

load-skill

Manage the team's asset library: import a file from a URL, promote (move) an asset to a different owner node (team, space, report — or, in an agent conversation, the agent or conversation), add tags, change visibility, or publish an image asset to the public CDN so it can be used in reports. `import_url` and `promote` require an explicit `target_scope` plus the matching `target_space_id` or `target_report_id` where applicable — there is no silent team default. Remote images for report widgets and themes must enter through the library. Before setting `image_url` or `background_image_url` on a widget, or a theme header/footer `images[].url`, call `import_url` for the remote URL with `target_scope=team` so the asset stays reusable, then `publish` the returned asset, and pass only the stable public `url` that `publish` returns. A Whatagraph URL that is already published needs no import. If either step fails, leave the widget or theme unchanged — never use the original URL and never invent a replacement. `publish` — copy an image asset's bytes to public storage and return a stable public `url`. Use it to put a brand image into a report: find it with `list-assets`/`search-assets`, then `publish`, then pass the returned `url` to a widget/theme. Publishing makes that image publicly fetchable so it renders in shared reports for logged-out viewers — this exposes ANY team-reachable image publicly, not just curated brand logos (same exposure model as report images; deliberate). `promote` — move an asset to a different owner node (single owner, a move not a copy). When a user pastes a file into an agent conversation it becomes a conversation-scoped asset; find its id with `list-assets` (or the Available assets list), then `promote` it to the destination node (team, client, report, agent, or conversation) to place/move it.

manage-assets

Create and update data goals (metric targets) — called 'goals' in the UI. Use `action` to choose the operation: - `create` — create a new goal with a target value on a metric - `update` — update an existing goal's target, condition, or period Playbook — required fields, ID shapes, call sequence: `load-skill` `whatagraph-goals`.

manage-goals