Whatagraph MCP Server

Export a report as a file — Excel data or a rendered PDF. Returns a temporary download URL that expires in 1 hour. Creates a private export file and, for PDF, a background render job. Exporting never changes the report's sharing settings: an unshared report stays unshared.

Choose with format:

• xlsx (default) — every widget as its own sheet with its own columns and data. The file can be large; when you have a shell, inspect parts of it rather than loading it whole. Calendar and filter control widgets are skipped. Requires the widget-csv-export plan feature.
• pdf — the report rendered as a document. Layout is fixed and not configurable: landscape, 1440 CSS px wide, one page per tab, each page's height following that tab's own content (so pages in one document can differ in height).

A PDF is rendered in the background, so the first call does not return the file — it returns a pdf_job_id. Call again with that pdf_job_id to collect it: status: pending means it is still rendering (wait a few seconds and repeat), status: ready carries the download_url, and status: expired means the job is unknown or older than 24 hours, so start a new one.

Parameters:

• report_id (required) — report to export
• format (optional) — xlsx (default) or pdf
• tab_id (optional) — a single tab. For xlsx only that tab's widgets are exported; for pdf the document is that one tab rather than the whole report.
• widget_ids (optional, xlsx only) — limit to specific widgets
• from / till (optional, xlsx only, YYYY-MM-DD) — fallback date range for widgets that don't have one configured
• pdf_job_id (pdf only) — collect a render started by an earlier call

Playbook reference: whatagraph-export, available through load-skill. Documents parameters, identifiers and operation dependencies.

Read marketing metrics from an existing connected source in the authenticated Whatagraph team. Returns rows of metric values optionally grouped by dimensions for a date range. source_id must resolve to that team's source catalog. Reads use Whatagraph's reporting pipeline, which can use stored data or the already-connected account's provider API. This tool does not connect new accounts or accept arbitrary URLs. Use list-sources to discover the team's sources, report types, and field names. Important: when a failure is retryable, wait the retry_after seconds it gives you and call again with the same parameters. A permission_denied failure is not retryable — the source has to be reconnected first.

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 by size (at most ~50 KB, less inside an agent conversation). 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 size cap (a single cursor advances both blocks, each tracking its own position).

Playbook reference: whatagraph-sources-and-data, available through load-skill. Documents parameters, identifiers and operation dependencies.

Internal: returns the data payload for a widget preview. Called by the preview app, not by the model. Requires the token from preview-widget.

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.

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.

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

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

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.

A blend filed under another blend is a child. list hides children unless you pass parent_blend_id or include_children, and show returns a parent's direct children.

Playbook reference: whatagraph-blends, available through load-skill. Documents parameters, identifiers and operation dependencies.

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.

Read what a Custom API source already holds. A Custom API source is one you fill in yourself, so this is how you find out what is defined before you write to it with manage-custom-api. Use action to choose the operation:

• list_metrics — the metrics defined on the source (external_id, name, type, accumulator)
• list_dimensions — the dimensions defined on the source (external_id, name, type)
• list_data_points — the stored rows, newest date first. Narrow with from and till

Read the metrics and dimensions before defining any, so you update what is there instead of creating a near duplicate.

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 reference: whatagraph-custom-dimensions, available through load-skill. Documents parameters, identifiers and operation dependencies.

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 reference: whatagraph-custom-metrics, available through load-skill. Documents parameters, identifiers and operation dependencies.

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

A transfer to Whatagraph Storage returns storage_source_id on list and show. That is the data source the transfer created, and it is what you pass to manage-widgets to build a widget on stored data. It is null for every other destination.

List the dynamic integrations this team has built — connectors stored as database rows rather than shipped in code. Each entry reports its status, its live version and its newest version, so a re-draft in progress is visible. Pass channel_id for one integration's full version history, including which version is live and whether the newest draft has been sampled (publishing is gated on that).

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.

On a pre-made agent that assign_token route does not work: its tool set is shared by every team, so manage-agents refuses action=update and prohibits tools on the per-team route. Use manage-agents action=set_external_connectors there instead, passing each entry's connector_ulid (not its assign_token) in connector_ids — the full list that should be on, because it replaces the team's current set.

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.

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). Only team-level filters are listed; a filter attached to a widget config or a source is not one, so it is read with show by its ID
• show — full filter details with options and values, for any filter the team owns, including the config-scoped ones manage-filters creates on a widget config, source or blend sub-source
• 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 reference: whatagraph-filters, available through load-skill. Documents parameters, identifiers and operation dependencies.

Browse the Whatagraph integration catalog for the current team and integration accounts already authorized by the authenticated user. Account IDs resolve through that user's connected accounts; other users' accounts are rejected. Source and sub-source discovery can read the selected provider account using its existing credentials. This tool does not authorize new accounts, make requests to caller-selected URLs, or search the public internet. 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)

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

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 reference: whatagraph-report-tabs, available through load-skill. Documents parameters, identifiers and operation dependencies.

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 reference: whatagraph-reports, available through load-skill. Documents parameters, identifiers and operation dependencies.

CALL THIS FIRST when a task builds, changes or analyses something in Whatagraph and you do not yet know which skill covers it, and again when entering a new domain. Skip it when the skill name is known (load it with load-skill) or that skill is already loaded in this conversation. 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.

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

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 reference: whatagraph-source-groups, available through load-skill. Documents parameters, identifiers and operation dependencies.

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)
• list_dimension_values — list the actual values a dimension holds on that source, each as an external_id and a name (requires source_id and dimension). This can query the connected provider, using the source's existing credentials. This is the value list the filter UI shows: use it to find the campaign, ad or ad set IDs that the includes and excludes filter operators match on, and to check a value exists before filtering on it. Not every dimension can be listed; one that cannot says so
• 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.

list leaves out sources on the Whatagraph Storage, Blends, Source Groups and Looker Studio channels, because each has its own tool. Pass the channel in channels to list them anyway. That is the way to find a Whatagraph Storage source, which has no tool of its own; its id then works in manage-widgets like any other source.

Start here when you need to understand what data is available before fetching it.

Playbook reference: whatagraph-sources-and-data, available through load-skill. Documents parameters, identifiers and operation dependencies.

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.

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)

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

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 reference: whatagraph-widgets, available through load-skill. Documents parameters, identifiers and operation dependencies.

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

Check a report you just built or edited, before you tell the user it is done. Choose with action:

• data_check — load every widget's data and report only the widgets that failed, with the reason each one gave. An empty failures list means every widget loaded. Run this first: a widget whose data fails renders as an error box, so an image of it tells you less than the message does. Setting a date range does not fetch anything, so nothing warns you at the time you set it — this is the call that finds a range a source rejects, a field a source no longer has, or a source that needs reconnecting. It loads data for real, so it takes a few seconds per widget on a report nobody has opened yet, and tab_id narrows it to one tab. A failure usually belongs to the widgets it names rather than to the report: a range one source refuses can be correct for every other widget, so the repair is often manage-widgets action=batch_change_date_range with the widget_ids from the failure, not a new range for the whole report.
• images (default) — see what the report looks like. Returns its tabs as images you can look at directly, for layout, branding, spacing, chart readability, and whether any table is cut off.

