Skip to main content
Glama
Crawlora MCP

Crawlora MCP

Official

bluesky_post_likes

Retrieve accounts that liked a Bluesky post by its at:// URI, with pagination and detailed actor info.

Instructions

List actors who liked a Bluesky post. Lists the accounts that liked a Bluesky post, identified by its at:// post uri, which is required. limit defaults to 25 and is capped at 100; pass the returned cursor back for the next page. Each actor has did, handle, display_name, description, avatar_url and created_at.

Input Schema

NameRequiredDescriptionDefault
uriYesThe post's at:// URI
limitNoPage size, 1-100
cursorNoPagination cursor

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

A3.8/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 it discloses meaningful behavior: pagination via cursor, page-size bounds and default, and the full actor field list returned per item. It does not mention auth or rate-limit behavior, so it falls short of 5, but for a read-only listing it is solid.

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?

Three sentences with the core purpose front-loaded and pagination details following logically. The only waste is the near-verbatim restatement of sentence one ('Lists the accounts that liked a Bluesky post') in sentence two, which adds no new information.

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 3-param read tool with no annotations and no output schema, the description does the work that structured fields cannot: it names the actor fields returned, states the default page size and cap, and explains cursor round-tripping. Only auth/permission expectations are absent.

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 already 100%, so baseline is 3, and the description adds real meaning on top: `limit` defaults to 25 (a default the schema does not state) and `cursor` is the returned value to pass back. It reinforces `uri` as required with the `at://` format. The 1-100 cap roughly duplicates the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'List actors who liked a Bluesky post', so the operation is unambiguous. What keeps it from a 5 is the near-identical sibling bluesky_post_reposted_by, which it never names or contrasts against — an agent must still infer which 'list actors on a post' tool applies.

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

Usage Guidelines3/5

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

It implies usage by stating the `uri` is required and how to paginate, so an agent with a post URI knows it can call this. But there is no when-to-use vs when-not guidance and no reference to the similar repost/quote siblings, leaving selection ambiguous.

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