Skip to main content
Glama

bluesky-mcp-server

Get Bluesky Post Quotes

bsky_get_post_quotes
Read-onlyIdempotent

Read the quote posts behind a Bluesky post's "quoteCount" — the posts that embed it with commentary of their own, newest first. On Bluesky this is where much of the reaction to a post lives; bsky_get_post_thread returns replies only. Accepts the post's AT-URI (at:///app.bsky.feed.post/) from the "uri" field of any returned post, or its bsky.app URL (https://bsky.app/profile//post/); a handle costs one extra lookup. Returns each quote post with full text, author, engagement counts, and AT-URI. Each result's embed names the queried post by AT-URI and CID only — its text is not repeated on every result — and keeps any media the quoting post attached. "quoteCount" is an upper bound on what this returns: Bluesky's counter keeps quotes that have left the index. Supports cursor pagination.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
uriYesThe post whose quotes to read — its AT-URI, e.g. "at://did:plc:z72i7hdynmk6r22z27h6tvur/app.bsky.feed.post/3l6oveex3ii2l", or its bsky.app URL, e.g. "https://bsky.app/profile/bsky.app/post/3l6oveex3ii2l"; a trailing "/", "?…", or "#…" on the URL is ignored. Posts only — a feed, profile, or list address is rejected.
limitNoMaximum number of quote posts to return (1–100). Default 25. Pages often hold fewer than the limit and still continue — follow the cursor, not the count. A page that would pass the 48,000-byte response budget comes back with fewer quotes and "budgetCapped: true"; its cursor continues from the first quote it left out.
cursorNoOpaque pagination cursor from a previous response for the same post, passed back unchanged. Omit for the first page.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe limit applied to this page.
uriNoAT-URI of the post whose quotes these are, in DID form — the form Bluesky was asked in, whatever form the input took.
errorNoPresent when the call failed. Absent on success.
postsNoPosts quoting the queried post, newest first.
shownNoNumber of quote posts returned on this page.
cursorNoOpaque cursor for the next page. Absent when there are no more quotes.
noticeNoGuidance on the page: that more quotes can be fetched with the returned cursor, or why the page is empty — the post has no readable quotes, or the last page was reached.
truncatedNoTrue when Bluesky returned a cursor, whatever this page held — pages often come back short of the limit with more behind them.
budgetCappedNoTrue when a page of the requested limit would have passed this server's 48,000-byte response budget, so Bluesky was asked again for fewer quotes and that page was returned whole. The cursor comes from that same response, so paging on from it skips nothing. Independent of "truncated", which still means only that a cursor was returned.
totalReturnedNoNumber of quote posts in this response page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum number of quote posts to return (1–100). Default 25. Pages often hold fewer than the limit and still continue — follow the cursor, not the count."New value: +"Maximum number of quote posts to return (1–100). Default 25. Pages often hold fewer than the limit and still continue — follow the cursor, not the count. A page that would pass the 48,000-byte response budget comes back with fewer quotes and \"budgetCapped: true\"; its cursor continues from the first quote it left out."
    • addedOutput schema / properties / budgetCapped
      Added value: +{
      +  "description": "True when a page of the requested limit would have passed this server's 48,000-byte response budget, so Bluesky was asked again for fewer quotes and that page was returned whole. The cursor comes from that same response, so paging on from it skips nothing. Independent of \"truncated\", which still means only that a cursor was returned.",
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / posts / items / properties / author / properties / verification
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Bluesky verification of the author — what tells a verified account from a look-alike handle. Absent when Bluesky sent none. Who issued it is on bsky_get_profile.",
      +  "properties": {
      +    "trustedVerifierStatus": {
      +      "description": "Whether the author is itself a trusted verifier — same values as verifiedStatus.",
      +      "type": "string"
      +    },
      +    "verifiedStatus": {
      +      "description": "Whether a trusted verifier verified the author: \"valid\", \"invalid\" (verified once, no longer holds), or \"none\". Passed through as Bluesky sends it, so another value may appear.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "verifiedStatus",
      +    "trustedVerifierStatus"
      +  ],
      +  "type": "object"
      +}
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

The description adds substantial behavioral detail beyond the annotations: newest-first ordering, the extra lookup cost for handles, the embed representation of the queried post, and the caveat that quoteCount is an upper bound because the counter retains quotes that left the index. It also confirms pagination support and clarifies what each result contains.

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 dense but every sentence earns its place: purpose, sibling contrast, input formats, output shape, caveats, and pagination are all covered. It is front-loaded with the core definition and flows logically through usage details.

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 read-only, idempotent annotations, the rich schema, and the presence of an output schema, the description is complete. It covers input alternatives, output contents, pagination, a meaningful data-integrity caveat, and a handle-lookup cost — nothing an agent needs to invoke 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 coverage is 100% and the schema descriptions are already detailed, so the baseline is 3. The description adds extra meaning by explaining where to obtain the AT-URI ('from the "uri" field of any returned post') and noting that a handle costs one extra lookup, which goes beyond the schema's syntax-only guidance.

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 description states a precise verb and resource: 'Read the quote posts behind a Bluesky post's quoteCount.' It clearly distinguishes this from replies by explicitly noting that bsky_get_post_thread returns replies only, so an agent can identify the tool's scope without ambiguity.

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

Usage Guidelines5/5

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

It gives explicit context for when to use this tool ('where much of the reaction to a post lives') and names the alternative for replies ('bsky_get_post_thread returns replies only'). This effectively routes an agent to the correct sibling tool based on the desired interaction type.

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.