Provides tools for scraping Bluesky public posts and replies. It can search posts by keyword or retrieve posts from accounts and post URLs, filter by date, language, and sort order, and return post data such as exact counts, dates, hashtags, links, images, and replies.
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., "@Bluesky Posts Scraper MCP Server What are people saying on Bluesky about AI this month? Include like counts"
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 Bluesky Posts Scraper actor on Apify. Bluesky posts by keyword or account, and replies by post.
Related MCP server: AT Protocol MCP Server
Give keywords, accounts, or post addresses. The actor reads Bluesky's public API with no login and no key, and returns one row per post or reply with exact counts, dates, hashtags, links, and images. A free status row per source says what it returned or why it stopped.
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-bluesky-posts-scraper": {
"command": "npx",
"args": [
"-y",
"@mambalabsdev/mcp-bluesky-posts-scraper"
],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Restart the client. The get_bluesky_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.
"What are people saying on Bluesky about cold email this month?"
"Get the last 50 posts from this Bluesky account with their like counts."
"Read the replies on this Bluesky post into a table."
get_bluesky_posts. One tool. Example arguments:
{
"queries": [
"apify"
],
"max_posts_per_source": 10
}Every buyer facing input of the actor. Omitted inputs take the actor's own defaults.
Input | Type | Required | Description |
| array | no | Keywords to search, up to 20. Without your own app password each search returns one page, about 100 posts. Text from Clay splits on new lines, so a query can hold a comma. |
| array | no | Bluesky handles, profile addresses, or DIDs, up to 20. Returns each account's own posts, newest first. |
| array | no | Addresses of Bluesky posts to read, up to 100. |
| string | no | latest or top. Default latest. Used for queries. |
| string | no | Only posts from this date, such as 2026-10-01. |
| string | no | Only posts before this date, such as 2026-11-01. |
| string | no | Language code such as en or de. Used for queries. Reads the language the post's author set. |
| number | no | Per query or account, up to 2000. Default 100. A search with no app password stops at about 100. |
| boolean | no | yes or no. Default no. Reads the replies under each post found. Each reply is a charged row. |
| number | no | Up to 200. Default 20. |
| boolean | no | yes or no. Default no. Used for accounts. |
| boolean | no | yes or no. Default no. Used for accounts. A repost row shows the original author. |
| string | no | Optional, with the app password. Used only to page a search past its first page. |
| string | no | Optional. Create an app password in Bluesky settings; never use your main password. Sent only to Bluesky. Without it a search returns one page, about 100 posts. Accounts and post addresses need no password. |
| string | 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.0011 | $0.001045 | $0.00099 | $0.000935 |
| $0.0065 | $0.0065 | $0.0065 | $0.0065 |
Source status rows and refused input are free. Mamba Labs pays the platform costs of the run. Mamba Labs pays the platform costs of the run, Apify proxy traffic included.
apify.com/mambalabs/bluesky-posts-scraper
MIT. See LICENSE.
Search public Bluesky posts by keyword, read an account's posts, or read a post and its replies. Returns exact like, reply, repost, and quote counts, dates, hashtags, links, and images. No login. Pay per event on Apify.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | latest or top. Default latest. Used for queries. | |
| authors | No | Bluesky handles, profile addresses, or DIDs, up to 20. Returns each account's own posts, newest first. | |
| queries | No | Keywords to search, up to 20. Without your own app password each search returns one page, about 100 posts. Text from Clay splits on new lines, so a query can hold a comma. | |
| language | No | Language code such as en or de. Used for queries. Reads the language the post's author set. | |
| post_urls | No | Addresses of Bluesky posts to read, up to 100. | |
| since_date | No | Only posts from this date, such as 2026-10-01. | |
| until_date | No | Only posts before this date, such as 2026-11-01. | |
| bluesky_handle | No | Optional, with the app password. Used only to page a search past its first page. | |
| max_charge_usd | No | Optional. The run stops before a charge that would pass this amount. Summary rows are always returned. | |
| include_replies | No | yes or no. Default no. Reads the replies under each post found. Each reply is a charged row. | |
| include_reposts | No | yes or no. Default no. Used for accounts. A repost row shows the original author. | |
| bluesky_app_password | No | Optional. Create an app password in Bluesky settings; never use your main password. Sent only to Bluesky. Without it a search returns one page, about 100 posts. Accounts and post addresses need no password. | |
| max_posts_per_source | No | Per query or account, up to 2000. Default 100. A search with no app password stops at about 100. | |
| max_replies_per_post | No | Up to 200. Default 20. | |
| include_account_replies | No | yes or no. Default no. Used for accounts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered by structured data. The description adds genuinely new operational context: no login required and Apify per-event pricing, which the agent needs to reason about cost and auth. It does not mention search pagination limits, but the schema covers that.
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?
Four short, front-loaded sentences: modes first, then returned fields, then auth, then pricing. Every sentence carries information and nothing is repeated from the schema. Minor terseness in fragments like 'No login. Pay per event on Apify.' but no wasted wording.
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 15 parameters and no output schema, the description does the right work: it names the return fields (like/reply/repost/quote counts, dates, hashtags, links, images) so the agent knows what comes back, and it flags the no-login and pay-per-event constraints. The app-password gating of multi-page search is left to the schema, which is a small omission but not a blocking one.
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 coverage is 100% with 15 richly documented optional parameters, so the baseline is 3. The description earns an extra point by framing the three modes, which helps the agent decide between the otherwise indistinguishable queries, authors, and post_urls inputs.
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 ('Search public Bluesky posts') and enumerates the three distinct operating modes: keyword search, account timeline, and single post plus replies. An agent immediately knows the tool's scope 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?
The three modes are clear use contexts and implicitly map to the queries / authors / post_urls parameters, giving the agent a routing decision. It does not explicitly say which parameter triggers which mode, and there are no sibling tools to differentiate against, so no exclusion guidance is needed.
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_bluesky_postsScored across 1 tool
Only one tool exists, so there is nothing to confuse it with. The description clearly defines its three modes: keyword search, account feed reading, and post plus replies retrieval.
get_bluesky_posts follows a clear verb_noun convention and is readable, though 'get' combined with a plural noun covers multiple read modes, which is slightly imprecise but harmless for a single tool.
A single tool that multiplexes three distinct operations—search, account timeline, and thread reading—is too thin for the stated purpose. Separate tools per mode would make the surface clearer.
Reading posts, replies, and search are covered, which matches the scraper's read-only domain, so no create/update/delete gap applies. However, no paging or filtering controls are exposed, and bundling three operations into one tool leaves notable gaps in usability.
Scrape Bluesky posts, profiles, followers, threads and keyword search. Clean JSON, pay per result.
Scrape and analyze public LinkedIn posts as structured JSON via the Apify LinkedIn Posts API.
Bluesky post search, author feeds, profiles & threads
Monitor Bluesky for new brand mentions, keywords and account posts. Alerts only on new results.