Call the getConversations MCP tool

List LinkedIn inbox conversations. OMIT account_id to read a unified inbox across ALL connected accounts (one merged, most-recent-first page); pass an account_id (from getLinkedInAccounts) to read just that account. Each chat returns the other person’s name, unread count, last-activity time, the owning account (account_id + account_name), campaign attribution (campaign_id + campaign_name + lead_state, aliased as status) when the chat came from a campaign, the lead’s classification tags, and last_category (the most recent AI reply classification; only populated for campaigns with the reply agent enabled - null for organic chats is normal). Each chat also carries last_message_from ("them" | "you" | null) and has_recent_inbound - use these to count who actually replied or wrote in, INCLUDING organic (non-campaign) conversations, which getWorkspaceStats deliberately excludes from its campaign-only replies number. null direction means unknown (outside the sampled window - see direction_note), never "no reply". Optionally filter by status and/or tags. Pass include_lead_details: true to also get linkedin_url, job_title, company_name, and location for the chat’s lead (omitted by default; an extra lookup most callers don’t need). A chat whose other person is not a tracked lead comes back with name: null (LinkedIn’s chat list itself carries no names for those) - the response then also includes a top-level name_note explaining this and pointing at resolve_names. Pass resolve_names: true to live-fetch up to 5 of those names (adds latency; do this only when the user actually needs the name). Use getConversationMessages to read a thread. Replying requires a key with the launch scope (sendReply); without it, the user replies from the Reachium inbox. NOTE: when status or tags is supplied, filtering happens AFTER the underlying LinkedIn page is fetched, so a returned page can have fewer than limit items even though more may match; keep following next_cursor until it is null to see everything.

Called through the Actions bridge: the response is that tool's own result, wrapped as { data: <tool result> } under HTTP 200. Billing, daily-cap, and confirm-step outcomes are embedded INSIDE data, never remapped to an HTTP status (see the templated /api/v1/actions/{toolName} operation above for the full protocol, and x-mcp-actions for this tool's machine-readable scope/cap/confirm_behavior fields). Authentication, request-shape, and optional idempotency-protocol failures still use their documented non-200 statuses.