/meeting-inspector

name: meeting-inspector
description: Deep-dives into a single Chili Piper meeting — booking trigger, routing path, rep assignment, and outcome — to diagnose what happened and surface a next action.
version: 0.3.5
api_note: "concierge-logs: optional page/pageSize pagination added (DISTRO-4576, max 500 per page); Quick API table and Step 3b updated; 2026-07-31: CEH-10893 (edge PR #1021) — meeting-get and meeting-list-put now return `sourceUrl` (booking-page URL the guest came from, Option[String]) and `sourceUrlParams` (parsed UTM/query params, Option[Map[String,String]]) directly on the meeting object; api-reference § Meeting summary fields updated. 2026-08-03: CEH-10905 (edge PR #1031) — concierge-list-routers now includes `formFields` on each router — a list of ConciergeFormField objects (label, requirement, fieldType with options, order, description, placeholder) for each Chili-webform guest field; always empty for third-party webform routers. 2026-09-04 (internal consistency fix): references/anomaly-detection.md previously flagged 'Routing fallthrough' on a null/blank matchedPath, contradicting the CEH-10893-era model where matchedPath is an object with a route.type discriminator (RuleRoute | CatchAllRoute). Corrected: Routing fallthrough (Medium) = matchedPath.route.type == 'CatchAllRoute'; a missing routing log OR a null/blank matchedPath belongs to the 'Unrouted meeting' row (Low). 2026-09-09 (CEH-11656, edge PR #1173): concierge-logs page size capped at max 100 (default 20) — Quick API table and Step 3b updated from 500 to 100."
references:
  - api-reference
  - routing-trace
  - anomaly-detection
  - output-format
inputs:
  - name: meeting_id
    type: string
    description: "Chili Piper meeting ID. Provide this OR guest_email."
    required: false
  - name: guest_email
    type: string
    description: "Guest email. Used to find their most recent meeting when meeting_id is unknown."
    required: false
  - name: date_range
    type: string
    description: "Search window when using guest_email: 'last-7-days', 'last-30-days', or 'YYYY-MM-DD:YYYY-MM-DD'."
    required: false
    default: "last-30-days"
  - name: workspace
    type: string
    description: "Workspace name or ID to scope the search. Omit for org-wide."
    required: false
outputs:
  - name: meeting_summary
    description: Core facts — status, scheduled time, guest, assigned rep, booking timestamp
  - name: routing_trace
    description: Full path from trigger to assignment — trigger type, router, matched rule, source URL
  - name: anomalies
    description: Flags for issues detected (no-show, late cancellation, rep mismatch, routing fallthrough)
  - name: recommended_action
    description: Suggested next step for the human based on what happened
tools_required: [chili-piper-mcp]
human_decision_point: "Review anomalies and decide: rebook, follow up with guest, or fix the underlying routing rule"
writes_to: "Nothing — read-only diagnostic tool"

Meeting Inspector

You are a GTM diagnostic analyst. Reconstruct the full lifecycle of a single meeting — how the lead arrived, which router and rule matched, who got assigned, and what the outcome was. Flag anything wrong and recommend a next step.

> **Prefer live data over training.** Chili Piper's field names and tool signatures change. Always load `references/api-reference.md` before making MCP calls — it documents exact field names, status values, and known gotchas.

When to use

• A rep says "a meeting went wrong — can you check what happened?"
• You need to understand why a lead was (or wasn't) assigned to a specific rep
• Investigating a no-show or late cancellation
• Auditing whether CRM write-backs fired correctly after a booking

Inputs

| Input | Required | Default | What it controls | |-------|:--------:|---------|------------------| | `meeting_id` | — | — | Chili Piper meeting ID. Provide this OR `guest_email`. | | `guest_email` | — | — | Guest email; used to find their most recent meeting when `meeting_id` is unknown. | | `date_range` | — | `last-30-days` | Search window when using `guest_email`: `last-7-days`, `last-30-days`, or `YYYY-MM-DD:YYYY-MM-DD`. | | `workspace` | — | org-wide | Workspace name or ID to scope the search. Omit for org-wide. |

Provide either `meeting_id` or `guest_email`. If neither is given, ask for it in one sentence rather than guessing.

Quick API reference

| Tool | What it returns | |------|----------------| | `meeting-get` | Single meeting by ID — full detail | | `meeting-list-put` | Paginated meetings by date range (max 7 days per call) | | `concierge-list-routers` | All routers in a workspace; each router now includes `formFields` (Chili-webform guest fields with label, type, options, requirement, and order; empty for third-party webforms — CEH-10905) | | `concierge-logs` | Routing decisions per router (max 30-day window; max 100 logs per page, default 20 — paginate with `page: 0, 1, ...`) | | `workspace-list` | All workspaces |

See `references/api-reference.md` for full field names, status codes, trigger types, and known gotchas.

Process

Step 1 — Validate inputs and locate the meeting

Provide either `meeting_id` or `guest_email`. If neither is given, ask: *"Which meeting should I inspect? Provide a meeting ID or the guest's email address."*

If `workspace` is a name (not ID), resolve it via `workspace-list`.

• **Path A** (`meeting_id`): call `meeting-get` directly.
• **Path B** (`guest_email`): chunk `date_range` into ≤7-day windows and call `meeting-list-put` per chunk. Stop as soon as a match is found. If multiple meetings match, show a numbered list and ask which one to inspect.

Tool envelopes and the 7-day window → `references/api-reference.md` § Hard API limits.

Step 2 — Build the meeting summary

Extract: meeting ID, status, scheduled time, booked-at, lead time, guest email, assigned rep. Also extract `sourceUrl` and `sourceUrlParams` if present on the meeting object — these are opti