Skip to content

verify_member

Status: Verified | Module: verify

Verify a member’s identity via 2-of-5 token matching (member_id, name, dob, phone, ssn_last_four); at least 2 tokens must match. On success, creates a booking session and returns member name, home address with coordinates, mobility/vehicle/eligibility, plus single-value typical_* hints derived from member history. The org’s full per-LOB treatment-type and service-type catalogues live SERVER-SIDE in the reference-data cache (1h TTL) — set_booking_details validates / fuzzy-matches the chosen value against them.

For saved/recent addresses or the full trip history, call get_member_addresses or get_member_profile instead — those payloads were removed from verify_member in the v2.0 audit (~85-92% smaller per call).

Hint Value
readOnlyHint false
destructiveHint false
idempotentHint false
Field Type Required Description
member_id string yes Medicaid ID (member_friendly_id) or member UUID
name string no Full name (“First Last” or “Last, First”)
dob string no Date of birth (MM/DD/YYYY, YYYY-MM-DD, DD.MM.YYYY)
phone string no Phone number (any format)
ssn_last_four string no Last 4 digits of SSN
channel string no voice_call, chat, sms, or web. Defaults to web.
Field Type Description
status string verified or failed
session_id string UUID of created session (1h TTL)
member_id string Member UUID
member_name string “First Last”
home_address object Structured home address: {address, latitude, longitude}
mobility_type string Member’s mobility type (e.g. ambulatory, wheelchair)
vehicle_type string Required vehicle type
eligibility string Eligibility status
mr_enrolled bool Whether member is enrolled in Mileage Reimbursement
typical_service_type string Member’s most-used service/vehicle code from history (e.g. "amb", "wc"). Surfaced only when derivable. The agent can offer it as the default transport_mode for set_booking_details.
typical_treatment_type string Member’s most-used treatment-type name from history (e.g. "Dialysis"). Surfaced only when derivable. Server-side fuzzy matcher in set_booking_details accepts close variants.
guidance Guidance Next-step instructions (short — long workflow guidance now lives in the tool description)

v2.0 audit changes: recent_addresses, tokens_matched, and booking_progress were removed from the response (P2-1). Per AUDIT-4 the treatment_types and service_types arrays were also dropped — the per-LOB catalogues (1–3 KB each) are now kept server-side and consulted by set_booking_details. Only single-value typical_* hints derived from member history are surfaced. The guidance.context_hint was trimmed (the prompt-engineering payload moved onto the tool description, where it is delivered ONCE per session via the MCP tools/list schema rather than on every call).

Note: The response is flat — no dossier or manifest nesting. DOB verification uses actual date comparison and requires a minimum of 2 matched tokens.

After verify_member, the canonical next step is resolve_address for BOTH pickup and dropoff before set_booking_details — never skip address validation. If the member confirms pickup from home, pass home_address.address as pickup_address and home_address.latitude/longitude as pickup_lat/pickup_lon (no resolve_address needed for the home leg).

{
"jsonrpc": "2.0", "id": 1, "method": "tools/call",
"params": {
"name": "verify_member",
"arguments": {
"member_id": "MED-12345",
"name": "John Doe",
"dob": "1990-01-15",
"channel": "voice_call"
}
}
}
{
"status": "verified",
"session_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"member_id": "m-uuid-001",
"member_name": "John Doe",
"home_address": {
"address": "123 Main St, Springfield, IL 62701",
"latitude": 39.7817,
"longitude": -89.6501
},
"mobility_type": "ambulatory",
"typical_service_type": "amb",
"typical_treatment_type": "Dialysis"
}
  • VERIFICATION_FAILED — Member not found or name/DOB mismatch