Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-linkedin-post-engager-capture Show me recent posts and commenters from Bill Gates' LinkedIn"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for the Mamba Labs LinkedIn Post Tracker and Comment Capture actor on Apify.
Point it at LinkedIn person profiles or company pages. It returns their recent posts as flat rows, with the real reaction and comment counts on every one, plus the commenters LinkedIn shows publicly. No cookies, no LinkedIn account, no credentials of any kind.
npx -y @mambalabsdev/mcp-linkedin-post-engager-capture{
"mcpServers": {
"mamba-linkedin-post-engager-capture": {
"command": "npx",
"args": ["-y", "@mambalabsdev/mcp-linkedin-post-engager-capture"],
"env": { "APIFY_TOKEN": "your-apify-token" }
}
}
}Get an Apify token at console.apify.com/account/integrations.
Related MCP server: LinkedIn Data API MCP Server
capture_linkedin_posts_and_commentersLinkedIn profiles and company pages in, their recent posts and public commenters out.
Input | Type | Required | Notes |
| array | no | Person profiles, for example |
| array | no | Company pages, for example |
| string | no | ISO date, for example 2026-08-01. Posts older than this are skipped before anything is charged. |
| boolean | no | One row per public commenter. Turn it off to collect posts only. Default |
| boolean | no | Returns no reaction rows whatever you set, because LinkedIn serves no reactor identities to a logged-out visitor. Present so the limit is visible rather than silent. Default |
| integer | no | 0 to 100. Ten is LinkedIn's own ceiling for a logged-out visitor, so raising it above 10 does nothing. Set it to 0 to pay for posts only. Default |
| boolean | no | Off by default, which is what the pricing assumes. Apify bills residential bandwidth on top of this actor's events. Default |
Nothing is required. A call with neither URL list comes back as a no_input notice row rather than an error, which mirrors the actor exactly.
One dataset carries three row types, told apart by row_type. Filter on it before loading a table.
post is one row per LinkedIn post.
engager is one row per public commenter, joined to the post on post_id.
notice is a run-level or source-level message.
post_id is the numeric part of LinkedIn's activity URN. It is stable across runs, across country subdomains and across both permalink spellings, so it is safe as a primary key and safe as the "have I already posted this to Slack" check.
The commenter limits are real and they are not small. LinkedIn renders about ten top-level comments to a logged-out visitor whatever the true total. Measured whole-run coverage was 178 commenters out of 4,857 that existed, which is 3.7 percent. About 30 percent of comment rows carry no timestamp. Every post row carries commenters_collected beside commenters_available so the coverage on any given post is a number you can read rather than something you infer.
Reactor identities are not available at all to a logged-out visitor. Every post row still carries the real reaction_count, and reactors_status says unavailable_without_login.
Every row carries degraded and degradation_reason. false means the actor looked; null on a field means it could not. Filter on degraded before you trust an absence. Two things that look like failures are deliberately not degraded, because both are measurements: reactors_unavailable is how logged-out LinkedIn works, and no_posts_found on a page that loaded is a real absence.
You are charged per post collected and per commenter collected, plus a small actor start fee. Notice rows are free. posted_since filters before anything is charged, so a scheduled run that finds nothing new costs the actor start and nothing else.
There is no result cache: every run refetches, which is the right behavior for an actor whose job is to notice new posts. Pricing is on the actor's Apify page. Running this server consumes Apify credits.
It is a thin client for the Apify actor. It passes your input through and returns the actor's output unchanged. Every behavior described above lives in the actor, not here.
It reads only what LinkedIn serves to a logged-out visitor. It holds no session cookie, uses no LinkedIn account, and reads nothing behind a login.
Commenter rows are named people. When you run this you are the data controller for the personal data it returns and Apify is the processor. Your lawful basis is yours to establish; nothing here is legal advice.
This actor is unofficial and is not affiliated with, sponsored by or endorsed by LinkedIn or Microsoft.
Errors are surfaced, never swallowed. An invalid input, an invalid token, an exhausted balance, a timeout, or a run that returns anything other than a dataset all come back as an explicit tool error rather than as an empty result.
The actor is on the Apify Store. This wrapper is MIT licensed.
Built by Mamba Labs
Point it at LinkedIn person profiles or company pages and it returns their recent posts as flat rows, with the real reaction and comment counts on every one, plus the commenters LinkedIn shows publicly. No cookies, no LinkedIn account, no credentials of any kind. One dataset carries three row types told apart by row_type: post, engager and notice, so filter on row_type before loading a table. post_id is the numeric activity URN and is stable across runs and across both permalink spellings, which makes it safe as a primary key and as a have-I-already-seen-this check. Read the limits before relying on the commenters: LinkedIn renders about ten top-level comments to a logged-out visitor whatever the real total, measured whole-run coverage was 3.7 percent, and roughly 30 percent of comment rows carry no timestamp. Reactor identities are not served to a logged-out visitor at all, so every post row carries the real reaction_count and reactors_status says unavailable_without_login. Every row carries degraded and degradation_reason: filter on degraded before you trust an absence. Requires an APIFY_TOKEN and consumes Apify credits. Read only.
| Name | Required | Description | Default |
|---|---|---|---|
| company_urls | No | LinkedIn company page URLs whose recent posts you want, for example https://www.linkedin.com/company/microsoft. Supply this, profile_urls, or both. | |
| posted_since | No | ISO date or timestamp, for example 2026-08-01. Posts published before this are skipped BEFORE anything is charged, so a scheduled run that finds nothing new costs the actor start and nothing else. Leave empty to take everything the page advertises. | |
| profile_urls | No | LinkedIn person profile URLs whose recent posts you want, for example https://www.linkedin.com/in/williamhgates. Country subdomains such as uk.linkedin.com are fine. Supply this, company_urls, or both. | |
| collect_reactors | No | LinkedIn serves no reactor identities to a logged-out visitor, so this returns no reaction rows whatever you set. It exists so the limit is visible rather than silent, and it adds one notice row per run. Set it to false to suppress that row. Default: true. | |
| collect_commenters | No | Return one row per person who commented, with name, profile URL, comment text and comment likes. Turn it off to collect posts only, in which case commenters_collected comes back null rather than 0, because the actor did not look. Default: true. | |
| max_engagers_per_post | No | Caps the engager rows charged per post. LinkedIn shows about ten comments to a logged-out visitor, so ten is the platform ceiling and raising this above ten does nothing. Set it to 0 to pay for posts only. Default: 10. | |
| use_residential_proxy | No | Off by default, which is what the pricing assumes and what was measured. Turn it on only if LinkedIn starts refusing the platform's datacenter addresses. Apify bills residential bandwidth on top of this actor's events. Default: false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, and the description aligns with all of them. It goes well beyond the annotations by disclosing concrete behavioral traits: no credentials needed, approximately ten comments are shown to logged-out visitors (3.7% coverage), 30% of comment rows lack timestamps, reactors are unavailable without login, and every row carries degraded and degradation_reason. This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but every sentence carries distinct value: purpose, data model, key fields, limitations, degraded flags, and prerequisites. It is front-loaded with the core function and then layers caveats logically. It is dense but not wasteful; a perfect 5 would require slightly tighter phrasing without losing needed caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has no output schema and seven optional parameters, but the description compensates fully: it explains the three row types, stable post_id semantics, commenter and reactor limitations, degraded flag usage, and the requirement for APIFY_TOKEN and credits. There is no missing context an agent would need to call the tool correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter in the input schema has a detailed description (e.g., posted_since skips before charge, max_engagers_per_post caps at ten, collect_reactors returns no rows). The tool description itself does not add significant parameter-specific semantics beyond the schema; it focuses on output structure and limitations. Per the rubric, the high schema coverage supports a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise statement of what the tool does: it points at LinkedIn person or company pages and returns posts, reaction/comment counts, and public commenters as flat rows. It also immediately distinguishes the data model with row_type, making the purpose unmistakable. No sibling tools exist, so differentiation is not applicable, but the purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There are no sibling tools to contrast against, but the description gives strong operational guidance: filter on row_type before loading, use post_id as a primary key, check degraded before trusting absences, and read limits before relying on commenters. It does not explicitly state 'use this when X instead of Y', but the context it provides is sufficient for an agent to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.1capture_linkedin_posts_and_commentersWith only one tool, there is no possibility of ambiguity between tools. The purpose is clearly described.
The single tool name follows a descriptive verb_noun pattern and clearly indicates its action and target. Consistency is not a concern with only one tool.
A single tool is on the borderline of being too thin for a server, even if it encapsulates a complex workflow. The tool is comprehensive in scope but represents only one function under the server's 'engage' name.
The tool captures posts and commenters but explicitly lacks reactor identities and has limited comment coverage, despite the server name suggesting engagement capabilities. This leaves significant gaps in the stated purpose of engaging with LinkedIn content.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Scrape and analyze public LinkedIn posts as structured JSON via the Apify LinkedIn Posts API.
Live LinkedIn data for AI agents: profiles, companies, jobs, posts, email finding. No account risk.
Search LinkedIn & Sales Navigator. Get structured people, companies, posts, jobs data. 4.9/5 on G2.
LinkedIn profile scraper: herkese açık profil bilgilerini toplu şekilde çıkarır ve dışa aktarır.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mambalabsdev/mcp-linkedin-post-engager-capture'
If you have feedback or need assistance with the MCP directory API, please join our Discord server