Skip to main content
Glama
paulet4a-commits

webdatatools-social-mcp

by paulet4a-commits
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

bluesky_scraper

Extract Bluesky posts, profiles, followers, follows, and thread replies via public API; search posts with query/date/sort filters and get one row per item.

Instructions

Bluesky Post, Search & Profile Scraper returns post text, engagement counts, images, profile bios, followers, follows and thread replies from Bluesky's public API — one row per item, no login required. Billed to your own Apify account: ~$0.0005 per post (Apify free-plan price, lower on paid plans).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYesMode — Choose what to scrape. "posts" reads a user's own posts, "search" finds posts matching a query (requires an app password below — Bluesky's public search API needs a signed-in session), "profile"/"followers"/"follows" read account data, and "thread" reads one post and its replies. Options: posts = User's posts; search = Search posts; profile = Profile; followers = Followers; follows = Follows; thread = Thread. Example: "posts".
sortNoSort order — Choose how search results are ordered: "latest" (newest first) or "top" (most engagement first). Used by the "search" mode only. Options: latest = Latest; top = Top.latest
sinceNoSince (ISO date) — Enter an ISO 8601 date/time to only return posts created on or after it, e.g. 2026-01-01. Leave blank for no lower bound. Used by the "search" mode only.
untilNoUntil (ISO date) — Enter an ISO 8601 date/time to only return posts created before it, e.g. 2026-06-01. Leave blank for no upper bound. Used by the "search" mode only.
handlesNoHandles, DIDs or profile URLs — Enter one or more Bluesky handles, DIDs or bsky.app profile URLs, e.g. bsky.app, did:plc:z72i7hdynmk6r22z27h6tvur or https://bsky.app/profile/jay.bsky.team. Used by the "posts", "profile", "followers" and "follows" modes. Example: ["bsky.app"].
postUrlNoPost URL — Enter one post's bsky.app URL (e.g. https://bsky.app/profile/bsky.app/post/3l6oveex3ii2l) or its at:// URI. Used by the "thread" mode only, to fetch that post and its replies. Example: "https://bsky.app/profile/bsky.app/post/3l6oveex3ii2l".
maxItemsNoMax items — Enter the maximum number of rows to return per handle or per search query, e.g. 100. Raise this for bulk exports; lower it to keep runs quick.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose two important traits: no authentication needed for scraping, and real billing on the user's own Apify account at ~$0.0005 per post. It also clarifies output cardinality ('one row per item'). It stops short of rate limits, pagination, or failure behavior, so not a 5.

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?

Two sentences, front-loaded with the capability and output scope, followed by the cost model. Dense but every clause earns its place; slightly run-on rather than wasteful.

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?

For a 7-parameter, mode-driven scraper with no output schema and no annotations, the description adequately conveys what comes back and what it costs. Mode-specific behavior and the search-mode credential requirement are left entirely to the schema, which keeps it just short of complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter including the mode enum is already documented in the schema. The description adds only the aggregate field list, not syntax, defaults, or the app-password caveat for search mode, so this is the baseline 3.

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?

Names a specific verb (scrape) and resource (Bluesky posts, search, profiles) and enumerates the returned fields: post text, engagement counts, images, bios, followers, follows, thread replies. It is instantly distinguishable from every sibling, which are YouTube, Podcast, Telegram, Substack and Google scrapers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states no when-to-use conditions, no alternatives, and no mode-selection guidance — the actual routing logic (which mode needs handles vs postUrl) lives only in the schema. The 'no login required' note is a constraint, not usage context.

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