Skip to main content
Glama

bluesky-mcp-server

by io.github.cyanheads

Get Bluesky Post Thread

bsky_get_post_thread
Read-onlyIdempotent

Fetch the conversation for a post by AT-URI — the parent chain upward and the reply tree downward. Enter the thread at any point and traverse the discussion. AT-URIs have the format "at:////" and are returned by bsky_search_posts and bsky_get_author_feed in the "uri" field of each post. Returns the root post, parent chain, and nested replies with per-post author and engagement data. The response is often a fraction of the conversation: Bluesky holds replies back past a per-post limit and offers no way to page the rest, so a thread with thousands of replies commonly returns a few hundred. Any node returning fewer replies than its own replyCount carries "truncated: true" with "unreturnedReplies" and a "truncationReason" — "depth" means the reply tree ended there and fetching that node's AT-URI as its own thread continues below it, "unavailable" means no request closes the gap. Read "unreturnedReplies" as an upper bound on what is missing rather than a count of readable replies: Bluesky's counter also includes replies that have left the index, so a small difference often means nothing is left to fetch. The parent chain is disclosed the same way: when it stops at parent_height instead of at the start of the conversation, the topmost node carries "parentChainTruncated: true" and fetching its AT-URI as its own thread continues upward. The enrichment fields total the difference for the whole thread; check them before describing a conversation as complete or naming its first post. In the rendered text nothing is indented: a reply's author heading carries how far it sits below the top-level reply it descends from ("### ↳2"), and every post also names its own parent on a "Reply to" line.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uriYesAT-URI of the post to fetch, e.g. "at://did:plc:z72i7hdynmk6r22z27h6tvur/app.bsky.feed.post/abc123". All three segments are required — authority (handle or DID), collection, and record key. Obtain from bsky_search_posts or bsky_get_author_feed.
depthNoHow many levels of replies to include below the target post. Default 6, maximum 10 — Bluesky itself returns no more than 10 levels however deep the request. Depth does not widen the reply tree either: the per-post reply limit is independent of it. To read below the deepest level returned, fetch an edge node's AT-URI as its own thread.
parent_heightNoHow many parent posts to include in the parent chain above the target post. Default 80, maximum 100. The chain is returned level for level up to this many posts and stops early at the conversation root. When it stops at this bound instead, the topmost node carries "parentChainTruncated: true" — fetch that node's AT-URI as its own thread to read above it. Set to 0 to skip the chain entirely; a reply target then reports the same marker on itself, since its own parent was not returned either.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNoWhat this response is missing, how much of the gap is explained, and which part of it can still be reached by a further request.
threadNoThe conversation thread rooted at the requested post — a recursive node tree. Each node has: post: { uri, cid, text, author: { did, handle, displayName?, avatar? }, replyCount?, repostCount?, likeCount?, quoteCount?, indexedAt?, createdAt?, labels?: [{ val, src?, cts? }], embed?, replyToUri?, replyRootUri? }. parent?: parent thread node. replies?: array of child thread nodes. truncated?: true when the node's own post.replyCount exceeds the replies returned for it, with unreturnedReplies: the size of that difference, and truncationReason: "depth" (the reply tree ends at this node — fetch its post.uri as its own thread to continue below it) or "unavailable" (no request closes the gap). unreturnedReplies is an upper bound on what is missing, not a count of readable replies: Bluesky's counter keeps including replies that have left the index, so a node reporting one unreturned reply often has none left to fetch. Only reply-tree nodes carry these; a parent-chain node is linear by construction and never reports a reply shortfall. parentChainTruncated?: true on the topmost node above the target when the chain stopped at parent_height rather than at the start of the conversation — that node is a reply to a post this response does not contain, so it is not the conversation root. Fetch that node's post.uri as its own thread to continue upward; parent_height is honored level for level, so the ancestors above it are one request away. Set on the target itself when no parent was returned at all. notFound?: true when the post was deleted or never existed. blocked?: true when its author blocks this view. Both stubs carry the reported AT-URI on post.uri and no content — a blocked node also carries the author DID on post.author.did.
truncatedNoTrue when at least one post in the reply tree returned fewer replies than Bluesky counts for it.
threadgateNoThe thread author's reply restrictions, present only when they set one. Hidden replies are counted in replyCount whether or not they were returned, so a gated thread is one reason the counts run ahead of the tree.
totalReturnedNoThread nodes in this response — the target post, its parent chain, and every reply returned.
unreturnedRepliesNoHow far the reply counts run ahead of the replies returned, summed across the reply tree. An upper bound on what is missing, not a count of readable replies — Bluesky's counters keep including replies that have left the index. Compare against the root post replyCount to judge how much of the conversation is present.
parentChainTruncatedNoTrue when the parent chain stopped at parent_height instead of reaching the start of the conversation, so the topmost post returned above the target is not the conversation root. Independent of "truncated", which covers the reply tree, and unlike it fully recoverable: fetch the topmost parent's AT-URI as its own thread to continue upward.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description is fully consistent with all three. Beyond that it discloses substantial non-obvious behavior the annotations cannot express: per-post reply limits with 'truncated: true', the two 'truncationReason' values (depth/unavailable) and their differing implications, 'unreturnedReplies' as an upper bound rather than an exact missing count, 'parentChainTruncated' semantics, and the author-heading indentation convention. This far exceeds what structured fields provide. No contradiction with annotations.

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?

The description is long and dense with well over ten sentences, which risks over-specification—but nearly every sentence earns its place by explaining genuinely non-obvious truncation and continuation semantics that no schema field could convey. The purpose is front-loaded in the first sentence, and the rest flows logically from thread structure to truncation markers to counter-semantics caveats to formatting. It is verbose yet information-dense; only the redundancy around continuation ('fetch its AT-URI as its own thread' appears several times) prevents a 5.

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 output schema exists (so return-value details needn't be restated) and the high complexity of this tool—asymmetric truncation, parent-chain cutoffs, counter semantics, hidden indentation—the description is remarkably complete for correct invocation and interpretation. It covers tool selection, parameter provenance, truncation detection, continuation strategy, the caveat about unreturnedReplies being an upper bound, and even the rendering convention for reply depth. Nothing an agent needs to call and interpret this tool 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 coverage is 100%, so the schema already documents all three parameters (uri, depth, parent_height) in depth—this sets the baseline at 3. But the description adds genuine value beyond the schema by explaining how depth and parent_height interact with truncation: depth does not widen the reply tree, the per-post reply limit is independent of depth, and the continuation strategy is a consequence of these bounds. It explicitly names how to obtain the uri ('returned by bsky_search_posts and bsky_get_author_feed'), which is not in the schema. This compensates beyond baseline.

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 is a specific verb+resource—'Fetch the conversation for a post by AT-URI'—with an immediate scope statement (parent chain upward, reply tree downward) that distinguishes it from siblings. It also explicitly ties the AT-URI source to bsky_search_posts and bsky_get_author_feed, making the separation from those siblings explicit. No ambiguity about what this 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 gives clear, actionable guidance: enter at any thread point, and readers can traverse deeper by fetching an edge node's AT-URI as its own thread when truncation markers appear. It also names the sibling sources of the AT-URI parameter. It stops short of an explicit 'when NOT to use this vs. bsky_search_posts' contrast, but the traversal and continuation instructions are concrete and well-motivated, which earns it above the 3-level implied-usage baseline.

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

All bluesky-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources