Skip to content
NEMT MCP Service

send_confirmation

Status: Implemented | Module: notification

Send a trip confirmation email. Automatically picks the right format: single trip or roundtrip → clean HTML confirmation email; standing order → full schedule email with two PDF attachments (branded trip schedule + blank Aetna mileage reimbursement form). Call AFTER confirm_trip. Ask the member ‘Would you like me to send a confirmation email?’ before calling.

Session-Scoped Authorization (PHI guard)

Section titled “Session-Scoped Authorization (PHI guard)”

send_confirmation is restricted to the trip captured by the session’s LastConfirmedDraft snapshot — set by confirm_trip on success. The use case verifies that the supplied trip_id (or standing_order_id) is in the session’s LastTripIDs / LastFriendlyIDs / StandingOrderID allowlist before dispatching. This prevents a cross-session PHI leak where one verified session could be tricked into emailing the booking details of another member’s trip.

If the session has no LastConfirmedDraft (e.g. confirm_trip was never called or failed), the tool returns an authorization error. Re-run confirm_trip to populate the snapshot.

Annotations

Section titled “Annotations”
Hint Value
readOnlyHint false
destructiveHint false
idempotentHint false
openWorldHint true

Input

Section titled “Input”
Field Type Required Description
session_id string yes Active session ID from verify_member
trip_id string cond Trip UUID or friendly_id. Required unless standing_order_id is provided.
standing_order_id string cond Standing order UUID or friendly ID. Use instead of trip_id for recurring-order confirmations.
email string no Recipient email. If omitted, the tool uses the primary email on file (or the first available email) for the member.

Exactly one of trip_id or standing_order_id must be supplied; both is rejected.

Output

Section titled “Output”
Field Type Description
status string sent on success, error otherwise
mode string single_trip or standing_order
message_id string Provider message ID returned by SendGrid
trip_count int Number of trips included in the email
message string Human summary (uses email domain only, not full address)
guidance Guidance Suggests end_conversation

Behavior

Section titled “Behavior”
  • Mode selection: standing_order_id set → standing order mode; otherwise single trip.
  • Recipient: explicit email arg wins; otherwise primary email, otherwise first email on file. Returns a descriptive error if no email is available.
  • Templates: HTML rendered via the template renderer (single-trip template or standing-order template).
  • Attachments (standing order only):
    • Trip schedule PDF — generated from the fetched legs. Generation failure is non-fatal (email still sends without this attachment).
    • Aetna mileage reimbursement form — a bundled static PDF, always appended when available. Missing asset is non-fatal (logged).
  • Standing-order fetch failure is non-fatal — the email still goes out, potentially with no trip legs (just the mileage form).

Compliance (HIPAA-03)

Section titled “Compliance (HIPAA-03)”
  • No PHI in the email subject. Subjects are of the form Trip Confirmation — <Display Name> or Standing Order Schedule — <Display Name>.
  • Audit entry mcp.send_confirmation metadata carries:
    • mode (single_trip or standing_order)
    • email_hash — stable hash of the recipient (see EmailHash in internal/app/notification/domain/privacy.go)
    • email_domain — domain portion only (e.g. example.com)
    • message_id — provider response
    • attachment_count
  • The recipient email plaintext is NEVER logged or written to audit metadata.
  • Error logs capture session_id + email_hash only.
  • send_confirmation is DISABLED (returns a configuration error) when SENDGRID_API_KEY is empty — no emails are attempted.

Integrations

Section titled “Integrations”
  • Email provider: SendGrid v3 (see internal/pkg/integrations/email/).
  • PDF generation: go-pdf/fpdf (see internal/pkg/integrations/pdf/).

Side Effects

Section titled “Side Effects”
  • Calls SendGrid (external HTTP).
  • Emits a HIPAA audit entry on allow or deny.
  • No database writes (email is sent side-effect-only; the audit row is the only persistent record).
Section titled “Related”