Search Linkedin Message History
search_linkedin_message_historyRead-only
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results (default 50, max 200). Only override if the user says a specific number like "show me 10 messages". For vague quantities ("couple", "few", "recent"), omit this parameter to use the default. | |
| offset | No | Rows to skip for paging (default 0). When the result is truncated, re-call with offset += limit to fetch the next page. | |
| order_by | No | SQL ORDER BY clause (default: message_datetime DESC). | message_datetime DESC |
| as_teammate | No | Read a consented teammate's LinkedIn message history instead of your own — pass their email. Gated on that teammate's conversation-sharing setting; a teammate who hasn't shared is rejected. Omit for your own. | |
| where_clause | Yes | SQL WHERE clause (without WHERE keyword). Use ONLY these columns: provider, chat_id, sender_name, sender_provider_id, recipient_name, recipient_provider_id, content, message_datetime, reply_outcome (inbound replies only; '' / 'interested' / 'meeting_booked' / 'not_interested' — the reply's classified outcome). To check whether a prior conversation exists before firing a templated message, match on `sender_provider_id`/`recipient_provider_id` first; if that returns zero rows, run a second pass matching the person's full name (first AND last) as a substring, e.g. `sender_name ILIKE '%Jane%Doe%' OR recipient_name ILIKE '%Jane%Doe%'`, before concluding there's no history — a stored provider_id is often blank or wrong, so an exact-match zero is indistinguishable from "never messaged." Never match on first name alone (it pulls every same-first-name person in the inbox and risks dropping a cold message onto a stranger's live thread). The full-name pass is a substring match, so if it spans more than one person (different provider_ids), use only the thread whose counterpart is your recipient — don't merge look-alike names or reuse a mismatched `chat_id`. Even both passes empty isn't proof of no prior contact: this local store holds only a bounded initial backfill from around when the account was connected, forward, so an older or pre-connection thread may never have been ingested — and the same person may be stored under a variant name a substring match misses. When you have the counterpart's `provider_id` and need certainty, call `fetch_linkedin_messages_with_person` — it reads LinkedIn's full synced history live and writes it back here; if that also returns empty, treat "no history" as confirmed, otherwise flag the uncertainty when a cold-open template goes to approval. |