Skip to main content
Glama

Inbound (Received) Connection Requests

li_received_invitations

List the connection requests people sent to this account that are awaiting a decision, each with name, HEADLINE (role + company), mutual connections, profile URL, the inviter's permanent memberId (ACoAA…) and a decision block from the triage memory. Read-only on LinkedIn.

RETURNS A JOB ID AND DOES NOT WAIT (by default). A long tray takes minutes to walk — a 57-invite tray at scrollPasses 40 outlived the client's 180s wait while the job finished fine. Read the result with li_job_result({ jobIds: [jobId], waitMs: 120000 }) — waitMs is honoured with jobIds, not jobId. Pass wait=true only for a small tray.

TRIAGE MEMORY. Every row carries decision: null if this account never judged them, else { decision (accepted | rejected | wrong_lane | failed | deferred), reason, icp, campaignId, routeTo, decidedAt, changedSinceDecision } — and changes (headlineBefore/Now, companyBefore/Now) when their headline or company moved since they were judged (case, whitespace and emoji ignored). People are matched on the member id, so a renamed vanity URL is still recognised. onlyUnreviewed=true returns ONLY the rows that need judging: never judged, a failed accept to retry, or changed since judged — and counts still covers the whole tray: { total, unreviewed, alreadyDecided: { accepted, rejected, wrong_lane, deferred }, failedRetry, changed }, so you can say '56 already checked' without listing them. Record verdicts with li_mark_invitations; li_accept_invitations records accepted/failed by itself. Each read also updates first/last-seen on every person it saw.

CONNECTION REQUESTS ONLY, by default. The same page carries newsletter-subscription and page-follow invitations listed against the inviter's own profile; accepting 'them' subscribes the account to a newsletter. filteredOut counts them; includeNonConnection=true shows them (with decision: null — they are never a connection decision).

🚨 READ pageState.reachedEnd BEFORE CONCLUDING ANYTHING FROM AN ABSENCE. When false, countsAreFloor is true and a reachNote says so: somebody missing may simply be below where the walk stopped. Nothing is ever marked gone from a read. Raise scrollPasses and read again.

Input Schema

NameRequiredDescriptionDefault
waitNoBlock until the read finishes and return the list directly. Default false (returns a jobId — read it with li_job_result). Only for a small tray.
sessionIdNoAccount id from li_list_accounts. Omit (with sessionLabel) to use your default account.
scrollPassesNoA CEILING on scroll passes, not a fixed number — the walk stops as soon as the card count settles and reports `pageState.reachedEnd`. About ten invitations load per pass. Default 12; raise it for a big backlog.
sessionLabelNoAccount by label, LinkedIn name, profile slug or member id (li_list_accounts). Omit (with sessionId) to use your default account.
onlyUnreviewedNoReturn only people never judged, failed accepts to retry, and people whose headline/company changed since they were judged. Counts still cover the whole tray. Default false.
includeNonConnectionNoAlso list newsletter, page-follow and event invitations. Default false — they are not requests to connect.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / sessionId / description
      Added value: +"Account id from li_list_accounts. Omit (with sessionLabel) to use your default account."
    • addedInput schema / properties / sessionLabel / description
      Added value: +"Account by label, LinkedIn name, profile slug or member id (li_list_accounts). Omit (with sessionId) to use your default account."
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

With annotations present, the bar is lower, yet the description adds substantial behavioral context beyond them: the async job pattern (returns a jobId, must be read with li_job_result, waitMs honoured with jobIds not jobId), a concrete timing anecdote (57-invite tray at scrollPasses 40 outlived a 180s wait), the side effect that each read updates first/last-seen, and the reachEnd/countsAreFloor caveat. The 'Read-only on LinkedIn' claim sits alongside readOnlyHint=false, but the description itself resolves this by disclosing the local first/last-seen mutation, so there is no contradiction.

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?

It is long but front-loaded with bold headers and almost every block earns its place (async contract, triage memory shape, newsletter trap, reachEnd warning). The one anecdotal sentence about the 57-invite tray is slightly verbose but supports the timing claim.

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?

There is no output schema, so the description carries the full burden of describing returns, and it does: the decision block fields, the changes object, counts breakdown, filteredOut, and pageState.reachedEnd/countsAreFloor/reachNote. For a 6-param tool with no output schema this is complete.

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 meaning beyond the schema: it explains why onlyUnreviewed exists (never judged, failed retry, changed since judged), that counts still cover the whole tray, and what includeNonConnection surfaces (newsletter/page-follow invitations with decision: null). This goes past restating the schema.

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+resource ('List the connection requests people sent to this account that are awaiting a decision') and enumerates the returned fields (name, headline, mutual connections, memberId, decision block). It is clearly distinguishable from siblings like li_pending_invites (outbound) and li_new_connections.

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?

Explicitly routes the agent to alternatives: 'Record verdicts with li_mark_invitations; li_accept_invitations records accepted/failed by itself.' It also gives when-to-use conditions for onlyUnreviewed, includeNonConnection, and wait (small tray only), so nothing about selection is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources