Skip to main content
Glama

bluesky-mcp-server

Get Bluesky Author Feed

bsky_get_author_feed
Read-onlyIdempotent

Get a Bluesky user's recent feed ordered newest-first. Every filter includes reposts, so items authored by other accounts appear alongside the actor's own writing — a "repostedBy" field marks those, and the "author" field always names who actually wrote the post. Filter by post type: "posts_with_replies" (everything), "posts_no_replies" (excludes replies), "posts_with_media" (posts with images or links), or "posts_and_author_threads" (posts the author started). Returns posts with full text, engagement counts, embeds, and AT-URIs for drilling into threads via bsky_get_post_thread. Because "limit" counts reposts too, a page from an account that reposts heavily holds far fewer of that account's own posts than the limit suggests; the enrichment fields report the split, so read "originalPosts" rather than the limit when you want the actor's own writing. Supports cursor pagination.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actorYesHandle (e.g. "alice.bsky.social") or DID of the author whose feed to fetch. A bare name without a dot is not a handle — use bsky_search_actors to resolve one.
limitNoMaximum number of posts to return (1–100). Default 25.
cursorNoOpaque pagination cursor from a previous response. Omit for the first page.
filterNoFilter for post types: "posts_no_replies" excludes replies, "posts_with_replies" for everything, "posts_with_media" for posts with images/links, "posts_and_author_threads" for threads the author started. None of these exclude reposts — the AppView offers no repost filter, so check "repostedBy" on each item.posts_no_replies

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe limit applied to this page.
errorNoPresent when the call failed. Absent on success.
postsNoFeed items, newest-first — the actor's own posts and the posts they reposted. Items carrying "repostedBy" were written by the account named in "author", not by the requested actor.
shownNoNumber of posts returned on this page.
cursorNoOpaque cursor for the next page. Absent on the last page.
noticeNoGuidance when the result set is empty or constrained.
repostsNoHow many items on this page are posts the requested actor reposted rather than wrote. Present only when there is at least one; these items carry "repostedBy".
truncatedNoTrue when more posts exist beyond this page (a cursor was returned).
originalPostsNoHow many items on this page the requested actor wrote. Present whenever the page carries at least one repost — the number a caller asking for the actor's own writing is after, since "limit" counts reposts too and no filter excludes them.
totalReturnedNoNumber of posts in this response page.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description carries the full burden of behavioral nuance beyond that. It discloses that all filters include reposts, explains the 'repostedBy' and 'author' fields, warns that 'limit' counts reposts so the returned page may hold fewer original posts than expected, and mentions cursor pagination. This is rich, actionable context that significantly aids invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence carries essential information—behavioral traits, return fields, filter semantics, and a critical caveat about pagination count. It is front-loaded with the core action and logically progresses through details. There is no redundancy, and the structure makes it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 parameters, an enum filter, behaviors around reposts and limit, pagination) and the presence of an output schema, the description covers all necessary context: what is returned, the meaning of key fields, the limitation of filters regarding reposts, and the pointer to bsky_get_post_thread for deeper drilling. Nothing an agent needs to call it correctly is missing.

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 description coverage is 100%, so parameters are already documented. The description adds meaning beyond the schema by clarifying the practical implication of 'limit' (it counts reposts, so use 'originalPosts' from the enrichment fields for the actor's own writing) and by reinforcing that no filter excludes reposts. This elevates the semantics beyond the baseline for full schema coverage.

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?

The opening sentence states a precise verb, resource, and ordering: 'Get a Bluesky user's recent feed ordered newest-first.' It clearly distinguishes itself from siblings by referencing bsky_get_post_thread for thread drilling and by its focus on a single author's feed rather than search or follows. No ambiguity about what the tool does.

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 description explains when to use the tool (fetching a specific author's feed) and implicitly differentiates it from siblings through its focus and the mention of bsky_get_post_thread for threads. It does not explicitly list exclusions or alternative tools for other use cases, but the context is clear enough that an agent can select it appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct resource: feed, follows, thread, profile, trending, actor search, and post search. While bsky_get_author_feed and bsky_search_posts might seem similar, their descriptions clearly separate a user-specific feed from full-text search. The other tools have unambiguous boundaries.

Naming Consistency5/5

All tools follow the same prefix pattern 'bsky_' followed by either 'get_' or 'search_' and a noun. There are no deviations or mixed conventions. The consistent verb+noun structure makes the tool surface predictable and easy to navigate.

Tool Count5/5

Seven tools is well within the ideal range for a focused Bluesky client. Each tool covers a core read operation without redundancy, and none feels extraneous. The count is proportionate to the server's apparent purpose.

Completeness4/5

The server covers the main read workflows: profiles, feeds, search, threads, trending, and social graph edges. Minor gaps exist, such as no direct single-post fetch (only via thread) and no posting capabilities, but these are consistent with a read-only social listening server and do not significantly impede core tasks.