Reach MCP — LinkedIn for AI agents

list_conversations

Read-onlyIdempotent

List LinkedIn messenger conversations (Voyager Messaging GraphQL), with optional archived, unread, starred filters and next_cursor paging — same as GET /api/linkedin/{account_id}/conversations. Each item returns conversation_id (the thread id — use this as conversation_linkedin_id when fetching messages or replying) and recipient_linkedin_id (the peer's fsd_profile id — use this as recipient_linkedin_id when sending a new message). last_message_from_me tells who wrote the last message: false means the other side spoke last and a reply is owed (last_message_sender_name says who, in group chats). since (ISO date or datetime) keeps only conversations active since then and drops next_cursor once older ones are reached, e.g. 'messages since Monday'. Do not call this in a loop to wait for replies: the same read is refused if repeated within 60s, inbox reads are capped at 300 per account per day, and polling gets LinkedIn accounts restricted. Subscribe a webhook to message.received instead. Use for the classic LinkedIn inbox (this is the one that matters in 95% of cases); Sales Navigator threads are separate, see salesnav_list_messaging_threads.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "account_id": "<account_id>"
    },
    "name": "list_conversations"
  }
}

Input Schema

Name	Required	Description
`count`	No	Page size.
`since`	No	Only conversations with activity since this ISO date or datetime (UTC unless an offset is given), e.g. 2026-11-02.
`unread`	No	Only conversations with unread messages.
`page_id`	No	Read this company page's inbox instead of the member's (page_id from list_managed_pages; needs read_messages and messaging on). unread and starred then filter the page of results LinkedIn returns.
`starred`	No	Only starred conversations.
`archived`	No	Only archived conversations.
`account_id`	Yes	Reach id of the LinkedIn account to act on, from list_accounts.
`next_cursor`	No	Cursor returned by the previous page; omit for the first page.

Output Schema

Name	Required	Description
`count`	No	Requested page size (LinkedIn typically caps at 25).
`items`	No
`since`	No	Only conversations active since this time are listed. ``next_cursor`` is dropped once the page reaches older ones: nothing more to fetch.
`unread`	No	Matches query: unread filter (search query with ``read:false``).
`starred`	No	Matches query: starred folder or client filter when combined.
`archived`	No	Matches query: archived folder (``category:ARCHIVE``) when not unread.
`next_cursor`	No	Pass as ``next_cursor`` for the following page when present.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 5, 2026

addedInput schema / properties / since

Added value: +{
+  "description": "Only conversations with activity since this ISO date or datetime (UTC unless an offset is given), e.g. 2026-11-02.",
+  "type": "string"
+}

addedOutput schema / $defs / LinkedInConversationListItemOut / properties / last_message_from_me

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "True when the account (or the page, for a page inbox) wrote the last message, false when the other side did: false means a reply is owed. Absent when LinkedIn sent no sender.",
+  "title": "Last Message From Me"
+}

addedOutput schema / $defs / LinkedInConversationListItemOut / properties / last_message_sender_linkedin_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "``fsd_profile`` id of who wrote the last message (absent for a page).",
+  "title": "Last Message Sender Linkedin Id"
+}

addedOutput schema / $defs / LinkedInConversationListItemOut / properties / last_message_sender_name

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Name of who wrote the last message.",
+  "title": "Last Message Sender Name"
+}

addedOutput schema / properties / since

Added value: +{
+  "anyOf": [
+    {
+      "format": "date-time",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only conversations active since this time are listed. ``next_cursor`` is dropped once the page reaches older ones: nothing more to fetch.",
+  "title": "Since"
+}

Changed1 schema field changedNov 3, 2026

addedInput schema / properties / page_id

Added value: +{
+  "description": "Read this company page's inbox instead of the member's (page_id from list_managed_pages; needs read_messages and messaging on). unread and starred then filter the page of results LinkedIn returns.",
+  "type": "string"
+}

First observedSep 10, 2026

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/is idempotent/non-destructive, but the description adds operational context annotations cannot carry: repeated identical reads are refused within 60s, inbox reads are capped at 300 per account per day, and polling risks account restriction. It also explains that since drops next_cursor once older conversations are reached, which changes pagination behavior. Slight gap: it does not describe ordering of returned results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded: the core action, then field contracts, then filters, then rate-limit warnings, then sibling routing. Every sentence carries useful information, though the single unbroken paragraph of ~180 words could be segmented for faster scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter read tool with an output schema, the description covers scope, sibling differentiation, rate limits, pagination interaction with filters, and the meaning of the returned identifiers across other tools. Nothing an agent needs in order to call it correctly or avoid abusing it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds cross-tool field semantics the schema cannot: conversation_id maps to conversation_linkedin_id for messages/replies, recipient_linkedin_id maps to recipient_linkedin_id for send_message, and last_message_from_me/last_message_sender_name encode 'reply owed'. It also clarifies since filtering interacts with paging, beyond the schema's plain ISO-format note.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List LinkedIn messenger conversations'), names the backend (Voyager Messaging GraphQL / GET /api/linkedin/{account_id}/conversations), and explicitly separates itself from salesnav_list_messaging_threads while claiming the classic inbox. An agent can route between the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ('the classic LinkedIn inbox — this is the one that matters in 95% of cases'), when-not-to-use (Sales Navigator threads, with the named sibling), and a hard prohibition on polling with the alternative prescribed (subscribe a webhook to message.received). This is a complete routing decision.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Reach MCP — LinkedIn for AI agents tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?