Bluesky Posts Scraper MCP Server

Get Bluesky posts

get_bluesky_posts

Read-onlyIdempotent

Search public Bluesky posts by keyword, read an account's posts, or fetch a post with its replies. Returns exact engagement counts, dates, hashtags, links, and images without login.

Instructions

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.

Input Schema

Name	Required	Description
`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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.1Nov 9, 2026

TDQS

A4.3/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server

Other Tools

get_bluesky_postsA