Skip to main content
Glama

Read People's Latest LinkedIn Posts

li_fetch_posts

Fetch each person's latest LinkedIn posts so you can personalise the first touch: pick ONE post and write the connection note or first message about it before importing, or choose the post to react to in the engage-before-invite step. Up to 2 posts per person, newest first, their own words only: plain reposts are left out, and a quote post is marked isRepost with a short cut of the post it shares (repostOf). Each post carries url, text (cut at 1,200 characters), postedAt, reactions and comments (null = the provider did not say, never 0), and reactable: false means the engage-before-invite step cannot use it (a group post, or another link li_ingest_prospects refuses as engagePostUrl; notReactable says why). No browser and no LinkedIn account is used; this reads a third-party provider. COST: 1 enrichment lookup per person not already read in the last 3 days, from the same shared pool as li_enrich_profiles, whether they have 2 posts or none; anyone read recently comes back free (cached: true), and refresh=true re-reads at full price. Per-person status: posts (found), no_posts (read: nothing of their own, or nothing inside sinceDays; charged; olderPosts counts what sinceDays hid), not_found (the provider says it is not a profile it can read; not charged), unreadable (the provider answered and we could not tell what it means; not charged, retry later), failed (the read broke; not charged), skipped_no_credits, skipped_plan_inactive. Never read unreadable or failed as "they do not post". Siblings: for who a person IS (headline, role, employer) use li_enrich_profiles; for what we already hold on a contact, including posts read earlier at no cost, use li_contact_dossier with fields ['posts']. Pass estimateOnly=true first for a long list: it reads nothing and charges nothing. Always relay message: it says what was charged and what is left.

Input Schema

NameRequiredDescriptionDefault
refreshNoIgnore posts read in the last 3 days and read again. Costs a lookup for every person.
maxPostsNoHow many of each person's latest posts to return, 1 to 2 (more is read as 2). Default 2. Costs the same either way: 1 lookup per person.
sessionIdNoAccount id from li_list_accounts. Needed (or sessionLabel) when you have more than one account; never guessed.
sinceDaysNoOnly return posts from the last N days. A person whose latest posts are all older comes back no_posts with `olderPosts` saying how many were hidden. Default: no age limit.
profileUrlsYesLinkedIn profile URLs. One real read takes at most 50 people and a longer list is refused rather than cut short; estimateOnly answers for up to 500 and says how many calls to split it into.
estimateOnlyNoPreview instead of reading anything: how many were read recently (free), how many would be read, how many lookups that charges and what is left. Charges nothing and reserves nothing.
sessionLabelNoAccount by label, LinkedIn name, profile slug or member id (li_list_accounts). Needed (or sessionId) when you have more than one account; never guessed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / maxPosts / description
      Previous value: -"How many of each person's latest posts to return, 1 to 3. Default 3. Costs the same either way: 1 lookup per person."New value: +"How many of each person's latest posts to return, 1 to 2 (more is read as 2). Default 2. Costs the same either way: 1 lookup per person."
    • removedInput schema / properties / maxPosts / maximum
      Removed value: -3
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only flag readOnlyHint=false/openWorldHint=true; the description goes far beyond by disclosing the cost model (1 lookup per person, shared pool with li_enrich_profiles, free within 3 days, refresh=true at full price) and the full per-person status taxonomy with which statuses are charged. It also warns against misreading unreadable/failed as 'they do not post' and explains reactable/notReactable. No contradiction with annotations — the readOnlyHint=false is consistent with credit-charging reads.

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?

Purpose and the actionable instruction are front-loaded, and virtually every sentence carries operational weight (cost, statuses, field semantics). It is nonetheless a very dense single block that would scan better broken into cost / output / status sections.

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?

No output schema exists, and the description compensates fully: it enumerates returned fields (url, text cut at 1,200 chars, postedAt, reactions/comments with null-means-unknown, reactable), the status enum, and the billing outcome. An agent has everything needed to call, interpret, and report cost correctly.

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

Parameters3/5

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

Schema coverage is 100%, so each parameter is already documented (refresh cost, maxPosts 1-2, sinceDays/olderPosts, estimateOnly, sessionId/sessionLabel). The description reinforces a few semantics — 'Up to 2 posts per person, newest first' and the olderPosts-charged interaction — but adds little the schema does not already say. Baseline 3 applies.

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?

Specific verb+resource ('fetch each person's latest LinkedIn posts') plus the concrete downstream purpose (personalise the first touch, pick a post to react to). It also explicitly distinguishes itself from li_enrich_profiles (identity) and li_contact_dossier (held data), so an agent can route without opening sibling schemas.

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?

Explicit when-to-use: pick ONE post before importing, or choose the post for engage-before-invite. It names alternatives and their conditions ('for who a person IS use li_enrich_profiles', 'for what we already hold use li_contact_dossier with fields [posts]') and prescribes estimateOnly=true first for long lists.

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