Retrieves public Facebook Page posts as structured rows, including post date, text, reactions, comments, shares, media type, and link for specified Pages.
Click on "Deploy 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., "@Facebook Posts Scraper MCP Server Get the last 20 posts from the NASA Facebook Page."
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.
An MCP server for the Mamba Labs Facebook Posts Scraper actor on Apify. Public Facebook Page posts as rows.
Related MCP server: facebook-mcp
Takes public Facebook Page names or addresses and returns one row per post with date, text, reactions, comments, shares, media type, and link.
All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.
You need Node.js 18 or newer and an Apify account with an API token.
Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:
{
"mcpServers": {
"mamba-facebook-posts-scraper": {
"command": "npx",
"args": [
"-y",
"@mambalabsdev/mcp-facebook-posts-scraper"
],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Restart the client. The get_facebook_page_posts tool appears.
Node.js 18 or newer.
An Apify API token from console.apify.com/account/integrations, set as APIFY_TOKEN. The server lists its tool without a token; a call needs one.
"Get the last 20 posts from the NASA Facebook Page."
"Get posts since 2026-10-01 from these Facebook Pages."
get_facebook_page_posts. One tool. Example arguments:
{
"pages": [
"NASA"
],
"max_posts_per_page": 5
}Every buyer facing input of the actor. Omitted inputs take the actor's own defaults.
Input | Type | Required | Description |
| array | no | Public Page names or facebook.com addresses, for example NASA. Groups and personal profiles are not read. In Clay, put the column inside a one item list. |
| number | no | Text number from 1 to 500. Default 20. |
| string | no | Optional date like 2026-01-31. Reading stops at the first post older than this. |
| number | no | Optional. The run stops before a charge that would pass this amount. Summary rows are always returned. |
Pay per event on Apify, billed to your Apify account. Prices in USD.
Event | Free plan | Bronze | Silver | Gold |
| $0.0075 | $0.007125 | $0.00675 | $0.006375 |
| $0.003 | $0.003 | $0.003 | $0.003 |
Page status rows and refused input are free. Mamba Labs pays the platform costs of the run, Apify proxy traffic included.
apify.com/mambalabs/facebook-posts-scraper
MIT. See LICENSE.
Get posts from public Facebook Pages. Returns one row per post with date, text, reactions, comments, shares, media type, and link.
| Name | Required | Description | Default |
|---|---|---|---|
| pages | No | Public Page names or facebook.com addresses, for example NASA. Groups and personal profiles are not read. In Clay, put the column inside a one item list. | |
| since_date | No | Optional date like 2026-01-31. Reading stops at the first post older than this. | |
| max_charge_usd | No | Optional. The run stops before a charge that would pass this amount. Summary rows are always returned. | |
| max_posts_per_page | No | Text number from 1 to 500. Default 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety needs no restatement. The description earns credit by disclosing the output shape (one row per post with named fields) in the absence of an output schema. It does not mention rate limits, historical depth limits, or cost behavior (left to the schema's max_charge_usd).
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?
Two sentences, no filler, purpose first and return shape second. Nothing is redundant with the name or title.
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?
For a read-only, zero-required-parameter collection tool with full schema coverage and annotations, the description plus schema cover what an agent needs to call it correctly and interpret results. Minor gaps: no note on pagination/limits or what happens when a Page is unavailable.
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 the descriptions there are strong (date cutoff semantics, charge cap, 1–500 post limit, one-item list convention). The tool description adds no parameter meaning beyond that, so baseline 3 applies.
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 (get posts from public Facebook Pages) and immediately scopes it to public Pages, which distinguishes it from profile/group reading. The second sentence enumerates the returned fields, so an agent knows exactly what data it gets without opening a 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?
Usage is only implied by the word 'public' — the agent can infer this is a read/collection tool with no alternatives to choose from (no siblings). Explicit exclusions (groups and personal profiles not supported) exist only in the schema's 'pages' description, not in the tool description itself.
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.0.1get_facebook_page_postsScored across 1 tool
With only one tool, there is no possibility of selection confusion. The tool's purpose—retrieving posts from a public Facebook Page—is stated clearly and cannot be mistaken for anything else.
The single name get_facebook_page_posts follows a clean verb_noun pattern (get + resource) and is fully descriptive of what it returns. There are no competing conventions to clash with.
One tool is defensible for a narrowly scoped scraper whose only job is fetching page posts, but it is on the thin side—there is no way to fetch post-level detail or paginate through a broader workflow. It sits at the borderline of 'focused' and 'underbuilt'.
The response shape is rich (date, text, reactions, comments, shares, media, link), covering the core read operation. However, there is no visible surface for pagination/date-range control, per-post detail, or bulk retrieval, so agents needing more than a single default fetch will hit a dead end.
Scrape and analyze public LinkedIn posts as structured JSON via the Apify LinkedIn Posts API.
Public Facebook pages and profiles with likes, followers, contact details and posts, as JSON.
Publish and schedule Facebook Page posts from your AI assistant.
Get email, phone, website and Instagram from public Facebook business pages for lead generation
