Skip to content

Trip Confirmation Flow

The trip confirmation flow emails the member after confirm_trip. The tool automatically selects a template based on whether a trip_id or standing_order_id is supplied.

graph TD CT["confirm_trip"] --> C{trip_id or
standing_order_id?} C -->|trip_id| SGL["send_confirmation
single-trip HTML"] C -->|standing_order_id| STO["send_confirmation
standing-order HTML
+ schedule PDF
+ mileage form PDF"] style CT fill:#4299e1,color:#fff style SGL fill:#f6ad55,color:#fff style STO fill:#f6ad55,color:#fff
  1. verify_member
  2. confirm_trip — creates the real trip(s)
  3. (Optional) get_member_email — surface the on-file email for verbal confirmation
  4. (If missing) update_member_email — add/update the email before sending
  5. send_confirmation — email the member
  • trip_id set, no standing_order_id → single_trip mode. Sends an HTML email with pickup/dropoff, appointment time, transport mode, trip type (one way/roundtrip), and trip IDs.
  • standing_order_id set, no trip_id → standing_order mode. Sends an HTML schedule email plus two PDF attachments:
    1. Branded trip schedule PDF listing every leg
    2. Blank Aetna mileage reimbursement form (static bundled asset)

Both arguments in the same call is rejected with a validation error.

  1. Explicit email arg wins.
  2. Otherwise, the member’s primary email on file is used.
  3. Otherwise, the first email on file is used.
  4. If no email is available, the tool returns email address is required — no member email on file and the AI should call update_member_email.
  • Standing-order fetch failure is non-fatal — the email still goes out (with no trip rows listed, just the mileage form).
  • Trip schedule PDF generation failure is non-fatal — the email still goes out without the schedule attachment.
  • Mileage form asset missing is non-fatal — logged and skipped.
  • No PHI in email subjects: Trip Confirmation — <Display Name> / Standing Order Schedule — <Display Name>.
  • Audit metadata for mcp.send_confirmation:
    • mode (single_trip / standing_order)
    • email_hash — stable hash of the recipient (privacy-safe)
    • email_domain — domain portion only (e.g. example.com)
    • message_id — SendGrid response
    • attachment_count
  • Recipient email plaintext is never logged or written to audit metadata.
  • Error logs include session_id + email_hash only.

send_confirmation is DISABLED when SENDGRID_API_KEY is empty — it returns a configuration error instead of attempting a send. Deployments that lack the key can safely skip email without breaking booking flow.