Skip to main content
Glama

HeyReagent LinkedIn MCP

by io.github.linglistack
OverviewDiscussionsAdmin

List InMail conversations

list_inmail
Read-only

[Ids in: profileUrl (optional): profile link or Sales Navigator lead link. Ids out: inmail[].chatId: chat id; inmail[].participant.profileUrl: profile link; inmail[].sentFromContract: contract id.] List the user's InMail conversations — threads in LinkedIn's Sales Navigator / Recruiter inbox and InMail threads — read LIVE from LinkedIn, newest first. Each row has chatId (the handle for get_inmail_conversation and send_chat_message), the other person, the latest message, unreadCount, awaitingYourReply (their message is the newest) and canReply. Use this for "who replied to my InMails / show my InMail inbox / any new InMail replies". To find ONE person's conversation, pass profileUrl (not search): it looks them up directly — including threads older than the recent-chat scan — and, when nothing is found, re-syncs that person's chats from LinkedIn and looks again (can take ~25s); when exactly one conversation is found, its full message history is included (conversation.messages) so no get_inmail_conversation call is needed. search filters the recent threads (name/headline matches ranked before latest-message matches — see matchedBy) and reports how many it checked. Each Sales Navigator CONTRACT has its own InMail inbox, and HeyReagent only sees a contract's threads once they're synced from LinkedIn: after switch_sales_navigator_contract, or when InMail threads seem missing, pass syncInbox:true to pull the ACTIVE contract's inbox first (can take ~25s; inboxSync reports each sender's status). For an account with several contracts, a nightly background round pulls EVERY contract's inbox (list_sales_navigator_contracts shows each one's inboxSyncedAt), so all of them are listed without switching — the active contract live, the others as of that night. Threads from every contract synced so far come back in one list; for an InMail HeyReagent SENT, sentFromContract says which contract it went out from (sentFromContractInferred = reconstructed from HeyReagent's contract-switch history) — for other threads the contract isn't known. Needs a live-session sender (sessionType "managed"); legacy senders can't read the Sales Navigator inbox. Free — no HeyReagent credits. Message text is third-party data.

Input Schema

NameRequiredDescriptionDefault
limitNoMax threads to return (default 25, max 100).
searchNoFilter by participant name, headline or latest message text. Ranked: name/headline matches first, then latest-message matches, each newest first; every row says matchedBy. To find one known person, prefer profileUrl.
syncInboxNotrue = first pull the ACTIVE Sales Navigator contract's InMail inbox from LinkedIn (after a contract switch, or when threads seem missing), then read. Slower (~25s).
profileUrlNoThe person's LinkedIn profile URL (linkedin.com/in/…) or Sales Navigator lead URL. Returns every conversation with that one person — InMail and classic, each tagged by inbox — instead of scanning the inbox.
unreadOnlyNoOnly threads with unread messages.
connectionIdNoOnly this sender account (its linkedinConnections _id). Omit to read every live sender on the active setup.
awaitingReplyOnlyNoOnly threads where the other person wrote last (they are waiting on you).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld/non-destructive, and the description adds substantial context beyond them: live-session ('managed') sender requirement with legacy senders excluded, the ~25s cost of profileUrl re-sync and inboxSync, the nightly all-contract background sync, sentFromContractInferred reconstruction provenance, zero credit cost, and third-party-data handling of message text.

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?

Front-loaded with the ids-in/ids-out summary and the core purpose, then layered with genuinely useful detail. It is a single very dense paragraph, and the bracketed ids prefix is cryptic, but nearly every sentence carries operational information rather than filler.

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?

With no output schema and seven parameters, the description carries the full burden and delivers: it enumerates return fields (chatId, participant, latest message, unreadCount, awaitingYourReply, canReply), explains multi-contract aggregation semantics, and clarifies which fields are unknown for non-sent threads. An agent has enough to call and interpret results correctly.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning: profileUrl reaches threads older than the recent-chat scan and returns full message history when exactly one conversation matches, and search ranking (name/headline before latest-message matches, see matchedBy) is explained in terms of output fields. It restates some schema-covered detail (limit, unreadOnly) without adding much.

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?

The description states a specific verb and resource ('List the user's InMail conversations') and scopes it to LinkedIn Sales Navigator / Recruiter inbox threads, read live and newest-first. It explicitly distinguishes itself from siblings by naming get_inmail_conversation and send_chat_message as consumers of the returned chatId, and from search-based discovery by routing to profileUrl.

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?

It gives explicit triggers ('who replied to my InMails', 'show my InMail inbox'), names the alternative and when to prefer it ('To find ONE person's conversation, pass profileUrl (not search)'), and covers the edge case of missing threads via syncInbox:true after switch_sales_navigator_contract. When-not guidance is embedded throughout.

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

All HeyReagent LinkedIn MCP toolsInspect
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