Metabase Webhook MCP Server

Metabase Webhook

Each stored delivery is one Metabase alert webhook POST — JSON only, fired when a saved question's alert condition is met (or when someone sends a test). Dashboard subscriptions do not use this payload shape. Tools read what already landed; nothing here triggers a new alert send.

Stored payload shape (export.json)

Top level:

• type — always "alert" for these deliveries.
• alert_id — numeric alert id; null on test sends (do not treat null as a production alert).
• alert_creator_id / alert_creator_name — who configured the alert.
• sent_at — ISO timestamp when Metabase sent the webhook (upstream event time; compare to source.captured_at for ingest delay).
• data — question results and metadata:
  • type — "question".
  • question_id, question_name — which saved question fired; use to disambiguate when one connection receives multiple alerts.
  • question_url — link to the question in the sender's Metabase instance (instance-specific; do not assume a fixed host).
  • raw_data — tabular results as Metabase's table view:
    • cols — column name strings.
    • rows — array of row arrays; index i in each row aligns with cols[i].
  • visualization — chart as a data:image/png;base64,... data URI; often very large. Prefer raw_data for numbers and trends unless the user explicitly wants the chart image.

Column names and row values reflect the underlying question — they are not a fixed schema across alerts.

First moves

1. Latest report — default for "what did the alert say" or "did anything fire".
2. Inspect export.json — read data.question_name, sent_at, and data.raw_data before quoting figures.
3. Recent reports — list when comparing repeated fires, test vs live (alert_id null vs set), or multiple questions on one connection.
4. One report by id — after listing, when the user names a specific delivery or time.

Response shape

• export.json — parsed alert object (structure above).
• export.text — full raw JSON when previews truncate or the body is oversized.
• source.captured_at — when the POST was stored here (not the same as sent_at).

Operational order

1. Start with the latest report — do not guess a report id.
2. If sent_at or source.captured_at is older than expected, say so — alerts run on Metabase's schedule (minute, hourly, daily, etc.).
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 questions or KPIs this ingest tracks.

Gotchas

• Read-only — cannot re-run the question, acknowledge the alert, or change Metabase alert settings from here.
• Test vs live — alert_id: null usually means a test payload; confirm before treating numbers as production signal.
• Huge visualization — base64 PNG can dominate payload size; summarize from raw_data unless the user needs the image.
• Alerts only — if the user expects dashboard subscription exports, those are a different Metabase feature and may never arrive on this connection.
• Each POST is one report — latest is the newest capture, not a merged history across alerts.