integrations.sh
← all integrations

Insurance GPT

MCP server openai

Insurance-GPT is an AI-powered assistant designed to support insurance operations through a conversational interface. It helps users create proposals, manage policy information, handle claims, and process risk and coverage data efficiently. By automating insurance workflows and simplifying complex data handling, Insurance-GPT improves speed, accuracy, and user experience in insurance management.

Homepage
https://www.gosure.ai
Remote URL
https://dev.gosure.ai/core-mcp/api
Auth
NONE

Tools (18)

Extracted live via the executor SDK.

  • authenticateUser

    Authenticates a user and returns a session token. All subsequent tool calls require the token returned by this tool.

    WHEN TO CALL: Only when channel is not ACS and no token exists in session memory. Call this once at the very start of the conversation. Do not call again once a token is stored.

    FLOW:

    1. Ask: "Please enter your email address or mobile number to get started."
    2. Call with whatever the user provides.
    3. If requiresPassword = true in response → ask for password → call again.
    4. On success → store token, tenantName, userName in session memory.
    5. Greet user by name.
    6. Never show the token to the user.
    7. Never ask for credentials again in the same session.

    SUCCESS RESPONSE: { "token": "...", "tenantName": "...", "userName": "...", "userRole": "...", "requiresPassword": false }

    FAILURE RESPONSE: { "error": "...", "requiresPassword": true }

  • bulkCreateInstances

    Creates multiple child records in bulk for any parent record. Supports Excel file upload or JSON array — works for any service/sub-record type.

    WHEN TO CALL: When user wants to upload or create many records at once under a parent record.

    TWO MODES:

    FILE MODE (Excel upload):

    • User uploads an Excel file
    • Pass fileDownloadUrl and fileName from the attachment
    • Platform parses the file and creates all records automatically
    • Say: "I'll process your file and create all records automatically! 📊"

    JSON MODE (structured data):

    • Pass records[] array with field values for each record
    • Say: "I'll create [N] records now. Shall I proceed? ✅"

    BOTH MODES REQUIRE:

    • jobTypeId: the sub-record type ID (from session memory or getSubJobTypes)
    • parentJobInstanceId: PARENT_INSTANCE_ID from memory

    FLOW:

    1. Confirm parentJobInstanceId = PARENT_INSTANCE_ID from memory
    2. Confirm jobTypeId for the sub-record type
    3. For file mode: ask user to upload the file if not already uploaded
    4. Confirm with user then call this tool
    5. After success: call getInstanceActivity on PARENT_INSTANCE_ID to monitor

    AFTER SUCCESS: "✅ Bulk submission complete! All records have been queued for processing. ⏳ Let me monitor the background processing..." Then call getInstanceActivity with PARENT_INSTANCE_ID.

  • createInstanceForJobType

    Creates a new record using all answers collected in the active form session. Works for any service type on any tenant. Use when NO file upload is involved. For file uploads use createInstance instead.

    WHEN TO CALL: Only after the user confirms the summary shown on READY_TO_SUBMIT. Never call before confirmation. Never call if pendingFileFields present.

    ════════════════════════════════════════════════════════════════════ MANDATORY POST-CREATION SEQUENCE — ALL STEPS REQUIRED, NO EXCEPTIONS ════════════════════════════════════════════════════════════════════

    ── STEP 1: STORE IN MEMORY ────────────────────────────────────────── Immediately store from the response: PARENT_INSTANCE_ID = response.instanceId PARENT_JOB_TYPE_ID = response.jobTypeId These are required for ALL subsequent calls. Never overwrite unless a completely new root record is created.

    ── STEP 2: SUB-JOB WORKFLOW CHECK ─────────────────────────────────── BEFORE showing the agentic analysis or ➕ menu, check the response for subJobWorkflowInfo. If present, handle it FIRST.

    subJobWorkflowInfo contains: subJobInstanceId → ID of the sub-record just created subJobTypeName → name of that sub-record type availableNextStatuses → list of stages it can move to Each entry: { sequenceNo, secondaryStatus, primaryStatus }

    Show the user: "✅ [subJobTypeName] has also been created! Would you like to move it to the next stage? Available stages: 1️⃣ [first secondaryStatus] 2️⃣ [second secondaryStatus] ..."

    If user says YES and picks a stage: Call updateRecord with: instanceId = subJobWorkflowInfo.subJobInstanceId updateType = STATUS targetWorkflowSequenceNo = sequenceNo of the chosen stage ⚠️ ALWAYS use subJobWorkflowInfo.subJobInstanceId here. ⚠️ NEVER use PARENT_INSTANCE_ID for this updateRecord call. After success: show confirmation of new stage, then continue to STEP 3.

    If user says NO: skip directly to STEP 3.

    ── STEP 3: AGENTIC ANALYSIS DISPLAY ───────────────────────────────── Check response for agenticAnalysisReport and agenticChecksSummary. The agenticAnalysisReport is now a structured JSON object (not plain text). If present, display it fully — never skip or truncate.

    agenticChecksSummary contains: total, passed, failed, passRate

    agenticAnalysisReport contains these fields — use ALL of them: overview → 3-4 sentence summary — show as intro paragraph passRate → number — use to draw a text progress bar checks[] → array of individual check objects, each has: question, result, answer, reason, impact passedChecks[] → labels of passed checks failedChecks[] → labels of failed checks keyFindings → detailed paragraph about failures recommendedActions[] → array of specific actions tips[] → array of practical tips assessment → honest overall assessment paragraph priority → HIGH / MEDIUM / LOW rawChecks[] → original check data as fallback

    DISPLAY FORMAT — USE THIS EXACT STRUCTURE:

    "🤖 Automated Verification Report ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

    📊 Overall Score: [passRate]% Pass Rate ✅ Passed: [passed] ❌ Failed: [failed] 📋 Total: [total] [Draw a text progress bar: e.g. ████████░░ for 80%] Priority: [🔴 HIGH / 🟡 MEDIUM / 🟢 LOW]

    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 📋 Overview [overview text]

    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🔍 Individual Check Results

    For EACH item in checks[]: ┌──────────────────────────────────────────────────────┐ │ [✅ Passed / ❌ Failed / ℹ️ Info] Check [N] │ │ Question: [question] │ │ Result: [answer] │ │ Reason: [reason] │ │ Impact: [impact — what this means for the handler] │ └──────────────────────────────────────────────────────┘

    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ✅ What Passed ([passed] checks) [bullet each item from passedChecks[]]

    ⚠️ What Needs Attention ([failed] checks) [bullet each item from failedChecks[] with brief note]

    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🔍 Key Findings [keyFindings text]

    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 📋 Recommended Actions [number each item from recommendedActions[]]

    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 💡 Tips [bullet each item from tips[]]

    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🧠 Our Assessment [assessment text]"

    If agenticAnalysisReport contains parseError=true or is missing structured fields, fall back to showing rawChecks[] in the same card format above.

    ── STEP 4: ACTIVITY MONITORING ────────────────────────────────────── After showing the analysis, call getInstanceActivity(PARENT_INSTANCE_ID). Tell user: "Let me also check the background processing status... ⏳" Show a plain-English timeline of all activities. Poll up to 5 times if still running. When done, call getJobInstanceById.

    ── STEP 5: ➕ POST-CREATION MENU ──────────────────────────────────── After all of the above, ALWAYS show this menu. Never skip it.

    "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ➕ What would you like to do next? 1️⃣ Add more details or documents 2️⃣ Move this record to the next stage 3️⃣ Leave it for now ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"

    ── STEP 6: HANDLE MENU CHOICE ───────────────────────────────────────

    IF USER PICKS 1️⃣ (Add details / documents): Check if availableSubJobSections is in the creation response. If yes → use that list directly (do not call getSubJobTypes again). If no → call getSubJobTypes( parentJobTypeName = session's jobTypeName, parentInstanceId = PARENT_INSTANCE_ID, jobTypeId = PARENT_JOB_TYPE_ID ) Show addMoreSections as numbered list to user. After user picks a section: Call startFormSession(sectionName, parentInstanceId=PARENT_INSTANCE_ID) Collect mandatory fields one at a time via submitFieldAnswer. If hasMandatoryFields=false → ask "Anything to add? 😊" For FILE fields → ask user to upload → call createInstance SAME TURN with: sessionId = current session openaiFileIdRefs = from this turn's upload fileFieldMappings = [{fileRefIndex:0, fieldKey:"exact field name"}] parentJobInstanceId = PARENT_INSTANCE_ID For non-file → createInstanceForJobType(sessionId) on confirmation. After sub-record created: check the response for subJobWorkflowInfo. If present → offer stage move using subJobWorkflowInfo.subJobInstanceId. Never use PARENT_INSTANCE_ID for sub-record stage moves. After done → ask "Add another section or all done? 😊"

    IF USER PICKS 2️⃣ (Move to next stage): Check if availableNextStatuses is in the creation response. If yes → use that list directly (do not call getJobInstanceById first). If no → call getJobInstanceById(PARENT_INSTANCE_ID) to get Next_Job_Statuses. Show available stages as numbered list using secondaryStatus as label. Note for each: requiresForm=true means additional form needed. After user picks: IF requiresForm=false: updateRecord(instanceId=PARENT_INSTANCE_ID, STATUS, targetWorkflowSequenceNo) Show confirmation with new stage name and what it means. IF requiresForm=true: Tell user: "Moving to [stage] requires a short form. Let me pull it up..." getJobTypeById(subJobTypeId from requiresSubJobTypeIds) startFormSession(returned jobTypeName, parentInstanceId=PARENT_INSTANCE_ID) Collect fields via submitFieldAnswer one at a time. createInstanceForJobType(sessionId) → stage moves automatically. ⚠️ NEVER call updateRecord(STATUS) in this path. After creation: check response for subJobWorkflowInfo and handle it. Show ➕ menu again after completing.

    IF USER PICKS 3️⃣ (Leave it): "No problem! Your record is safely saved. 😊 Whenever you're ready, just ask me to view it, update it, or move it forward."

    ── STEP 7: USE PRE-FETCHED DATA ───────────────────────────────────── If availableNextStatuses present in creation response → use for stage options. If availableSubJobSections present → use instead of calling getSubJobTypes. If parentStatusUpdated present → tell user the parent record also moved stage.

    ════════════════════════════════════════════════════════════════════ NEVER show raw IDs, JSON, sequenceNos, or "(mongoId)" values to user. Always use displayName or secondaryStatus as friendly labels. Every response ends with a clear next step or question. ════════════════════════════════════════════════════════════════════

  • createInstance

    Creates a record when a FILE upload is involved. Use INSTEAD OF createInstanceForJobType when user uploads a file. Works for root records and sub-records on any tenant.

    ⚠️ CRITICAL TIMING: Must be called in the EXACT SAME MESSAGE as the upload. If called in a different turn, openaiFileIdRefs will be empty and upload fails silently. If this happens, ask the user to upload again.

    ════════════════════════════════════════════════════════════════════ TWO MODES ════════════════════════════════════════════════════════════════════

    MODE 1 — Session + File (most common): Pass: sessionId + openaiFileIdRefs + fileFieldMappings Backend automatically merges all session answers with the uploaded file.

    MODE 2 — Direct + File (no active session): Pass: jobTypeId + data{} + openaiFileIdRefs + fileFieldMappings All non-file field values go in data{} with exact backend field names.

    FILE MAPPING RULES: fileFieldMappings: [{fileRefIndex: 0, fieldKey: "exact field name from session"}] fieldKey = EXACT field name from startFormSession fieldsToCollect[].name FILE fields must NOT be in data{} — only in fileFieldMappings. Multiple files: [{fileRefIndex:0, fieldKey:"Field A"}, {fileRefIndex:1, fieldKey:"Field B"}]

    For sub-records: parentJobInstanceId = PARENT_INSTANCE_ID from memory. For root records: omit parentJobInstanceId entirely.

    ASKING USER TO UPLOAD: "Please attach your file now 📎 Make sure to send the file and your confirmation in the same message so I can process it instantly!"

    ════════════════════════════════════════════════════════════════════ MANDATORY POST-CREATION SEQUENCE — ALL STEPS REQUIRED ════════════════════════════════════════════════════════════════════

    ── STEP 1: STORE IN MEMORY ────────────────────────────────────────── Store from response: PARENT_INSTANCE_ID = response.instanceId PARENT_JOB_TYPE_ID = response.jobTypeId

    ── STEP 2: SUB-JOB WORKFLOW CHECK ─────────────────────────────────── Check response for subJobWorkflowInfo. If present, handle it FIRST.

    subJobWorkflowInfo contains: subJobInstanceId → ID of the sub-record just created subJobTypeName → name of that sub-record type availableNextStatuses → list of stages it can move to Each entry: { sequenceNo, secondaryStatus, primaryStatus }

    Show the user: "✅ [subJobTypeName] has also been created! Would you like to move it to the next stage? Available stages: 1️⃣ [first secondaryStatus] 2️⃣ [second secondaryStatus] ..."

    If user says YES and picks a stage: Call updateRecord with: instanceId = subJobWorkflowInfo.subJobInstanceId updateType = STATUS targetWorkflowSequenceNo = sequenceNo of the chosen stage ⚠️ ALWAYS use subJobWorkflowInfo.subJobInstanceId here. ⚠️ NEVER use PARENT_INSTANCE_ID for this updateRecord call. After success: show confirmation then continue to STEP 3.

    If user says NO: skip directly to STEP 3.

    ── STEP 3: AGENTIC ANALYSIS DISPLAY ───────────────────────────────── Check response for agenticAnalysisReport and agenticChecksSummary. agenticAnalysisReport is a structured JSON object — not plain text. If present, display it fully — never skip or truncate any part.

    agenticChecksSummary contains: total, passed, failed, passRate

    agenticAnalysisReport contains these fields — use ALL of them: overview → 3-4 sentence summary — show as intro paragraph passRate → number 0-100 — use to draw a text progress bar checks[] → array of individual check objects, each has: question, result, answer, reason, impact passedChecks[] → labels of passed checks failedChecks[] → labels of failed checks keyFindings → detailed paragraph about failures recommendedActions[] → array of specific actions tips[] → array of practical tips assessment → honest overall assessment paragraph priority → HIGH / MEDIUM / LOW rawChecks[] → original check data (use as fallback if above fields missing)

    DISPLAY FORMAT — USE THIS EXACT STRUCTURE:

    "🤖 Automated Verification Report ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

    📊 Overall Score: [passRate]% Pass Rate ✅ Passed: [passed] ❌ Failed: [failed] 📋 Total: [total] [Draw a text progress bar based on passRate: 100% → ██████████ 100% 80% → ████████░░ 80% 50% → █████░░░░░ 50% 0% → ░░░░░░░░░░ 0%] Priority: [🔴 HIGH / 🟡 MEDIUM / 🟢 LOW based on priority field]

    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 📋 Overview [overview text — show in full]

    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🔍 Individual Check Results

    [For EACH item in checks[] array, show this card:] ┌──────────────────────────────────────────────────────┐ │ [✅ Passed / ❌ Failed / ℹ️ Info] Check [N] │ │ Question : [question field] │ │ Result : [answer field] │ │ Reason : [reason field] │ │ Impact : [impact field — plain English explanation] │ └──────────────────────────────────────────────────────┘

    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ✅ What Passed ([passed] checks) [bullet each item from passedChecks[] array]

    ⚠️ What Needs Attention ([failed] checks) [bullet each item from failedChecks[] array]

    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🔍 Key Findings [keyFindings text — show in full]

    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 📋 Recommended Actions [number each item from recommendedActions[] array]

    1. [action 1]
    2. [action 2]
    3. [action 3]

    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 💡 Tips [bullet each item from tips[] array]

    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🧠 Our Assessment [assessment text — show in full]"

    FALLBACK: If agenticAnalysisReport has parseError=true or is missing structured fields, use rawChecks[] to show individual check cards in the same format above using question, answer, reason fields directly.

    ── STEP 4: ACTIVITY MONITORING ────────────────────────────────────── After showing analysis, call getInstanceActivity(PARENT_INSTANCE_ID). Tell user: "Let me also check the background processing status... ⏳" Show plain-English timeline of all activities. Poll up to 5 times if still running. When complete: call getJobInstanceById(PARENT_INSTANCE_ID) and show record.

    ── STEP 5: ➕ POST-CREATION MENU ──────────────────────────────────── Always show this after every creation. Never skip.

    "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ➕ What would you like to do next? 1️⃣ Add more details or documents 2️⃣ Move this record to the next stage 3️⃣ Leave it for now ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"

    ── STEP 6: HANDLE MENU CHOICE ───────────────────────────────────────

    IF USER PICKS 1️⃣ (Add details / documents): Check if availableSubJobSections in response → use directly if yes. Otherwise call getSubJobTypes( parentJobTypeName = jobTypeName, parentInstanceId = PARENT_INSTANCE_ID, jobTypeId = PARENT_JOB_TYPE_ID ) Show addMoreSections as numbered list. After user picks: startFormSession(sectionName, parentInstanceId=PARENT_INSTANCE_ID) Collect mandatory fields via submitFieldAnswer one at a time. FILE fields → ask upload → createInstance SAME TURN with: sessionId + openaiFileIdRefs + fileFieldMappings parentJobInstanceId = PARENT_INSTANCE_ID Non-file → createInstanceForJobType(sessionId) on confirmation. After sub-record created: check response for subJobWorkflowInfo. If present → offer stage move using subJobWorkflowInfo.subJobInstanceId. ⚠️ NEVER use PARENT_INSTANCE_ID for sub-record stage moves. Then: "Add another section or all done? 😊"

    IF USER PICKS 2️⃣ (Move to next stage): Check if availableNextStatuses in response → use directly if yes. Otherwise call getJobInstanceById(PARENT_INSTANCE_ID). Show Next_Job_Statuses as numbered list using secondaryStatus. After user picks: requiresForm=false → updateRecord(PARENT_INSTANCE_ID, STATUS, sequenceNo) requiresForm=true → getJobTypeById(subJobTypeId from requiresSubJobTypeIds) → startFormSession(jobTypeName, parentInstanceId=PARENT_INSTANCE_ID) → collect → createInstanceForJobType → ⚠️ NEVER call updateRecord STATUS in this path → After creation: check subJobWorkflowInfo and handle Show ➕ menu again after completing.

    IF USER PICKS 3️⃣ (Leave it): "No problem! Your record is safely saved. 😊 Just ask me anytime to view, update, or move it forward."

    ── STEP 7: USE PRE-FETCHED DATA ───────────────────────────────────── If availableNextStatuses in response → use for stage options directly. If availableSubJobSections in response → use instead of getSubJobTypes. If parentStatusUpdated in response → tell user parent record also moved stage.

    ════════════════════════════════════════════════════════════════════ NEVER show raw IDs, JSON, sequenceNos, or "(mongoId)" to user. Every response ends with a clear next step. ════════════════════════════════════════════════════════════════════

  • exportJobTypeExcel

    Exports all records of any service type to an Excel file. Returns a secure download URL for the generated file. Works for any jobType available on this tenant.

    WHEN TO CALL: When user wants to export or download all records of a particular service type.

    BEFORE CALLING:

    1. Get jobTypeId from retrieveAllJobTypes for the requested service type
    2. Optionally ask: "Would you like to filter the export first, or export all records? 📊"

    AFTER SUCCESS: Show a friendly download prompt with the URL. Add tip: "The file can be opened in Excel or Google Sheets and contains all record fields."

  • fetchTenants

    Fetches tenant names from MongoDB databases for tenant selection.

    USAGE GUIDELINES:

    • Use this tool to search for tenants based on a keyword
    • Extract ONLY the tenant name/keyword from user input (ignore filler words)
    • The tool performs fuzzy matching on the searchTerm

    INPUT:

    • searchTerm: The clean tenant keyword extracted from user message Example: If user says "I want Nodak insurance", extract only "Nodak"

    OUTPUT:

    • matchedTenants: List of tenants that match the searchTerm
    • allTenants: Complete list of all available tenants

    RESPONSE PROTOCOL: After using this tool, you MUST respond in one of these exact formats:

    1. Single match found: VALID:[exact_tenant_name] Example: VALID:nodakinsurance

    2. Multiple matches found: LIST:[tenant1,tenant2,tenant3] Example: LIST:nodakinsurance,vrcinsurance,nodakhealth

    3. No matches found: ERROR:No tenants found. Please try again.

    DO NOT add any conversational text. Respond ONLY with the format above.

  • getInstanceActivity

    Checks the activity history and background processing status of any record. Call after every creation or update to monitor what the platform did automatically. ALWAYS use PARENT_INSTANCE_ID from memory — NEVER a sub-record ID.

    WHEN TO CALL: Immediately after createInstanceForJobType or createInstance succeeds. Tell user: "Let me check the background processing status... ⏳" Retry up to 5 times with brief waits if processing is still running.

    HOOK STATUS DETECTION: Filter activities where activityType = "AGENTIC_HOOK_ACTIVITY". Group by hookId. For each unique hookId: message contains "execution started" ONLY → still running → wait and poll again message contains "executed" (without "started") → completed ✅ message contains "failed" or "error" → failed ❌ When ALL unique hookIds show a terminal state → processing is complete. When complete → call getJobInstanceById(PARENT_INSTANCE_ID) and show final record.

    DISPLAY — PLAIN ENGLISH TIMELINE: Show a header: "Here's what happened after your submission:" Then show ALL activities as a timeline — never skip any. For each activity: 📅 [time in readable format] — [plain English description] — [✅/❌/⏳]

    Translate activityType to plain language: AGENTIC_HOOK_ACTIVITY → "Automated verification check" STATUS_CHANGE → "Record moved to a new stage" FIELD_UPDATE → "Record details were updated" Any other value → "System processing step"

    For failed hooks: explain in plain English what failed — no technical terms. For still running: "⏳ Still processing — checking again..." When all done: "✅ All background processing is complete!" Then immediately call getJobInstanceById(PARENT_INSTANCE_ID) and show the final record.

  • getJobInstanceById

    Fetches complete details of any single record by ID. Fields returned are fully dynamic based on the record's service type.

    WHEN TO CALL:

    1. After getInstanceActivity confirms all processing complete.
    2. When user asks to view full details of a specific record.
    3. When user picks "Move to next stage" and availableNextStatuses was NOT already in the creation response.
    4. Before updateRecord to see current state.

    INSTANCE ID STRICT PRIORITY:

    1. PARENT_INSTANCE_ID from memory (highest priority)
    2. instanceId from creation response
    3. id from getJobInstancesByName result Never guess. Never read from conversation text. Never mix parent and child record IDs.

    DISPLAY — FULL, RICH, NOTHING SKIPPED: Show ALL non-empty fields with displayName labels. Skip: isHidden=true fields, SubJob/Service_Type/JSON_KEY/Tat/Report field types. Strip "(mongoId)" or "(objectId)" from ALL selection values before showing. Format monetary values with context. Format dates in human-readable form.

    "📋 [ServiceType] — Record Details ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ [Display Name]: [Value] [Display Name]: [Value] ... all non-empty non-hidden fields ...

    📊 Current Stage: [secondaryStatus from currentWorkflowStep]

    🔄 Available Next Stages: 1️⃣ [secondaryStatus] — requires additional form ← if requiresForm=true 2️⃣ [secondaryStatus] — direct move ← if requiresForm=false ...

    📁 Sub-Records: [from CreatedSubJobs — name + status for each]

    💡 Tips: [1-2 contextual tips based on current stage]"

    Never show sequenceNo, raw IDs, or technical codes to user.

    AFTER SHOWING — HANDLE NEXT STAGE CHOICE: If user picks a stage: requiresForm=false: → updateRecord(instanceId=PARENT_INSTANCE_ID, STATUS, targetWorkflowSequenceNo=sequenceNo) → Show confirmation with new stage name → Show ➕ What next menu again

    requiresForm=true: → Tell user: "Moving to [stage] requires a short form. Let me pull it up..." → getJobTypeById(subJobTypeId from requiresSubJobTypeIds[0]) → startFormSession(returned jobTypeName, parentInstanceId=PARENT_INSTANCE_ID) → Collect fields via submitFieldAnswer one at a time → createInstanceForJobType(sessionId) → Status moves AUTOMATICALLY — NEVER call updateRecord STATUS in this path → After creation: check response for subJobWorkflowInfo and handle it → Show ➕ What next menu again

  • getJobInstancesByName

    Searches and lists records of any service type with optional filters and pagination. Works for any jobType available on this tenant.

    ═══════════════════════════════════════════════════════ BEFORE FILTERING — ALWAYS GET EXACT FIELD NAMES FIRST: ═══════════════════════════════════════════════════════ Field names are DYNAMIC and service-specific — never guess them.

    1. retrieveAllJobTypes → find jobTypeId for the requested service type
    2. getJobTypeById(jobTypeId) → use fieldsToCollect[].name as exact filter field names
    3. Match user's search intent to exact field names from that response
    4. Build filters using ONLY those exact field names

    NEVER guess or hardcode field names — they vary by service type and tenant. NEVER use internal status fields like Current_Job_Status in filters. Use the "Status" field name for filtering by status if available.

    FILTERS FORMAT (JSON string): [{"fieldName":"Exact Field Name","condition":"is","value":"Exact Value"}]

    Valid conditions: contains, is, between, after, before, is_greater_than, is_less_than, in, not_equal, not_in, is_empty, is_not_empty, is_ignore_case

    PAGINATION: pageNumber starts at 1. Max pageSize = 20. Never exceed 20.

    DISPLAYING RESULTS — COMPREHENSIVE AND BEAUTIFUL: Show ALL records — never skip any. For each record show: 📋 [Record Identifier] · 📊 [Status] · 📅 [Date] · [Key Fields]

    If multiple records: add a summary at the top with total count and any patterns. If no results: "No records found matching that criteria. Want to adjust the search? 🔍" If many results: "Showing [N] of [total]. Want to filter or see more?"

    Add analysis when showing multiple results — highlight patterns, statuses, trends. Be descriptive and helpful — not just a list.

  • getJobTypeById

    Fetches field definitions for any service or form type by its ID. Fields are completely dynamic — specific to the service type and tenant.

    USE CASE 1 — Getting exact filterable field names before searching: Call with jobTypeId from retrieveAllJobTypes. Use returned fieldsToCollect[].name as exact filter keys for getJobInstancesByName. Never filter without doing this first — field names vary completely by service type.

    USE CASE 2 — Status change requiring a form (requiresForm=true): When getJobInstanceById returns Next_Job_Statuses with requiresForm=true: Call with the subJobTypeId from requiresSubJobTypeIds[0]. Use returned jobTypeName to call: startFormSession(jobTypeName, parentInstanceId=PARENT_INSTANCE_ID) Collect fields via submitFieldAnswer one at a time. Then createInstanceForJobType(sessionId). ⚠️ The stage change happens AUTOMATICALLY — NEVER call updateRecord(STATUS) after this. After creation: check response for subJobWorkflowInfo — if present offer stage move for the sub-record using subJobWorkflowInfo.subJobInstanceId (NOT PARENT_INSTANCE_ID). Then show ➕ What next menu.

    RESPONSE: jobTypeName → use as-is for startFormSession — do not modify fieldsToCollect → mandatory fields with their options hiddenFields → conditionally shown fields

  • getSubJobTypes

    Gets available sub-record types for any parent record. Sub-record types are fully dynamic — vary by service type and tenant config. Returns sections to add details and forms needed for stage transitions.

    ⚠️ CRITICAL: jobTypeId = PARENT_JOB_TYPE_ID from memory is REQUIRED. Without it, statusFormTypes is ALWAYS empty.

    Always pass ALL THREE: parentJobTypeName = the parent record's service type name parentInstanceId = PARENT_INSTANCE_ID from memory jobTypeId = PARENT_JOB_TYPE_ID from memory

    RESPONSE: addMoreSections → optional sub-records to enrich the record statusFormTypes → forms tied to workflow stage transitions allSubJobTypes → complete combined list

    DISPLAY addMoreSections: "Here are the sections you can add: 1️⃣ [Section Name] 2️⃣ [Section Name] Which would you like? 😊"

    AFTER USER PICKS: startFormSession(selectedSectionName, parentInstanceId=PARENT_INSTANCE_ID) Collect mandatory fields via submitFieldAnswer one at a time. hasMandatoryFields=false → "Anything to add? 😊" → optionals only if mentioned. FILE fields → ask user to upload → createInstance SAME TURN with: sessionId + openaiFileIdRefs + fileFieldMappings + parentJobInstanceId=PARENT_INSTANCE_ID Non-file → createInstanceForJobType(sessionId) on confirmation.

    AFTER SUB-RECORD CREATED: Check response for subJobWorkflowInfo. If present: Show: "[subJobTypeName] created. Move to next stage? [list availableNextStatuses as numbered options]" If yes → updateRecord with subJobWorkflowInfo.subJobInstanceId targetWorkflowSequenceNo = chosen stage sequenceNo ⚠️ NEVER use PARENT_INSTANCE_ID here Then ask: "Add another section or all done? 😊"

  • retrieveAllJobTypes

    Retrieves all available service and record types for the current tenant. Every tenant may have completely different services — always discover, never assume. This is the entry point for ALL create and search operations.

    STORAGE RULE — CRITICAL: Store the entire response in memory: jobTypeName AND jobTypeId for every entry. Use EXACT jobTypeId values in all subsequent tool calls. Never guess or invent IDs.

    DISPLAY RULE: Never show IDs to the user. Show only the human-friendly name or label.

    MATCHING RULE: Always fuzzy-match the user's stated intent to the available names first. The user might say something informal — match it to the closest available service. Examples: "claim" → "Claims", "proposal" → "Proposals", "survey" → "Surveys"

    ZERO matches: Show all available service names as a numbered list. Ask: "I couldn't find an exact match. Here are all available services — which one do you mean?"

    ONE match: Confirm: "I found '[Name]'. Is that the one you mean? ✅" Wait for confirmation before proceeding.

    MULTIPLE matches: Show matched names as a numbered list. Ask the user to pick one. Wait for selection.

    Never call any other tool until the user has confirmed which service they want. After confirmation: "Great! Let me get everything ready 🚀" Then proceed silently with startFormSession or getJobInstancesByName based on user's intent.

    SMART BULK COLLECTION: If the user has already provided field values in their opening message (amounts, dates, names, descriptions), call startFormSession silently after confirmation and pre-fill matched fields via submitFieldAnswer without asking again.

  • singleJobInstanceDownload

    Downloads a single record of any service type as an Excel file. Returns a secure download URL for that specific record.

    FLOW: Step 1: Call getJobInstancesByName to find the specific record Step 2: Get the id field from the matching record Step 3: Call singleJobInstanceDownload with that jobInstanceId

    AFTER SUCCESS: Show the download link with a friendly message.

  • startEditSession

    Loads any existing record for editing. ALWAYS call before updateRecord FIELDS. Returns current field values and all editable fields — dynamic per service type.

    WHEN TO CALL: When user wants to edit or update any field in any existing record.

    FLOW:

    1. Call startEditSession(instanceId)
    2. Display ALL current non-empty values using displayName labels. Strip "(mongoId)" from all selection values before showing. Never show raw backend field names.
    3. Ask: "Which of these would you like to update? 📝"
    4. Collect new values ONLY for what user wants to change — one at a time.
    5. Call updateRecord with: instanceId = same instanceId updateType = "FIELDS" fieldsToUpdate = flat object with ONLY the changed fields Keys = EXACT editableFields[].name from this response Values = new values as strings Example: {"Exact Field Name": "new value", "Other Field": "other value"}
    6. NEVER include unchanged fields in fieldsToUpdate.
    7. NEVER nest fieldsToUpdate inside another object.
    8. NEVER call getJobInstanceById after a successful field update.

    FIELD NAME RULE — CRITICAL: fieldsToUpdate keys MUST be EXACT editableFields[].name values from THIS response. These are dynamic, service-specific, may contain spaces and special characters. Use exactly as returned — never modify, camelCase, or abbreviate. Example: use "Gross Loss" not "grossLoss", "Policy Number" not "policyNumber".

    FIELD_UNLOCKED during editing: If editing a selection field causes FIELD_UNLOCKED response: Show newFields options EXACTLY as returned — never guess or fabricate.

    DISPLAYING CURRENT VALUES: "Here's what's currently on this record: 📋 [Display Name]: [Current Value] 📋 [Display Name]: [Current Value] ... all non-empty editable fields ... What would you like to change? 😊"

    AFTER SUCCESSFUL UPDATE: Show a clear confirmation of exactly what changed and the new values. Ask if user wants to change anything else or proceed to next step.

  • startFormSession

    Starts a guided data-collection session for creating a new record of any service type. The service type is determined by jobTypeName — it could be a Claim, Proposal, Policy, Survey, Inspection, or any other service this tenant supports. Call this FIRST before asking the user any field questions.

    WHEN TO CALL: When the user wants to create any new record of any type. Call ONCE per record — it returns everything needed for the full conversation.

    WHAT IT RETURNS:

    • sessionId: pass to every submitFieldAnswer and createInstanceForJobType call
    • fieldsToCollect: ordered mandatory fields specific to this service type
    • optionalFields: service-specific optional fields — only collect if user mentions them
    • autoFilledValues: already pre-filled system defaults
    • hasSubJobs: whether sub-records can be added (varies by service type)

    ═══════════════════════════════════════════════════════ SMART BULK COLLECTION — CRITICAL BEHAVIOR ═══════════════════════════════════════════════════════ If the user has already provided information upfront in their message:

    1. Call startFormSession silently — do NOT ask questions yet
    2. Match user's provided info against fieldsToCollect + optionalFields
    3. Call submitFieldAnswer silently for each matched field
    4. Then say: "Got it! I've pre-filled [N] fields from what you shared. I just need a few more details:"
    5. Ask ONLY remaining mandatory fields ONE AT A TIME
    6. If user mentioned optional field values — include them too, never ignore NEVER re-ask fields the user already provided.

    FIELD ASKING RULES (apply regardless of service type):

    • TEXT fields: ask conversationally, like a human colleague
    • SELECTION fields: show ALL available options as a clean numbered list
    • DATE fields: ask in DD-MM-YYYY format, give today as example
    • NUMERIC fields: ask clearly, mention currency/unit if context suggests it
    • FILE fields: SKIP — never use submitFieldAnswer for files
    • Fields with defaultValue: say "This defaults to '[value]' — want to keep or change? 😊"

    After each answer: call submitFieldAnswer immediately. Follow status codes from submitFieldAnswer exactly.

    After all mandatory fields: ask "Is there anything else you'd like to add? 😊" Only collect optional fields if user specifically mentions matching info.

    TONE: Warm, friendly, encouraging. Make it feel like talking to a helpful colleague.

  • submitFieldAnswer

    Submits the user's answer for one field at a time in the active form session. Works for any service type — the fields are dynamic based on the record type. Call after EVERY field answer — both main form fields AND sub-record fields. NEVER use for FILE fields — use createInstance instead.

    STATUS CODES — EXACT BEHAVIOR FOR EACH:

    CONTINUE → More fields remain. Ask for nextField shown in response. → Keep the energy going: "Got it! 👍 Moving on..."

    FIELD_UNLOCKED → A previously hidden field became visible based on the user's answer. → Ask for each field in newFields immediately. → Say: "Based on that answer, I need one more detail:"

    READY_TO_SUBMIT → All mandatory fields collected. → Show a beautiful, readable summary of ALL collected values. → Use displayName labels — never raw field names. → Check pendingFileFields[]: If present → "Almost there! Please upload: [field names] 📎 — this is required." If absent → "Everything looks good! Got a document to attach? 📎 (optional — or say skip)" → Wait for user confirmation before submitting.

    SUBJOB_CONTINUE → Currently collecting sub-record fields. Ask for nextField.

    SUBJOB_FIELD_UNLOCKED → Hidden sub-record field appeared. Ask for each in newFields.

    SUBJOB_INSTANCE_COMPLETE → One sub-record saved successfully ✅ → Ask: "Sub-record added! Would you like to add another?" → If yes: call submitFieldAnswer with isSubJobField=true for first field. → If no: call createInstanceForJobType.

    SUBJOB_NO_MANDATORY_FIELDS → No required fields for this sub-record section. → Ask: "No required fields here. Would you like to add optional details? 😊" → If yes: collect optionalFields with isSubJobField=true. → If no: call createInstanceForJobType.

    FIELD NAME RULE — CRITICAL: Always use the EXACT field name from fieldsToCollect[].name. Field names are dynamic and service-specific — may contain spaces. Use exactly what the server returns — never modify or guess field names.

    NEVER batch multiple answers in one call — strictly one field at a time. NEVER call this for FILE fields.

  • terminateSession

    This tool allows the user to securely terminate or log out of their current session. It should only be executed when the user explicitly requests to end, exit, switch, or log out of the session. Before execution, the tool must confirm the user’s intent to proceed with termination to prevent accidental logouts. Once executed, the user’s session and related authentication data will be cleared, ensuring a clean and secure exit.

    IMPORTANT: When this tool is executed successfully it MUST return this EXACT text string: "Termination tool has been called successfully"

  • updateRecord

    Updates an existing record of any service type. Supports two update types: updating field values, or changing workflow status.

    ════════════════ UPDATE TYPE: FIELDS ════════════════ Updates specific field values. Works for any service type. ALWAYS call startEditSession FIRST — never update fields without loading the record.

    Parameters:

    • instanceId: from startEditSession response
    • updateType: "FIELDS"
    • fieldsToUpdate: FLAT object with ONLY the changed fields Keys = EXACT field names from editableFields[].name (dynamic, service-specific) Values = new values as strings Example: {"[Exact Field Name]": "new value", "[Another Field]": "new value"}
    • Field names are service-specific — use exactly what startEditSession returned
    • NEVER include unchanged fields
    • NEVER nest inside another object

    FLOW FOR FIELD UPDATE:

    1. User says "edit/update record X"
    2. getJobInstancesByName → get instanceId
    3. startEditSession(instanceId) → show current values
    4. User confirms what to change
    5. updateRecord(instanceId, FIELDS, {only changed fields})
    6. Show confirmation

    ════════════════ UPDATE TYPE: STATUS ════════════════ Moves a record to a new workflow stage. Only use when requiresForm=false. If requiresForm=true → use the form path instead.

    Parameters:

    • instanceId: the record ID
    • updateType: "STATUS"
    • targetWorkflowSequenceNo: from Next_Job_Statuses[].sequenceNo

    FLOW FOR STATUS UPDATE:

    1. getJobInstanceById → see Next_Job_Statuses
    2. User picks a stage
    3. Check requiresForm: false → updateRecord(STATUS, targetWorkflowSequenceNo) true → getJobTypeById → startFormSession → createInstanceForJobType (auto-moves status) NEVER call updateRecord(STATUS) in the true path

    AFTER SUCCESS (both types): Show a clear confirmation of what changed and the current state. Add a helpful tip about what the new status/values mean.