images creates a private background render job and temporary render files, so it takes two calls:

1. Call with report_id (and tab_id for one tab). You get back a pdf_job_id and no images.
2. Call again with that pdf_job_id. While it is still rendering you get status: pending — wait a few seconds and repeat, do not poll in a tight loop. Once it is done you get the page images.

One tab renders as one image. Without tab_id you get every visible tab, up to 5 images per call; a longer report tells you what was left out, and tab_id gets you the rest. Pass tab_id whenever you only care about one tab — it is faster and much cheaper than rendering the whole report.

Images are downscaled to 1100 px wide. A very tall tab is cropped, and the response says so — do not describe a cropped page as if you had seen all of it.

This never changes the report's sharing settings. For a file to hand to a person, use export-report instead.

Render a Whatagraph widget inline in the chat as a live preview. The chat host displays the actual widget (same charts and theme as in the report) inside its sandbox.

Use widget_id from list-widgets (action=show or action=list). The widget renders with the report's current theme and the widget's saved date range, or a date_range_from / date_range_till override if supplied.

Read the extracted text of a document available to you, by its asset id (from list-assets). Use offset and limit to page through long files. Image and PDF attachments return a short pointer rather than text. Never guess a file's contents; read it.

Hybrid search over the documents available to you — MySQL full-text keyword matching on extracted text, titles and summaries, plus semantic (vector) matching that catches paraphrases the keywords miss. In an agent conversation it is scoped to this conversation, your agent and the team; otherwise to the assets you can access (team-owned, plus spaces/reports you can reach). Returns matching assets (id, title, kind, summary). Use read-document to read a match's full text. Narrow with scope, kind, or filter_space_ids / filter_report_ids for exact-node ownership.

Ask the provider, right now, whether one connected source is still reachable. Use this before telling a user a source is broken, because the stored status can be out of date in both directions.

list-sources reports the stored access status as status, which is written when a fetch last failed and is not re-checked until someone verifies the source. A source that has since been fixed at the provider keeps reading error until then. This tool makes the live call instead, so it answers what is true now.

It never changes a source's status. The stored access_status is left exactly as it was, whatever the probe finds, so it is always safe to call. Clearing a stale error still needs a person to press "Verify access" in the Whatagraph app.

Read outcome rather than just reachable:

• reachable — the provider listed the source under its own account.
• reachable_via_other_account — another connected account can serve it, which is how the platform will fetch it. Working, despite this account not listing it.
• not_available — the provider answered and did not list the source. This is a real problem and usually means access was removed at the provider.
• provider_error — the provider could not be reached, so reachability is unknown. Read provider_error.next_steps, and retry later when provider_error.retryable is true.

When stored_status_is_stale is true, the source works but is still stored as errored. Tell the user they can ignore the error, or press "Verify access" on that source to clear it.

See the actual ad-creative images (Facebook, Google, LinkedIn, TikTok, ...) from a report's media widgets, as images you can look at directly. Use this for creative analysis and creative QA — reviewing visual content, layout, contrast, typography, branding — instead of guessing from creative URLs or ad copy, which is all other tools return.

Returns up to 10 creative images per call, each numbered and mapped to its widget and ad name in the text block that comes first. If the report has more creatives, the response says how many were left out — pass offset to page through them, or narrow with tab_id / widget_ids.

Creatives come from media widgets only. Use list-widgets to find media widgets and export-report or fetch-data for the performance numbers to pair with what you see.

When you present your analysis, show each creative to the user by embedding its URL from the mapping as a markdown image (![ad name](url)) next to what you say about it — the user cannot see the images you received.

View data goals (called 'data goals' in the backend, 'goals' in the UI) — targets set on specific metrics to track progress toward KPIs. Use action to choose the operation:

• list — paginated list of goals with optional search/filter by source
• show — show details for a specific goal by ID
• status — measure named goals against freshly fetched data and report whether each is on track

list and show return a goal's configuration only — no progress and no verdict. active there means the goal is still running, NOT that it is being met. Never infer from list or show that a goal is on track, healthy, or within its limit: only status fetches actual data and decides.

status takes an explicit goal_ids array (max 20 per call) and returns, per goal: status (on_track / off_track / unknown), current_value, goal_value, percentage, projected_value (where the metric lands at the current run-rate) and days_remaining. A goal is off_track when it is projected to miss a target or breach a limit — not merely behind an even pace. unknown means the goal could not be measured (broken source, missing metric); treat it as a blind spot, never as a pass. To check many goals, call list first, then status in batches of 20.

Pagination: list uses page-number pagination (page + per_page), not cursor-based. Response includes page, per_page, last_page, and total_count.

View report and overview sharing settings and public share URLs. Use this to read an existing share link; use manage-sharing to create one or change its settings. Target a report with report_id or an overview with overview_id — one or the other, never both. Use action to choose the operation:

• show — current sharing settings and share URL. Returns is_shared (bool), and when shared: share_settings.id, share_settings.share_url, share_settings.require_password (bool) and share_settings.disable_date_changing (bool). A report share also returns share_settings.hash, share_settings.options and share_settings.date_range (from/till/period/compare_type); an overview share has none of those.

