Loading ToolBench
The Bluesky MCP server has 15 tools with consistent naming conventions (bluesky_* prefix), explicit input schemas with type definitions, and descriptions for all tools. However, critical gaps exist: (1) parameter descriptions are minimal and sometimes missing essential context (e.g., 'actor' in get-followers.ts lacks guidance on whether to pass DID or handle); (2) output schemas are NOT documented anywhere, the code returns generic `{content: [{type: 'text', text: '...'}]}` responses without specifying what data structure clients should expect; (3) error handling is generic and provides no recovery guidance; (4) no pagination hints or result limits documented despite tools like get_timeline and get_followers accepting limit/cursor parameters; (5) descriptions under-explain WHEN to use each tool and its dependencies (e.g., that get_post_thread requires a valid post URI in a specific format). Tool naming is strong (verb_noun pattern, clear intent), and schemas are well-formed JSON Schema objects. But execution and composition guidance are weak, placing this in the C-/D+ range.
Unfollow a user
Delete a like
Delete a post
Delete a repost
Follow a user
Get user's followers
Get user's follows
Output schemas completely undocumented. All tools return generic {content: [{type: 'text', text: '...'}]} responses with no specification of actual returned data structure, field names, or types. LLMs cannot reason about or extract data from responses without documented schemas.
Parameter descriptions are minimal or missing context. 'actor' parameter in get_followers/get_follows/get_profile is described as 'The DID (or handle) of the user...' but lacks guidance on expected format (e.g., is 'jack.bsky.social' valid or must it be a DID 'did:plc:...'?). 'uri' and 'cid' parameters lack explanation of their format or where to obtain them.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get likes for a post
Get a post thread
Get a user's profile
Get user's timeline
Like a post
Post a message
Repost a post
Search posts
No pagination guidance. Tools like get_timeline, get_followers, get_follows, get_likes, search_posts accept 'limit' and 'cursor' parameters but descriptions do not explain: (1) recommended limit values or defaults, (2) how to detect end of results, (3) whether cursor is opaque or has structure, or (4) total record count availability.
Error handling provides no recovery guidance. All tools use generic try-catch with 'Successfully...' text responses. No indication of what could go wrong (invalid URI, user not found, permission denied, rate limit), whether errors are retryable, or what the LLM should do next.
No distinction between read-only and destructive operations in tool metadata. Tools marked as DESTRUCTIVE (delete_*) or WRITE (follow, like, post, repost) do not use toolAnnotations (readOnlyHint/destructiveHint/idempotentHint) to signal intent to clients. This violates current MCP spec (2026-07-28) guidance.
Tool dependencies not documented. For example, bluesky_like requires both 'uri' and 'cid', but the descriptions don't explain how to obtain a valid CID or that both must come from the same post. get_post_thread may call get_likes afterward, but there's no hint that get_likes returns post URIs usable in follow-up calls.
No result limits or truncation guidance. Tools returning lists (get_followers, get_follows, get_likes, get_timeline, search_posts) do not document maximum safe result sizes or whether responses are capped at API limits. An LLM cannot plan pagination strategy without knowing default/max limits.
Inconsistent parameter naming styles. Most tools use camelCase (followUri, likeUri, postUri, subjectDid, parentHeight, algorithm) while the pattern baseline prefers snake_case for MCP tool parameters. This is not critical but reduces consistency.