Workflows and examples

Prepare a customer meeting

Ask: “Prepare me for the meeting with alex@example.com. Show open and closed deals, contacts, notes and the latest documented exchange.” frida_prepare_customer_briefing accepts an exact email directly. Choose the intended customer if results are ambiguous.

The response combines customer totals per currency and at most three deals with bounded notes, history and mail excerpts. It creates no meeting. Separate stored facts from the assistant’s suggestions.

{
  "name": "frida_prepare_customer_briefing",
  "arguments": {
    "email": "alex@example.com",
    "deal_limit": 2
  }
}

{
  "selected_deals": 2,
  "more_contacts": false,
  "selection_is_complete": false
}

Review pipeline history

Ask: “Show my pipeline over the last 12 weeks. Keep currencies separate and show incomplete coverage.” Use frida_get_pipeline_overview for totals and frida_get_pipeline_history for periods. Never total a paginated deal list yourself.

recorded_pipeline contains observed opening and closing balances. complete_since identifies the start of coverage. Earlier or partial coverage means unknown, not zero. Deal value is not booked revenue.

{
  "name": "frida_get_pipeline_history",
  "arguments": {
    "interval": "week",
    "periods": 12,
    "time_zone": "Europe/Copenhagen"
  }
}

{
  "recorded_pipeline": null
}

Find exact Outlook IDs

Find the deal with frida_search_deals and pass its deal_id to frida_get_deal_mail_references. Follow next_cursor for further pages. The response provides references, not message content.

Internal Frida IDs, provider message IDs, thread IDs and internet IDs are separate fields. Preserve them exactly. Outlook IDs can change on folder moves. Use the same mailbox; fetching through another Outlook integration is unverified. Native Outlook contact IDs are not stored.

{
  "name": "frida_get_deal_mail_references",
  "arguments": {
    "deal_id": "00000000-0000-4000-8000-000000000001",
    "limit": 50
  }
}

{
  "has_more": true,
  "next_cursor": "illustrative-opaque-cursor",
  "coverage": "partial_stored_deal_mail"
}

Update a deal after a call

Say precisely what should change and on which deal. The assistant must describe the change first and have approved deals.write access. This example changes only value and requires your explicit request.

For frida_update_deal, read the deal first, pass updated_at as expected_updated_at, and generate one request_id per intended change. After a timeout reuse the same ID and identical input. Check the receipt with frida_get_change_status; never claim success without a receipt.

The receipt contains before and after. Notes, value, stage and expected close date can be undone for 24 hours using change_id if the same field has not changed since. Check undo_available and undo_until in the receipt; a previously empty value cannot be restored here. This does not automatically apply to follow-up actions or question answers.

{
  "name": "frida_update_deal",
  "arguments": {
    "change": {
      "deal_id": "00000000-0000-4000-8000-000000000001",
      "action": "set_value",
      "value": 25000,
      "expected_updated_at": "2026-10-05T10:00:00Z",
      "request_id": "00000000-0000-4000-8000-000000000002"
    }
  }
}

Review changes since last time

Use frida_get_changes with since, or continue with next_cursor. Finish all pages: counts_by_kind counts only the current page. Keep returned as_of for the next review. Recurring reviews require a separate scheduled task in your assistant; MCP does not start them itself.