bluesky-mcp-server

Get Bluesky Post Interactions

bsky_get_post_interactions

Read-onlyIdempotent

List the accounts behind a post’s likes or reposts without credentials, in provider order. Accepts a post AT-URI or bsky.app post URL; a handle authority costs one extra resolution request. Returns actor summaries with account creation and label provenance when supplied, and a separate likedAt timestamp for likes. Account counts and website are available through bsky_get_profile. Post likeCount and repostCount are upper bounds on retrievable interactions: cursor exhaustion does not prove every counted interaction was returned. Follow returned cursors with the same post and kind; no pages are walked automatically. Repost cursors retain Bluesky’s behavior, which can ignore malformed cursors and repeat a page.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "uri": "<uri>",
      "kind": "<kind>"
    },
    "name": "bsky_get_post_interactions"
  }
}

Input Schema

Name	Required	Description
`uri`	Yes	Post AT-URI or https://bsky.app/profile/<handle-or-did>/post/<rkey> URL. URL trailing slash, query, and fragment are accepted. Feed, profile, and list references are rejected.
`kind`	Yes	Interaction to list: likes includes likedAt; reposts has no interaction timestamp.
`limit`	No	Maximum accounts per page, default 25. Values above 100 are clamped with a notice unless read-limit clamping is disabled.
`cursor`	No	Opaque cursor from the previous response for the same post and kind. Pass unchanged; omit for the first page.

Output Schema

Name	Required	Description
`cap`	No	Applied page limit when a continuation cursor is present.
`uri`	No	DID-form AT-URI of the queried post.
`kind`	No	Interaction whose accounts are returned.
`error`	No	Present when the call failed. Absent on success.
`shown`	No	Accounts shown on a page with a continuation cursor.
`actors`	No	Accounts in provider order.
`cursor`	No	Opaque continuation cursor. Absence ends traversal, without proving every counted interaction was returned.
`notice`	No	Pagination, empty-page, clamping, and counter-completeness guidance.
`truncated`	No	True exactly when Bluesky returned a cursor, regardless of page size.
`totalReturned`	No	Accounts returned on this page.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover readOnly/idempotent/openWorld, yet the description adds substantial operational context: no credentials required, provider ordering, an extra resolution request for handle authorities, clamping notices above 100, and no automatic pagination. It also discloses the crucial caveat that likeCount/repostCount are upper bounds and that repost cursors can ignore malformed input and repeat a page.

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?

Front-loaded with purpose and format acceptance, then caveats and cursor rules, with no filler sentences. It is dense and long-ish, but every clause carries consequential information; slight readability cost from packing many caveats into two blocks.

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?

Despite an output schema existing, the description covers the operational gaps that matter for a paginated, somewhat quirky endpoint: cursor semantics, per-kind timestamp differences, upper-bound counts, and malformed-cursor behavior. Nothing an agent needs to call this correctly and interpret results 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 baseline is 3, but the description earns extra credit by adding meaning the schema does not: handle-based URIs cost one extra resolution request, and cursor behavior differs per kind. It does not add anything for limit beyond what the schema's clamping note already says.

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?

Opens with a specific verb and resource: 'List the accounts behind a post's likes or reposts,' with the credentials and ordering scope stated up front. It is unmistakable against siblings like bsky_get_post_quotes, bsky_get_post_thread, and bsky_get_profile.

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?

Gives concrete context for when this tool is right (listing interaction accounts) and explicitly redirects to bsky_get_profile for counts and website. It also prescribes cursor continuation etiquette (same post and kind, no auto-walk). What it lacks is an explicit statement of when NOT to use it, e.g. for quote posts, which live in the sibling bsky_get_post_quotes.

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 tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.