Looker Webhook MCP Server

looker-webhook

Looker scheduled plans POST export deliveries when a Look or dashboard schedule fires upstream. Each capture reflects whichever Look, dashboard, format, filters, and cadence were configured — tabular columns are not fixed across schedules. Tools read what already landed; there is no pull API and no way to trigger a new send from here.

What upstream deliveries look like

Looker webhook destinations typically POST JSON (application/json) with export bytes embedded in the body:

• Text formats (CSV, TXT, HTML, JSON) — file content lives as a plain string under attachment.data. CSV is the usual choice for tabular KPI questions; headers appear in the first line of that string.
• Binary formats (PDF, XLSX, PNG) — the same attachment.data key holds base64-encoded bytes; attachment.mimetype often ends with ;base64 and attachment.extension names the file type. PDF and PNG are common for dashboard schedules; XLSX for Looks.
• Inline JSON — when the upstream format is inline JSON, the envelope differs slightly: row data may be JSON-escaped inside attachment.data with extra properties describing the query operation rather than a traditional file attachment.
• Dashboard CSV zip — dashboard schedules can deliver a zip of multiple tile CSVs; when the zip arrives as base64 in attachment.data, storage may unpack the first CSV inside for tabular preview when bytes are available.
• Schedule metadata — sibling object scheduled_plan carries the Look or dashboard title, a link back to the content in Looker, scheduled_plan_id, and type (look vs dashboard). Use it to disambiguate when one connection receives several schedules.

Less common but supported by ingest wiring: multipart file uploads or a compact link JSON wrapper when an integration posts a download URL instead of inline bytes.

First moves

1. Latest report — default for "what did the scheduled Look say" or dashboard export questions.
2. Report freshness — check source.captured_at and source.filename before quoting figures; compare to scheduled_plan.title in export.json when present.
3. Recent reports — compare runs, spot duplicate filenames, or find a delivery from a specific schedule date.
4. One report by id — after listing, when the user names a particular run or schedule.

Response shape

• source — capture time, filename, format, connection purpose.
• export.json — parsed webhook body when stored as JSON; inspect scheduled_plan for schedule name and Look vs dashboard type, and attachment for format hints (extension, mimetype).
• export.rows — parsed CSV preview when storage holds raw or unpacked CSV bytes; may truncate with rows_truncated. When the upstream only embedded CSV text inside export.json.attachment.data, read that string directly — rows may not be pre-parsed.
• export.text — full raw body when rows truncate, the delivery is non-tabular, or you need the complete CSV string from a JSON envelope.

For PDF, PNG, and XLSX deliveries, expect limited tabular preview — prefer export.text, note binary or base64 content, or summarize from scheduled_plan.title when the user asked about a visual export.

Operational order

1. Start with the latest report — do not guess a report id.
2. If captured_at is older than expected, say so — Looker sends on the schedule cadence configured upstream (minute, hour, day, week, month, or custom).
3. List recent reports only for history, duplicate suspicion, or explicit compare-by-date asks.
4. Read ## This connection in the skill supplement for Look- or dashboard-specific column notes.

Gotchas

• Read-only — cannot run "Send Now", edit a scheduled plan, or change Looker delivery settings from here.
• Variable columns — do not assume fixed KPI names; read CSV headers from export.rows, export.text, or export.json.attachment.data depending on how the capture landed.
• JSON envelope vs file — many Looker webhooks store one JSON object (payload.json) rather than a standalone .csv file; tabular data may require reading attachment.data inside export.json.
• Base64 binary — PDF, XLSX, and PNG attachment.data values are encoded; decoding happens at read time in chat, not as pre-built export.rows.
• Dashboard zip vs single Look CSV — dashboard schedules may bundle several tile CSVs; filename and preview reflect what was unpacked first when a zip was present.
• Inline JSON shape — row layout differs from CSV; inspect export.json keys before quoting metric names.
• Filters and timezone — upstream schedules can apply Look filters and query timezones; two deliveries with the same scheduled_plan.title may differ if filters changed upstream.
• Each delivery is one report — latest is the newest capture, not a merged history across schedules.