Apache Superset Webhook MCP Server

Apache Superset Webhook

Each stored delivery is one Superset Alerts & Reports webhook POST — fired when an alert SQL condition is met or a scheduled report runs. Superset also delivers via email and Slack; this connection only sees deliveries where Webhook is the notification method (requires the ALERT_REPORT_WEBHOOK feature flag upstream). Tools read what already landed; nothing here triggers a new alert or report send.

Upstream payload shape

Superset branches on attachments:

JSON only (application/json)

When the alert or report has no file attachments, Superset POSTs a single JSON object:

• name — alert or report title (often includes chart or dashboard name).
• header — notification metadata:
  • notification_format — export format intent: "JSON", "TEXT", or "PNG" (and similar); does not guarantee inline tabular data in the JSON body.
  • notification_type — "Alert" or "Report".
  • notification_source — upstream source label (for example "Alert", "chart", "dashboard").
  • chart_id — numeric chart id when the notification targets a chart; null when dashboard-scoped.
  • dashboard_id — numeric dashboard id when applicable; null for chart-only alerts.
• text — human-readable message; often populated for errors. On successful TEXT-format alerts it is frequently null — use name, description, and url instead.
• description — optional report or alert description configured upstream; may be null.
• url — deep link back to the chart, dashboard, or explore view in the sender's Superset instance (host-specific).

There is no Metabase-style raw_data block in the generic webhook JSON. Chart or table values are not serialized inline — they arrive only as CSV/XLSX attachments on multipart report deliveries (see below). For metadata-only JSON fires, summarize from name, header, description, and url.

Multipart with attachments (multipart/form-data)

When the report includes CSV, Excel, PDF, or PNG screenshots, Superset switches to multipart:

• Form fields name, text, description, url — plain strings (may be empty or null-ish text).
• Form field header — JSON-encoded string with the same keys as the JSON-only header object above.
• Repeated form field files — attachments such as report.csv, report.xlsx, report.pdf, or screenshot_0.png.

Storage may hold separate records per part (metadata text fields plus each file). Correlate by nearby source.captured_at timestamps. Prefer report.csv / report.xlsx for tabular KPIs via export.rows; PDF and PNG parts may only expose export.text or binary metadata.

First moves

1. Latest report — default for "what did the alert or report say".
2. Inspect export.json — when the stored part is JSON, read name, header.notification_type, header.chart_id, and url before quoting figures.
3. Check for CSV attachment — when the user asks for chart numbers, list recent deliveries and open the latest report.csv (or .xlsx) capture, not only metadata JSON.
4. Recent reports — compare repeated fires, metadata-only vs attachment deliveries, or multiple files from one upstream POST.
5. One report by id — after listing, when the user names a specific delivery or time.

Response shape

• export.json — parsed JSON when the stored part was JSON metadata (payload.json) or a JSON attachment.
• export.rows — parsed CSV preview when the stored part was report.csv or similar tabular export; may truncate with rows_truncated.
• export.text — full raw body when previews truncate, when form fields were stored as plain text (name, header, etc.), or when the file is not tabular.
• source.captured_at — when the POST was stored here (not the upstream schedule time).

Operational order

1. Start with the latest report — do not guess a report id.
2. If source.captured_at is older than expected, say so — alerts and reports run on Superset's configured schedule or SQL condition cadence.
3. List recent reports only for history, duplicate suspicion, or explicit compare-by-date asks.
4. Read ## This connection in the skill supplement for which dashboards, charts, or KPIs this ingest tracks.

Gotchas

• Read-only — cannot re-run the chart, acknowledge the alert, or change Superset alert/report settings from here.
• Thin JSON metadata — unlike Metabase alert webhooks, generic Superset webhook JSON does not include inline raw_data; expect links and labels unless a CSV/XLSX file was attached.
• text: null is normal — for successful TEXT-format alerts, build the summary from name and url.
• Multipart split — one upstream POST can produce several stored items; pair metadata fields with report.csv by capture time.
• Feature flag — webhook recipients are unavailable upstream until ALERT_REPORT_WEBHOOK is enabled; Slack/email deliveries never arrive on this connection.
• Each POST is one upstream fire — latest is the newest capture, not a merged history across charts.