MCPサーバー for the Mamba Labs LinkedIn Post Tracker and Comment Capture actor on Apify.
LinkedInの個人プロフィールや企業ページを指定します。最近の投稿をフラットな行として返し、各投稿の実際のリアクション数とコメント数、さらにLinkedInが公開しているコメント投稿者を返します。CookieもLinkedInアカウントも、いかなる認証情報も必要ありません。
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" }
}
}
}Apifyトークンはconsole.apify.com/account/integrationsで取得できます。
Related MCP server: LinkedIn Data API MCP Server
capture_linkedin_posts_and_commentersLinkedInプロフィールと企業ページを入力として、最近の投稿と公開コメント投稿者を出力します。
入力 | 型 | 必須 | 備考 |
| array | いいえ | 個人プロフィール。例: |
| array | いいえ | 企業ページ。例: |
| string | いいえ | ISO日付。例: 2026-08-01。これより古い投稿は課金される前にスキップされます。 |
| boolean | いいえ | 公開コメント投稿者ごとに1行。オフにすると投稿のみを収集します。デフォルトは |
| boolean | いいえ | 設定に関係なくリアクション行は返されません。LinkedInはログアウトした訪問者にリアクションした人の身元を提供しないためです。制限を黙らせるのではなく可視化するために存在します。デフォルトは |
| integer | いいえ | 0〜100。10はLinkedInがログアウトした訪問者に提供する上限なので、10を超えても効果はありません。0に設定すると投稿のみに課金されます。デフォルトは |
| boolean | いいえ | デフォルトではオフ。これは価格設定が前提としている設定です。Apifyはこのアクターのイベントに加えて、住宅用プロキシの帯域幅を請求します。デフォルトは |
必須項目はありません。どちらのURLリストも指定しない呼び出しは、エラーではなくno_input通知行として返されます。これはアクターの動作を正確に反映しています。
1つのデータセットには3種類の行があり、row_typeで区別されます。テーブルを読み込む前にこれでフィルタリングしてください。
postはLinkedInの投稿ごとに1行です。
engagerは公開コメント投稿者ごとに1行で、post_idで投稿に結合されます。
noticeは実行レベルまたはソースレベルのメッセージです。
post_idはLinkedInのアクティビティURNの数値部分です。実行間、国別サブドメイン間、両方のパーマリンク表記間で安定しているため、主キーとしても「これをSlackに投稿済みか」のチェックとしても安全です。
コメント投稿者の制限は現実的で、決して小さいものではありません。 LinkedInはログアウトした訪問者に対して、実際の総数に関係なく約10件のトップレベルコメントを表示します。測定された実行全体のカバレッジは、存在した4,857件中178件のコメント投稿者で、3.7%でした。コメント行の約30%にはタイムスタンプがありません。各投稿行にはcommenters_availableの横にcommenters_collectedが含まれるため、特定の投稿のカバレッジは推測ではなく読み取れる数値です。
リアクションした人の身元はログアウトした訪問者には一切利用できません。 それでも各投稿行には実際のreaction_countが含まれ、reactors_statusはunavailable_without_loginと表示されます。
すべての行にはdegradedとdegradation_reasonが含まれます。falseはアクターが確認したことを意味し、フィールドのnullは確認できなかったことを意味します。欠落を信頼する前にdegradedでフィルタリングしてください。失敗のように見える2つのケースは意図的にdegradedとして扱われません。どちらも測定結果だからです。reactors_unavailableはログアウトしたLinkedInの仕組みであり、読み込まれたページのno_posts_foundは実際の欠落です。
収集した投稿ごと、収集したコメント投稿者ごとに課金され、さらに小さなアクター起動料金がかかります。通知行は無料です。posted_sinceは課金前にフィルタリングされるため、新しいものが見つからないスケジュール実行はアクター起動料金のみで、それ以外はかかりません。
結果キャッシュはありません。毎回再取得します。これは新しい投稿を検知するアクターにとって正しい動作です。価格はアクターのApifyページにあります。このサーバーを実行するとApifyクレジットを消費します。
これはApifyアクターのシンクライアントです。入力をそのまま渡し、アクターの出力を変更せずに返します。上記のすべての動作はアクター側にあり、ここにはありません。
ログアウトした訪問者にLinkedInが提供するものだけを読み取ります。セッションCookieを保持せず、LinkedInアカウントも使用せず、ログインの背後にあるものは一切読み取りません。
コメント投稿者の行は実名の人物です。 これを実行する場合、あなたは返される個人データのデータ管理者であり、Apifyは処理者です。法的根拠はあなた自身が確立するものです。ここに法的助言はありません。
このアクターは非公式であり、LinkedInやMicrosoftとの提携、スポンサー、推奨はありません。
エラーは表面化され、決して飲み込まれません。無効な入力、無効なトークン、残高不足、タイムアウト、またはデータセット以外を返す実行はすべて、空の結果ではなく明示的なツールエラーとして返されます。
アクターはApify Storeにあります。このラッパーはMITライセンスです。
Mamba Labsによって構築されました。
Point it at LinkedIn person profiles or company pages and it returns the posts a search engine has indexed for each one, as flat rows: permalink, author, a text excerpt, and the publish date decoded from the post id. No request is sent to LinkedIn and no cookie or account is used. A result counts only when its permalink names the source, so posts are never attributed to the wrong author. Coverage is what the search index holds: posts appear days or weeks after publishing and many never appear. Commenters, reaction counts, comment counts and media are no longer returned (removed 2026-10-12, they came only from LinkedIn pages). Rows carry row_type post or notice; filter on row_type before loading a table. post_id is the activity URN and is stable across runs. Every row carries degraded and degradation_reason. Requires an APIFY_TOKEN and consumes Apify credits. Read only.
| Name | Required | Description | Default |
|---|---|---|---|
| company_urls | No | LinkedIn company page URLs, 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. Leave empty to take everything the index holds. | |
| profile_urls | No | LinkedIn person profile URLs, for example https://www.linkedin.com/in/williamhgates. Country subdomains such as uk.linkedin.com are fine. Supply this, company_urls, or both. | |
| max_charge_usd | No | Optional. The actor's own spend cap for this run, in USD. The run stops before a charge would take its total past this amount, writes one notice row saying so, and keeps every row already charged. Leave it empty for no cap of your own; the maximum cost per run set in Apify is honored either way. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: no request is sent to LinkedIn, no cookie or account is used, results only count when the permalink names the source, coverage is bounded by the search index, and commenters/reactions/media were removed on 2026-10-12. It also discloses the APIFY_TOKEN requirement, credit consumption, degraded/degradation_reason flags, and that post_id is a stable activity URN.
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?
Front-loaded with the core behavior, then layered with caveats, each of which carries real decision value (coverage limits, row_type, removed features, credits). It is long, but nearly every sentence prevents a specific failure mode; only minor tightening is possible.
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?
With no output schema, the description fully describes the return shape (permalink, author, text excerpt, decoded publish date, row_type, post_id, degraded flags). Combined with the cost, auth, and coverage disclosures, an agent has everything needed to invoke and interpret this tool correctly.
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%, so all four parameters (company_urls, profile_urls, posted_since, max_charge_usd) are already fully documented in the schema, including the charge-cap behavior. The description adds no parameter-level detail beyond that, which is the correct baseline when the schema does the heavy lifting.
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?
States a specific verb and resource — it returns search-indexed LinkedIn posts for supplied person profiles or company pages as flat rows — and names the exact fields returned. It also proactively corrects the misleading tool name by stating that commenters are no longer returned. An agent knows precisely what comes back without opening the schema.
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?
Gives concrete operating guidance: filter on row_type before loading a table, use posted_since to avoid charges, and expect posts to appear days or weeks after publishing with many never indexed. There are no sibling tools to route against, so explicit alternatives cannot be named, but the coverage caveats make the appropriate context clear.
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.
v1.4.0capture_linkedin_posts_and_commenters1 field changedInput schema / properties / max_charge_usdAdded value: +{
+ "description": "Optional. The actor's own spend cap for this run, in USD. The run stops before a charge would take its total past this amount, writes one notice row saying so, and keeps every row already charged. Leave it empty for no cap of your own; the maximum cost per run set in Apify is honored either way.",
+ "minimum": 0,
+ "type": "number"
+}v1.3.0capture_linkedin_posts_and_commenters8 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / collect_commentersRemoved value: -{
- "description": "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.",
- "type": "boolean"
-}Input schema / properties / collect_reactorsRemoved value: -{
- "description": "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.",
- "type": "boolean"
-}Input schema / properties / company_urls / descriptionPrevious value: -"LinkedIn company page URLs whose recent posts you want, for example https://www.linkedin.com/company/microsoft. Supply this, profile_urls, or both."New value: +"LinkedIn company page URLs, for example https://www.linkedin.com/company/microsoft. Supply this, profile_urls, or both."Input schema / properties / max_engagers_per_postRemoved value: -{
- "description": "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.",
- "maximum": 100,
- "minimum": 0,
- "type": "integer"
-}Input schema / properties / posted_since / descriptionPrevious value: -"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."New value: +"ISO date or timestamp, for example 2026-08-01. Posts published before this are skipped BEFORE anything is charged. Leave empty to take everything the index holds."Input schema / properties / profile_urls / descriptionPrevious value: -"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."New value: +"LinkedIn person profile URLs, for example https://www.linkedin.com/in/williamhgates. Country subdomains such as uk.linkedin.com are fine. Supply this, company_urls, or both."Input schema / properties / use_residential_proxyRemoved value: -{
- "description": "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.",
- "type": "boolean"
-}v1.0.1capture_linkedin_posts_and_commentersScored across 1 tool
There is only one tool, so there is no possibility of selecting the wrong one. Its purpose (capture indexed LinkedIn posts for given profiles/pages) is stated unambiguously.
The single name uses a clear snake_case verb_noun form, which is internally consistent. However, it still advertises 'commenters' even though the description says commenter data was removed, making the name stale and slightly misleading.
The server exposes exactly one tool for a very narrow, read-only capture operation, so the count is defensible but thin. An agent gets no separate means to list sources, filter row types, or fetch metadata without parsing the single flat output.
For a read-only 'capture posts from a search index' domain, one tool covers the whole lifecycle and returns stable post_id, row_type, and degradation flags. Gaps are minor: no dedicated source-validation or post-filtering operation, and the name's promise of commenters is no longer fulfilled.
Scrape and analyze public LinkedIn posts as structured JSON via the Apify LinkedIn Posts API.
LinkedIn companies, hiring signals and public profiles by URL. No login, no cookies. Pay per result.
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.