URL types: The share_url is the public viewer URL (e.g. https://reports.live/shared/<hash> for a report, .../shared/o/<ulid> for an overview). This is NOT the signed-in editor URL (https://live.whatagraph.com/client/<space_id>/live-report/<report_id>).

View team settings, subscription details, available roles, and perform global search across the entire platform. Use the search action when you don't know which domain (reports, spaces, overviews) to look in. Use action to choose the operation:

• show — team info: name, settings, enabled features
• search — global cross-domain search: finds reports, overviews, spaces, blends, and source groups matching a term. Returns a bounded set of top matches per domain (not paginated; cursor is not accepted)
• roles — available team roles for this team (admin, manager, editor)
• members — seated team members with their member_id, name, email, and current role (use member_id to change a member's role via manage-members)
• invites — pending invitations with invite_id, email, and role (use invite_id with manage-members for update_invite, resend_invite, or remove-invitations for cancel_invite; existing agent configurations use the supported historical name remove-members)
• show_subscription — current subscription plan and usage limits
• list_plans — available subscription plans

Playbook reference: whatagraph-team-and-members, available through load-skill. Documents parameters, identifiers and operation dependencies.

Manage an agent's recurring schedules — cron-cadenced runs that each start a new conversation with the agent as the schedule's creator. Use action:

• create — add a recurring schedule (requires agent_ulid, prompt, cron_expression). The prompt is the first message of every scheduled conversation — it must describe the work self-contained. The cron grid runs in the team timezone.
• list — see the agent's schedules (requires agent_ulid).
• update — change prompt, cron_expression, name or is_enabled (requires agent_ulid + schedule_ulid).
• cancel — remove a schedule (requires agent_ulid + schedule_ulid).

Schedules apply immediately — they are NOT part of the agent draft and need no publish. Timing is minute-granular. Cron examples: 0 */3 * * * every 3 hours, 0 8 * * * daily at 8:00, 30 12 * * 1 Mondays 12:30, 0 9 1 * * first day of month 9:00.

Destructive actions. cancel: removes the selected configuration. Breaks downstream: scheduled agent runs. The original configuration can be restored by another configuration edit.

Manage an agent's event triggers — product events that each start a new conversation with the agent as the trigger's creator (e.g. "when a report is created, apply the brand theme"). Use action:

• create — add a trigger (requires agent_ulid, prompt, event_type). The prompt is the first message of every triggered conversation — it must describe the work self-contained; the firing event's entity reference is appended automatically.
• list — see the agent's triggers (requires agent_ulid).
• update — change prompt, event_type, name or is_enabled (requires agent_ulid + trigger_ulid).
• cancel — remove a trigger (requires agent_ulid + trigger_ulid).

Triggers apply immediately — they are NOT part of the agent draft and need no publish. event_type must be one of the catalog values enumerated in this tool's input schema (each is a fully-qualified event class name; the schema lists the available ones).

Destructive actions. cancel: removes the selected configuration. Breaks downstream: event-triggered agent runs. The original configuration can be restored by another configuration edit.

Create and manage AI agents for the team. Use action to choose the operation:

• create — create a new agent (requires description). The agent starts enabled for the team and is immediately available. Optional: name, subtitle, instructions, model, max_steps, thinking_level, tools, provider_tool_capabilities, tools_mode. Omit name and subtitle to have the server generate a spec-compliant one-word name and a two-word subtitle from the instructions and tools.

• update — edit an existing agent (requires agent_ulid + at least one field to change). Changes are applied to a draft; the live agent is unaffected until published. If a draft exists from a different conversation, the edit is rejected with a draft_conflict error.

• publish — publish the agent's pending draft to the live agent, clearing the draft (requires agent_ulid). Fails with not_found when there is no draft. Only publish when the user has explicitly asked to save/publish — never auto-publish after an edit.

• discard — discard the agent's pending draft and its tool changes (requires agent_ulid).

• save_as_new — promote the agent's pending draft to a brand-new standalone agent, copying the source's knowledge; the source keeps its own draft-free config (requires agent_ulid). Team-owned agents only: a pre-made source is rejected with a conflict error, because its draft belongs to every team. To copy a pre-made agent, use duplicate instead.

• duplicate — deep-copy the agent named by agent_ulid into the acting team as a live, editable team agent, then apply any config fields sent alongside (instructions, tools, model, ...) to that copy directly, with no draft. The source is untouched. This is how a pre-made template becomes something a team can change. Optional name names the copy; omit it to have one generated. The copy is live at once, so use this only after the user has agreed to a duplicate.

• set_external_connectors — set which external connectors this team may use on a PRE-MADE agent (requires agent_ulid + connector_ids). An absolute set: send every ULID that should stay on, and an empty array to switch them all off. For an incremental change ("also add Notion"), read the current set from list-agents action=show first — its enabled_mcp_connection_ids is this team's grants on that agent — and send it with your change applied, or you will switch off the connectors you left out. A pre-made agent's instructions, skills and AI settings are the same for every team and cannot be changed, but its schedules, triggers, external connectors and context are this team's own. For a team-owned agent, set connectors through update's tools payload instead.

agent_ulid is always the published (source) agent ULID from list-agents, never a draft ULID. If tools is not provided, tools keep registry defaults. Use tools_mode: deny_unlisted to restrict the agent to only the listed tools; the default patch mode leaves unlisted tools untouched. Call list-agent-tools first for canonical tool_name values — do not invent names. Ambient tools (list-skills, load-skill) and agent-management tools included in tools are silently ignored.

Optional skills (on create and update) is a convenience macro: pass skill names (from list-skills) the agent must be able to run and their non-destructive core tools are auto-granted at the least permission that works: read tools always_allow, write tools needs_approval (so a skill never bypasses approvals). Destructive core tools are never auto-granted (returned in skill_coverage.skipped_destructive_tools); optional tools are never auto-granted (returned in skill_coverage.suggested_optional_tools). Explicitly denying a selected skill's core tool is rejected. The response's skill_coverage reports which skills are now visible, which stay hidden (with missing tools), and what was granted or skipped.

Note: when called inside Agent Builder, conversation_ulid is injected automatically by the wrapper — it is not part of the public schema.

Destructive actions. discard: permanently deletes data. Breaks downstream: unpublished draft edits. publish, update: can replace tool permissions when tools_mode=deny_unlisted; patch mode leaves unlisted tools unchanged. Breaks downstream: agent tool permissions. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Create and operate AI visibility monitors — track how AI answer engines (ChatGPT, Gemini, Claude, Google AI Overviews) talk about a brand via monitored prompts. Use action to choose the operation:

• create_monitor — set up a brand monitor. Requires brand_name; recommended: brand_domain, aliases, competitors (with their aliases), topics with nested prompts, engines. Creates a normal data source (stored data channel) — probe results flow to storage and are readable via fetch-data and widgets.
• update_monitor — change monitor settings after creation (requires monitor_id; any of brand_name, brand_domain, aliases, markets, engines, monthly_probe_limit, monitor_status). Only the fields you pass change.
• manage_brands — curate the brand registry (requires monitor_id). Pass competitors to add or update entries and remove_brands to drop them. Each entry takes name, optional domain, aliases and role:
  • competitor (default) — a real rival in the same buying decision. Counts in share of voice.
  • adjacent — a real brand that shows up in the same answers without competing for the purchase (a platform, a complement, a channel).
  • ignored — a string that is not a brand at all (a feature name, a protocol, a generic noun). Kept out of brand reporting. Entries are matched by name and merged into the registry, so re-sending one updates it and the 100-entry limit is per call, not per registry — classify a long worklist in successive batches rather than stopping at 100. Curation applies immediately to answers read through list-ai-visibility; fetch-data and widgets pick up changes after the next successful stored-data ingestion sweep. No re-probing is needed. Fold spelling variants into the parent brand's aliases rather than leaving them as separate entries.
• manage_surfaces — classify the domains AI engines cite (requires monitor_id). Pass citation_surfaces to add or update entries and remove_surfaces to drop them. Each entry takes domain and type:
  • review — a site where buyers rate and compare options in this market.
  • forum — a community thread where practitioners answer each other.
  • social — a platform where the content is a post or a feed.
  • video — a channel or platform where the content is video (YouTube-class surfaces).
  • editorial — a publication, blog or guide that writes about the market. Domains belonging to a brand in the registry are always the vendor's own site — never classify those here. Subdomains inherit their parent unless you register them separately. Anything you have not classified reads as unclassified, which is what the cited-domain worklist in list-ai-visibility action=show_monitor shows you. Classification applies immediately to citations read through list-ai-visibility; stored-data consumers update after the next successful ingestion sweep. Which domains count as what is market-specific — review sites are G2 and Capterra for software, Google Maps and Yelp for a local practice, Avvo for a law firm, Zocdoc for a clinic. Work out the surfaces this brand's buyers actually read instead of assuming a software market.
• add_prompts — add prompts to a monitor (requires monitor_id and prompts; each prompt: text, optional type (unbranded/comparison/branded/local), funnel_stage, persona and locale)
• update_prompts — retag or change the status of existing prompts (requires monitor_id, prompt_ids, and at least one of prompt_status, funnel_stage, persona). Tag changes re-slice collected answers on the next successful stored-data ingestion sweep; no re-probing is needed.
• probe_now — queue a probe batch instead of waiting for the daily schedule (requires monitor_id). Probes contact the configured external AI engines asynchronously, subject to active prompts, available engines and the remaining monthly budget. Check progress with list-ai-visibility action=list_answers; stored data follows on the next successful ingestion sweep. A successful queued response does not mean answers are already available.

Share of voice is only as honest as the registry: run list-ai-visibility with action=show_monitor to see which discovered brands out-mention the ones already tracked, and which cited domains are still unclassified, then curate both before quoting a share number or naming a place to go earn a mention.

Craft prompts the way real users ask: mostly unbranded category questions ("best marketing reporting tools for agencies"), some comparisons, a few branded checks. Ground them in the client's real GSC/GMB search terms via fetch-data when those sources are connected.

Destructive actions. manage_brands, manage_surfaces: updates entries by name or domain and removes only entries explicitly listed in remove_brands or remove_surfaces; omitted entries are preserved. Breaks downstream: role labelling on answers already collected.

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.

Report widget image_url and background_image_url, and theme header/footer images[].url, accept published Whatagraph image URLs. import_url with target_scope=team creates a reusable library asset; publish copies an image asset to public storage and returns its stable URL. An already-published Whatagraph URL needs no new import. A failed import or publication provides no replacement URL and does not update any widget or theme. Importing alone does not publish an asset.

The report shortcut widget (type 141) takes a different key. It has no image_url: it reads rows[0].configs[0].options.images as [{"url": "<published url>", "title": "<caption>"}], and it draws that image only when linked_report_thumbnail_style on the same config options is image. The array contains published Whatagraph image URLs. image_url on a type 141 widget is stored and never read, so the card keeps its live report preview.

publish — copy an image asset's bytes to public storage and return a stable public url. Publishing makes the image publicly fetchable, including by logged-out viewers of shared reports. This can expose any team-reachable image, not just curated brand logos. Private library ownership does not prevent this public exposure after publication.

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. list-assets and the Available assets list expose its ID; target_scope and the matching target ID determine the destination owner for the move.

Playbook reference: whatagraph-assets, available through load-skill. Documents parameters, identifiers and operation dependencies.

Create and update scheduled report delivery. If a user says "schedule", "automated report", or "email delivery", they mean automation. Use action to choose the operation:

• create — create a new automation schedule for a report
• update — update schedule, recipients, or format
• review — approve the next automated delivery (when needs_approval is true)

Destructive actions. update: replaces collections, so omitted items are removed. Breaks downstream: automation recipients.

Playbook reference: whatagraph-automations, available through load-skill. Documents parameters, identifiers and operation dependencies.

Create, update, and duplicate data blends. Blends combine data from multiple sources into a single virtual data source for cross-channel reporting. Use action to choose the operation:

• create — create a new blend with sub-sources and join configuration
• update — update blend name, description, currency, sub-sources, and joins
• duplicate — duplicate an existing blend with all sub-sources and joins Use list-blends with action=list to find blend IDs.

A sub-source can carry its own filter via items[].filter_id, applied to that channel's rows before the join runs. This is not the same as filtering the blend's output — use it when only one of the joined channels should be narrowed.

create accepts parent_blend_id, pointing at another blend in the same team. A blend that has a parent is a child: it does not appear in the customer's list of blends and appears on its parent instead, while staying a normal source everywhere else. The parent is fixed at creation, so update and duplicate reject the key. A duplicate keeps the original's parent.

Destructive actions. update: replaces collections, so omitted items are removed. Breaks downstream: widgets, reports, filters. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-blends, available through load-skill. Documents parameters, identifiers and operation dependencies.

Create, message, and manage 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 — spawn (start a child agent conversation; requires parent_agent_ulid, parent_conversation_id, child_agent_ulid, message), send_message (follow-up to a child; requires conversation_id, message), close (requires conversation_id), cancel (requires conversation_id).
• type=user — create (start a Chat conversation with an initial message; may route agent-management messages to the Agent Builder; optional agent_ulid, attachment_urls), send_message (requires conversation_id, message; optional attachment_urls), cancel (requires conversation_id).
• type=builder — create (start an Agent Builder conversation with an initial message; optional context_agent_ulid to edit an existing agent), send_message (requires conversation_id, message), cancel (requires conversation_id). After type=user create, use the returned read_tool_name/read_tool_type/read_tool_action to read the conversation back with list-conversations. close ends an inter-agent conversation; cancel stops its active work and pending turns. A closed or cancelled inter-agent conversation cannot be resumed by sending another message. Neither operation deletes the saved conversation history.

Put your own numbers into Whatagraph. A Custom API source is one you fill in yourself, for data Whatagraph has no connector for. Once the rows are in, they work in any widget, report or blend like any other source. Use action to choose the operation:

• create_source — make a new Custom API source (requires name, optional space_ids)
• define_schema — create or update the metrics and dimensions the rows will use. Matching on external_id, so calling it again updates rather than duplicates
• push_data — send rows (requires rows). One row is one day. Default mode is replace_dates, which drops what the source holds for each date in the payload and then inserts, so re-sending a day corrects it. Pass mode=append only when you are adding rows to a day you have already sent
• delete_data — remove every stored row between from and till

Define the metrics and dimensions before pushing rows: a widget built on a dimension that is missing for part of its date range can error. The Date dimension already exists, along with every time grouping built from it, so never define one.

You do not need an access token. This tool writes to the source directly.

Destructive actions. delete_data: permanently deletes data. Breaks downstream: widgets, blends and reports built on the source. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Create, update, and duplicate custom dimensions. Use action to choose the operation:

• create — create a new custom dimension (requires name, map_type, transformation_level)
• update — update dimension name, description, mappings, conditions, or tags
• duplicate — duplicate an existing custom dimension
• add_tag — add a tag to a tag-type custom dimension
• remove_tag — remove a tag from a tag-type custom dimension
• assign_tag_sources — assign sources to a specific tag (replaces existing source assignments for that tag)
• preview_ai — preview AI-generated dimension output before saving On create, set parent_id to file the new dimension under another custom dimension. A dimension with a parent is hidden from the customer's list and shown on its parent's page, but works like any other dimension everywhere else. A parent is fixed at creation and update cannot change it. The playbook says when to create one.

Destructive actions. update, assign_tag_sources: replaces collections, so omitted items are removed. Breaks downstream: widgets, filters, reports. remove_tag: permanently deletes data. Breaks downstream: widgets, filters. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-custom-dimensions, available through load-skill. Documents parameters, identifiers and operation dependencies.

Create, update, and duplicate custom metrics (universal metrics). Custom metrics combine data from multiple sources using formulas or aggregations. Use action to choose the operation:

• create — create a new custom metric (requires name, map_type, transformation_level, fields)
• update — update metric name, description, fields, or formula settings
• duplicate — duplicate an existing custom metric On create, set parent_id to file the new metric under another custom metric. A metric with a parent is hidden from the customer's list and shown on its parent's page, but works like any other metric everywhere else. A parent is fixed at creation and update cannot change it. The playbook says when to create one.

Destructive actions. update: replaces collections, so omitted items are removed. Breaks downstream: widgets, filters, reports. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-custom-metrics, available through load-skill. Documents parameters, identifiers and operation dependencies.

Create and control data transfers (ETL exports to BigQuery, Looker Studio, or Whatagraph Storage). Use action to choose the operation:

• create — set up a new transfer (requires destination_id, name, frequency, integration_source_id, configs)
• stop — pause a transfer so it stops syncing new data (requires transfer_id)
• resume — re-activate a stopped transfer and backfill any missed dates (requires transfer_id)
• resync — re-fetch a date range for an ACTIVE transfer (requires transfer_id, from, to)
• update — rename a transfer and/or change how far back it backfills (requires transfer_id, and at least one of name/backfill_until)

A transfer covers one data source, named once in integration_source_id, and every table in it reads that source. To transfer a second channel, create a second transfer.

Each entry in configs becomes one table and consumes one source credit. Before creating, read the whatagraph-destinations skill: it covers which sources can be transferred, the date dimension every table needs, and what each destination requires. Use list-destinations (action=list) to find transfer IDs, and (action=list_destination_types) to see the destinations available.

Creating checks every table against the source before it writes anything, so a rejected report type, dimension or metric comes back as an error naming that table. Pass validate_only=true to run that check and create nothing.

Playbook reference: whatagraph-destinations, available through load-skill. Documents parameters, identifiers and operation dependencies.

Build and publish a dynamic integration — a connector stored as database rows and run through the declarative engine, with no code deploy. Actions, run in order:

• draft — store manifest_yaml + spec_yaml + schema + host_allowlist. Omit channel_id to create a new integration; pass it to append a new version of an existing one. host_allowlist is required: the integration may only call those exact hosts, over HTTPS, and never a private address. Re-drafting a published integration does NOT change what live reports read — only publish moves the pointer.
• set-oauth-client — oauth2 flows only. Store the client_id and client_secret of the OAuth application the user registered with the provider. Register the oauth_redirect_urls that draft returns on that application first.
• authorize — oauth2 flows only, in place of test-auth. Returns authorize_url, a Whatagraph link the user opens in a browser to approve access; the callback stores the credentials. Before the first publish the consent runs the newest draft, after it the live version, so a change that needs a new consent cannot be proven on a draft once published.
• test-auth — run the definition's real authorization flow against the live API with credentials. A 401/403 fails and stores nothing; success stores the credentials.
• sample — read live records from stream through the full engine using the stored credentials. Publishing is gated on this: it proves the definition can fetch.
• publish — promote the newest draft to live, write the report-type, dimension and metric rows, and sync the internal storage template.
• connect — run source discovery (source_specification.discovery) against the live API. Pass source_external_ids to select sources; when several are discovered and no selection is provided, return candidates and attach nothing. A single discovered source is attached automatically. Each selected source is stored through an internal transfer, and reads are served from storage. Idempotent: reconnecting after a removal restores the same source rows, so the widgets built on them survive.
• resync — re-fetch stored data after fixing a definition. Republishing alone does NOT correct data already in storage: a fetch that "succeeded" with wrong values is not a failed job, so nothing re-runs it. This is how corrected data gets there. Use delete-dynamic-integrations to remove an integration that was never connected to. Every action after draft takes channel_id. Each report type in schema needs a stream of the same name in the manifest, or one stream named general to serve them all.

Create and update data filters. Filters narrow down displayed data on sources and widgets. Use action to choose the operation:

• create — create a new filter. Use dimension + dimension_operator for dimension filters, metric + metric_operator for metric filters, or filter_parameters alone for parameter-only filters (e.g. attribution windows). A widget config, source or blend sub-source holds one filter at a time, so creating a filter on a target that already has one replaces it, and the response then lists the deleted filter in replaced_filter_ids. To give a target a second condition, call add on the filter it already has instead of calling create again
• add — add a condition to an existing filter. On a version 2 filter, group=AND (default) creates a new row group and group=OR adds an OR condition to an existing row group, and dimensions and metrics cannot be mixed in the same row group. On a version 1 filter, row groups combine with OR, so both operators join the condition into the row group given by row_index (the last one by default), and a row group there may hold both dimensions and metrics. The response reports the filter's version
• update — update an existing filter's operator and/or value. A dimension_operator updates dimension rows, a metric_operator updates metric rows, and value updates the rows of the kind you are addressing (or all rows when no operator is given)
• attach — attach a team-level filter to a widget config, report source, or blend sub-source (requires filter_id and one of widget_config_id, source_id, blend_sub_source_id). Creates a copy of the filter attached to the target

A blend sub-source filter is applied to that channel's rows before the blend join runs, which is not the same as filtering the blend's output. Use list-blends with action=show to find sub_sources[].id values.

Idempotency: create and attach accept an optional idempotency_key (a client-generated UUID). If a timeout or network error leaves the result uncertain, resend the same call with the same key — the original result is returned instead of creating a duplicate. Use a fresh key for each distinct operation.

Destructive actions. create: replaces collections, so omitted items are removed. Breaks downstream: filters already on the target widget or source.

Playbook reference: whatagraph-filters, available through load-skill. Documents parameters, identifiers and operation dependencies.

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 reference: whatagraph-goals, available through load-skill. Documents parameters, identifiers and operation dependencies.

Connect sources from already-connected integration accounts and assign them to spaces. Use action to choose the operation:

• add_sources — connect new sources from an already-connected account (requires channel_id, account_id, source_ids)
• sync_to_clients — assign a source to spaces (requires source_id, client_ids)

Destructive actions. sync_to_clients: replaces collections, so omitted items are removed. Breaks downstream: reports and widgets in the unassigned spaces. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-integrations-admin, available through load-skill. Documents parameters, identifiers and operation dependencies.

Invite new team members, manage pending invitations, and change the role of an existing member. Use action to choose the operation:

• invite — send an invitation email with a specified role
• update_invite — change the role on a pending invitation
• resend_invite — resend an invitation email
• update_member_role — change the role of an existing (already-joined) member (requires member_id and role)

Choose a role using view-team with action=roles to discover available roles.

Space access follows the role, by design:

• admin and manager always have access to every space; their space access is reset to all spaces on each role change, and spaces is ignored for them.
• editor is scoped to specific spaces. You must pass the editor's complete spaces list on every change — it replaces their current access, so omitting a space removes it.

Find an existing member's member_id with view-team action=members. Removing a seated member is not supported here — do it in the Whatagraph app.

Destructive actions. update_member_role, update_invite: replaces collections, so omitted items are removed. Breaks downstream: member space access.

Playbook reference: whatagraph-team-and-members, available through load-skill. Documents parameters, identifiers and operation dependencies.

Create or update overviews (KPI tracking dashboards) that monitor specific metrics over time with per-metric visualizations. Use action=create to create a new overview, or action=update (with overview_id) to change an existing one. update supports partial updates: only supply the fields you want to change. Omitted fields keep their current values. For example, to rename an overview just pass name — no need to resupply source_id or metrics. When metrics or dimensions are supplied on update, they fully replace the existing set — partial metric lists are not merged. Targets are not part of an overview: to track a metric against a target, create a goal with manage-goals. Pass filter_id to narrow the overview's data with a team-level filter; an overview holds one filter, so a new one replaces the old and null removes it.

Destructive actions. update: replaces metric or dimension collections only when supplied; omitted collections are preserved, while an explicit filter_id replaces or removes the current filter. Breaks downstream: overview notifications, overview shares.

Playbook reference: whatagraph-overviews, available through load-skill. Documents parameters, identifiers and operation dependencies.

Create, duplicate, reorder, and update tabs within a report. Use action to choose the operation:

• create — create a new blank tab in a report (requires name)
• duplicate — duplicate a tab with all its widgets (requires tab_id)
• update — update tab name/settings (requires tab_id)
• sort — reorder tabs within a report (requires tab_order)
• move_widgets — move widgets from one tab to another (requires tab_id, widget_ids, target_tab_id)
• set_layout — set the report's grid layout (layout) and its display settings: layout_whitelabel (the toggle that shows or hides the theme header and footer), show_page_numbers and border_radius_size. Changing the grid only works on a report with NO widgets yet, because a different grid reshapes what every widget sits in, so set the layout when you start a report and then add widgets. The display settings can be changed at any time, on a report with widgets too — omit layout to keep the grid the report already has.
• insert_row_space — open empty rows in the middle of a tab (requires tab_id, position_y; row_count defaults to 1). Every widget starting at position_y or below moves down by row_count rows. This only moves widgets; it adds none. "Add a row" / "insert a line" is done when this returns — only create a widget in the new space if the user asked for a widget, and never invent its type or content.
• remove_row_space — close empty rows in the middle of a tab (requires tab_id, position_y; row_count defaults to 1). Everything below moves up. The rows must already be empty — this never deletes or resizes a widget.

List the report's tabs first to find tab IDs.

Playbook reference: whatagraph-report-tabs, available through load-skill. Documents parameters, identifiers and operation dependencies.

Create, duplicate, update reports and manage their attached data sources. Use action to choose the operation:

• create — blank report in a space, with a default tab (tab_name names it). layout sets the grid orientation up front, defaulting to printing_landscape_6x6
• create_from_template — report linked to a template, auto-updating. layout overrides the template's orientation, and is honoured only while the report still has no widgets
• duplicate — copy a report with all pages, widgets, and configs
• update — report name and/or date range. date_range is rejected on an automated report, whose range comes from its schedule. The response's type is read-only: manage-automations action=create flips it to automated, delete-automations flips it back
• attach_source — attach sources (integration_source_ids) or sample-data placeholders (channel_ids), batched. A real source must be assigned to this report's space or to none; otherwise assign it first with manage-integrations action=sync_to_clients
• detach_source — detach a source. delete_widgets: true deletes its widgets; otherwise they are remapped to another attached source of the same channel, or to sample data. The response reports which widgets were deleted, remapped, and to what
• change_sources — bulk-swap attached sources, attaching one when the old side is sample data. The response flags any widget that ended up on sample data
• move — move a report to another space (report_id, client_id). keep_sources=false resets attached sources to sample data; the default keeps them

Destructive actions. detach_source, change_sources: permanently deletes data. Breaks downstream: widgets, reports. move: replaces collections, so omitted items are removed. Breaks downstream: widgets, report sources. The original configuration can be restored by another configuration edit. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-reports, available through load-skill. Documents parameters, identifiers and operation dependencies.

Create and update report and overview share links with optional password protection. If a user says "share link", they may mean this tool or view-sharing. Target a report with report_id or an overview with overview_id — one or the other, never both. Use action to choose the operation:

• create — create a public share link with optional password. Idempotent: if a share link already exists, returns an error pointing to update — it will NOT create a duplicate or silently overwrite the existing link
• update — update share settings (password, date range control, IQ chat). Pass share_id or just report_id (the share is resolved automatically since each report has at most one share link)

Getting a file out of a report is not sharing. PDF and Excel exports live in export-report, which is read-only and does not touch a report's share status. Use that tool instead — creating a share link is not a step towards a download.

URL types: The share_url returned by create/update is the public viewer URL (e.g. https://reports.live/shared/<hash> for a report, .../shared/o/<ulid> for an overview). This is NOT the signed-in editor URL (https://live.whatagraph.com/client/<space_id>/live-report/<report_id>).

Playbook reference: whatagraph-sharing, available through load-skill. Documents parameters, identifiers and operation dependencies.

Save and restore report snapshots. Use action to choose the operation:

• create — save current report state as a snapshot
• restore — restore report to a previous snapshot state (overwrites current structure)

Destructive actions. restore: permanently deletes data. Breaks downstream: report tabs, widgets, report sources. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-snapshots, available through load-skill. Documents parameters, identifiers and operation dependencies.

Create, update, duplicate source groups, or resolve sync issues. Source groups aggregate multiple data sources into a single virtual source. Only legacy plans limit source groups by source credits. When such a plan has too few, create, update and duplicate fail with the credits available and needed. Use action to choose the operation:

• create_config — build ONE team-internal ETL config for a single channel from a source, report type, and fields. Returns an etl_config_id. Call once per channel BEFORE create. Load the whatagraph-source-groups skill — creation is a strict multi-step flow (resolve fields → verify with fetch-data → create_config per channel → create).
• create — create a new source group from integration_source_ids and a single config holding the etl_config_ids returned by create_config (one per channel).
• update_config — PATCH an existing channel's ETL config (fields changed). Same etl_config_id is kept. Verify with fetch-data first. Skip for channels that didn't change. Channels marked is_premade by list-source-groups action=show are Whatagraph-managed and CANNOT be edited — build a new source group instead of working around it.
• update — update an existing source group. Simple changes (name/description/currency/sources) need only those fields — omit configs. To change fields, first update_config the changed channels (and create_config any new channel), then pass every config the group has (from action=show), each with its existing id and full etl_config_ids set. Configs are neither added nor removed here, and a channel's etl_config_id may only be dropped when its sources leave in the same call. Load the whatagraph-source-groups skill.
• duplicate — duplicate an existing source group
• resolve_issues — re-enable disabled ETL configs for specified sources. Note: this restarts the affected sources' data transfers, which refreshes those sources for every source group that shares them — not just this group.

Destructive actions. update, update_config: replaces collections, so omitted items are removed. Breaks downstream: widgets, blends, reports, transfers. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-source-groups, available through load-skill. Documents parameters, identifiers and operation dependencies.

Modify data sources — apply tags, change currency settings, or force a data refresh on connected sources. Use action to choose the operation:

• tag — assign EXISTING tag values to one or more sources (requires source_ids, tag_id, tag_value_ids). This only ASSIGNS tags that already exist — it does NOT create them. To CREATE a tag (a tag dimension and its values, optionally assigning sources in the same call), use manage-custom-dimensions with action=create and map_type=tag. Discover existing tag_id/tag_value_ids with list-sources action=list_metadata (scope tags).
• set_currency — override the display currency for selected sources (requires source_ids, currency)
• refresh — clear cached data for selected sources so the next read re-fetches fresh data from the provider (requires source_ids, max 10 per call)

Destructive actions. tag: replaces collections, so omitted items are removed. Breaks downstream: widgets, filters, blends. The original configuration can be restored by another configuration edit.

Playbook reference: whatagraph-sources-and-data, available through load-skill. Documents parameters, identifiers and operation dependencies.

Create and update spaces (client folders). Spaces organize reports and data sources. If a user says "space", "folder", or "client", they mean a space. Use action to choose the operation:

• create — create a new space, optionally nested under a parent
• update — update space name, description, or parent (cannot update the Home space)
• set_theme — set cover, icon, and font for a space

Playbook reference: whatagraph-spaces, available through load-skill. Documents parameters, identifiers and operation dependencies.

Update team name and settings. Use action to choose the operation:

• update — update team name and/or localization settings (timezone, currency, decimal places, start of week, region, text direction)

Playbook reference: whatagraph-team-and-members, available through load-skill. Documents parameters, identifiers and operation dependencies.

Create, update, and edit report templates, and propagate template changes to linked reports. Use action to choose the operation:

• create — create a template from an existing report (converts report structure to a reusable blueprint)
• update — update template name/settings
• edit — open the template as an editable DRAFT report and return its draft_report.id. Modify the draft's tabs/widgets with manage-report-tabs and manage-widgets, then publish it. Optionally pass client_id to choose which space hosts the temporary draft (defaults to the home space).
• publish — push an edited draft report's structure back into the template AND propagate the changes (added/removed/renamed tabs and widgets) to every linked report. Requires template_id. Optionally pass report_id (the draft returned by edit); if omitted, the most recent draft for this template is used automatically. The draft report is consumed (deleted) on publish; propagation to linked reports runs in the background.

Structural changes to a template only reach linked reports through edit → modify the draft → publish. Editing the original source report a template was created from does NOT propagate.

Destructive actions. publish: replaces collections, so omitted items are removed. Breaks downstream: templates, linked reports. The original configuration can be restored by another configuration edit.

Playbook reference: whatagraph-templates, available through load-skill. Documents parameters, identifiers and operation dependencies.

Apply themes and color palettes to reports, and create or update custom palettes. Color palettes and themes are separate concepts:

• Color palette controls widget/chart colors only.
• Theme controls branding (logo, header, footer) and can optionally link a color palette.

Use action to choose the operation:

• enable_theme — activate a theme on a report (requires report_id, theme_id)
• enable_color — activate a color palette on a report (requires report_id, color_id)
• create_theme — create a new custom theme (requires name)
• create_color — create a new color palette (requires colors). Pass colors.theme_id to bind the new palette to that theme
• update_color — update an existing color palette (requires color_id, colors)
• update_theme — update an existing custom theme (requires theme_id)
• create_email_theme / update_email_theme / enable_email_theme — manage email (whitelabel) themes (requires whitelabel feature)

Load the whatagraph-themes skill for detailed color format rules, resolution order, email theme setup, and workflow guidance.

Playbook reference: whatagraph-themes, available through load-skill. Documents parameters, identifiers and operation dependencies.

Browser side-channel for getting local or pasted files (no URL) into the team's asset library.

create — return a browser upload link the user opens in a new tab to upload files directly. Requires a target_scope (team, client, or report) plus the matching target_space_id or target_report_id where applicable — there is no silent team default.

check — call after the user says they finished uploading; pass the token from create to get per-file results (added / failed) for the session.

Create, update, and duplicate widgets on report tabs. Use action to choose the operation:

• create — new widget on a tab (channel_id, widget_type_id, tab_id). For a chart family with no dedicated widget type (scatter, bubble, stacked bar, stacked area, heatmap, candlestick, combo, top-N) create widget_type_id 142 and pass chart_type
• apply_premade — apply a premade widget to a tab (widget_id, tab_id). Alias: create_premade
• update — name, position, options, rows, date range (widget_id). Does not write AI text settings — use update_ai_text for those. Pass dry_run: true with a chart_type or chart_spec to compile it against the widget's real data and see what it would plot without saving anything
• duplicate — copy one widget (widget_id); the copy is packed into the next free grid slot
• batch_duplicate — copy several at once (widget_ids), tiled across the grid
• batch_change_source — repoint several widgets (widget_ids, source_id)
• batch_change_settings — apply option keys to several widgets (widget_ids, settings)
• batch_change_date_range / batch_delete_date_range — set or clear date-range overrides (widget_ids)
• batch_change_filter_visibility — toggle source filters (widget_ids, source_filter_off)
• update_ai_text — AI text settings for a comment widget (widget_id, ai_text). Unless auto_update is true it also queues the summary and returns a summary_job_id; the summary is not in that response. Call again with the same widget_id and that summary_job_id to collect it: status: pending means it is still generating (wait a few seconds and repeat), status: ready carries the content, status: failed says why, and status: expired means the job is unknown or older than 24 hours, so queue a new one. Refused up front when every widget it would read serves sample data
• convert_currency / restore_currency — convert money metrics to a target currency, or revert them all (widget_id). Needs the Data Transformation feature
• add_row — append a row copied from the last one (widget_id)
• remove_row — drop a row (widget_id, row_id); the last remaining row cannot be removed
• set_conditional_formats — replace every conditional-formatting rule on one metric of a table widget (widget_id, metric_external_id, conditional_formats). Replace-all: the rules you send become the metric's complete set, so read the current ones with list-widgets action=conditional_formats first, or you will drop them. An empty array clears the metric
• add_conditional_formats — append rules to a metric, keeping the existing ones (widget_id, metric_external_id, conditional_formats)
• set_auto_colors — shade a table metric's column in seven tints of one base colour across its own low-to-high range, no thresholds to author (widget_id, metric_external_id, auto_color). Pass auto_color: null to turn it off. A metric renders either auto colors or manual rules, never both — setting one clears the other
• promote_preview — move an on-demand widget onto a real report page (widget_id, report_id, tab_id, optional position). The widget id does not change, so a preview card already in the chat keeps rendering, and the widget stops expiring. Refused when a bound source is not assigned to the destination report's space

Showing a widget without committing it. When someone asks what a widget would look like and has not named a report to build it in, create it with preview=true and no report_id/tab_id. That widget is real — live data, real theme, real chart rendering — but belongs to no report, so nothing is added to the user's reports until they ask. Render it in chat (render_widget in the in-app agent, preview-widget over MCP), refine it with action=update preview=true, and move it into a report with action=promote_preview. Previews expire, so build in the report directly whenever the user named one.

Destructive actions. update, set_conditional_formats, set_auto_colors, batch_delete_date_range: replaces collections, so omitted items are removed. remove_row: removes the selected configuration. Breaks downstream: conditional formats on the row. The original configuration can be restored by another configuration edit.

Playbook reference: whatagraph-widgets, available through load-skill. Documents parameters, identifiers and operation dependencies.

Delete an AI agent for the team (soft delete). Deletion is blocked while the agent has active conversations (processing, retrying, cancelling, or awaiting action) — wait for them to finish or cancel them first. Use action=delete with an agent_ulid. Use list-agents with action=list to find ULIDs.

Destructive actions. Every action of this tool: permanently deletes data. Breaks downstream: agent schedules, agent triggers, conversations. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

Permanently delete an AI visibility monitor, its prompts, and all captured answers. The monitor's data source is removed from the team, so widgets built on it stop loading. Use action=delete_monitor with the monitor_id from list-ai-visibility.

Destructive actions. Every action of this tool: permanently deletes data. Breaks downstream: widgets, reports. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

Remove scheduled report delivery configurations.

Destructive actions. Every action of this tool: permanently deletes data. Breaks downstream: scheduled report deliveries. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

Delete data blends.

Destructive actions. Every action of this tool: permanently deletes data. Breaks downstream: widgets, reports, filters, goals. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

Delete one of your conversations (soft delete). Only type=user (chat) conversations can be deleted — inter-agent and builder conversations are managed by their agent lifecycle and are not deletable here. Deletion is blocked while a conversation is still active (processing, retrying, cancelling, or awaiting action) — cancel it first. Use action=delete with a type and conversation_id.

Destructive actions. Every action of this tool: permanently deletes data. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

Permanently delete one or more custom dimensions and all their related mappings, tags, and fields. A dimension still used by widgets or filters is blocked (unless force=true) and the references are reported, because deletion is a hard delete that cannot be undone.

Destructive actions. Every action of this tool: permanently deletes data. Breaks downstream: widgets, filters, reports, blends. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

Permanently delete one or more custom metrics and all their related field mappings. A metric still used by widgets or filters is blocked (unless force=true) and the references are reported, because deletion is a hard delete that cannot be undone.

Destructive actions. Every action of this tool: permanently deletes data. Breaks downstream: widgets, filters, reports. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

Delete data transfers. This removes the ETL transfer configuration and stops data syncing. Use action to choose the operation:

• delete — delete a transfer. Requires confirmation.

Destructive actions. Every action of this tool: permanently deletes data. Breaks downstream: source groups, widgets. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

Delete a dynamic integration that has never been connected.

Destructive actions. Every action of this tool: permanently deletes data. Breaks downstream: integration_definitions, integration_keys. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

Delete a filter by ID. This removes the filter (soft delete). Use action to choose the operation:

• delete — remove a filter (soft delete)

Destructive actions. Every action of this tool: permanently deletes data. Breaks downstream: widgets, blends, overviews. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

Delete goals.

Destructive actions. Every action of this tool: permanently deletes data. Breaks downstream: overviews. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

Delete overviews.

Destructive actions. Every action of this tool: permanently deletes data. Breaks downstream: overview shares. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

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: soft-deletes a tab and its widgets; the restore action can recover them while their deleted records remain available. Breaks downstream: widgets, reports. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

Delete reports.

Destructive actions. Every action of this tool: permanently deletes data. Breaks downstream: report tabs, widgets, automations, shares, snapshots. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

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. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

Delete report snapshots. Use action to choose the operation:

• delete — delete a snapshot

Destructive actions. Every action of this tool: permanently deletes data. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

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. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

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. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

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. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

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. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

Delete custom themes and color palettes.

Destructive actions. Every action of this tool: permanently deletes data. Breaks downstream: reports, templates, spaces. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

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: soft-deletes widgets; the restore action can recover them while their deleted records remain available. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

Disconnect sources from the team or remove an integration account entirely. Use action to choose the operation:

• remove_sources — disconnect specific sources from the team (requires account_id, source_ids). Requires confirmation.
• delete_account — remove an integration account and all its sources (requires account_id). OAuth re-connection required to re-add. Requires confirmation.

Destructive actions. Every action of this tool: permanently deletes data. Breaks downstream: sources, widgets, blends, reports, transfers. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.

Cancel a pending team invitation using action=cancel_invite and its invite_id. This invalidates that invitation. It does not remove an accepted team member or change their role. Pending invitation IDs are returned by the team-member management tool.

Destructive actions. Every action of this tool: permanently deletes data. Breaks downstream: pending invites. These actions use a two-step server contract: the first call returns a preview without changes; executing the same arguments requires its single-use confirm_token.

Playbook reference: whatagraph-deleting, available through load-skill. Documents parameters, identifiers and operation dependencies.