Bluesky Social MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific Bluesky operations like posting, following, or fetching feeds, with clear boundaries. However, send_post, send_image, send_images, and send_video overlap in posting functionality, which could cause confusion about when to use each, though their descriptions clarify media-specific roles.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern, such as get_post, like_post, and delete_post. This uniformity makes the tool set predictable and easy to navigate, with no deviations in naming style across the 25 tools.
Tool Count3/5
With 25 tools, the count is borderline high for a social media server, as it may feel heavy and complex for agents to manage. While it covers many Bluesky features, a more streamlined set could improve usability without sacrificing functionality.
Completeness5/5
The tool set provides comprehensive coverage of Bluesky's core operations, including CRUD for posts (create, get, delete), social interactions (follow/unfollow, like/unlike, mute/unmute), and data retrieval (feeds, profiles, likes, reposts). No obvious gaps exist for typical agent workflows in this domain.
Average 3.2/5 across 25 of 25 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action 'follow a user' but doesn't disclose behavioral traits such as authentication requirements, rate limits, whether it's idempotent, what happens if the user doesn't exist, or if there are privacy restrictions. The description is minimal and lacks critical operational context.
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 brief and structured with sections for Args and Returns, making it easy to scan. However, the 'ctx' parameter in Args is unnecessary clutter since it's an MCP implementation detail not relevant to the agent. Overall, it's efficient but could be more focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with no annotations and no output schema), the description is incomplete. It doesn't explain the return value ('Status of the follow operation') in detail, such as success indicators or error conditions. For a tool that modifies user relationships, more context on behavior and outcomes is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that lists 'handle' as the parameter, adding meaning beyond the input schema (which has 0% description coverage). However, it doesn't explain what a 'handle' is (e.g., username, ID, format) or provide examples. With 1 parameter and low schema coverage, this adds some value but is insufficient for full clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'follow' and resource 'user', which provides a basic purpose. However, it doesn't distinguish this tool from sibling tools like 'get_follows' or 'unfollow_user' beyond the obvious action difference, nor does it specify what platform or system this applies to. The purpose is clear but lacks differentiation from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication status), exclusions (e.g., cannot follow oneself), or compare it to siblings like 'get_follows' (for checking follows) or 'unfollow_user' (for reversing the action). Usage is implied by the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action but doesn't mention required permissions, whether the operation is idempotent, rate limits, or what the 'Status of the like operation' entails. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, but includes redundant sections ('Args:', 'Returns:') that add little value without elaboration. While concise, it under-specifies critical details, making it less helpful than a slightly longer but informative description would be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on authentication needs, error conditions, return values, and parameter semantics, leaving significant gaps for the agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists parameters (uri, cid) but provides no semantic context—what these identifiers represent, their format, or how they relate to the post. Without this, the agent cannot understand parameter meaning beyond the schema's basic types.
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 clearly states the action ('Like a post') with a specific verb and resource, making the purpose immediately understandable. However, it doesn't explicitly differentiate from the sibling 'unlike_post' tool, which would require mentioning the opposite action for full distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'unlike_post' or 'get_likes'. There's no mention of prerequisites (e.g., authentication status), context for usage, or exclusions, leaving the agent without operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions pagination ('cursor') and filtering options, but doesn't describe important traits like rate limits, authentication requirements, error conditions, or whether this is a read-only operation. For a feed-fetching tool with 5 parameters, this leaves significant gaps in understanding how it behaves.
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 well-structured with clear sections (purpose, Args, Returns) and uses only essential sentences. The front-loaded purpose statement is immediately followed by parameter details. While efficient, the 'Args' section could be more integrated with the main description rather than appearing as a separate documentation block.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no annotations and no output schema, the description provides basic purpose and parameter listing but lacks important context. It doesn't explain the return format beyond 'Feed with posts,' doesn't mention authentication requirements, and doesn't differentiate from sibling tools. The parameter explanations are too brief to fully understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that lists all 5 parameters with brief explanations, providing semantic meaning beyond the 0% schema description coverage. However, the explanations are minimal ('Handle or DID of the user', 'Optional filter for post types') and don't elaborate on format, constraints, or examples. This partially compensates for the schema gap but doesn't fully document parameter behavior.
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 clearly states the tool's purpose: 'Get posts from a specific user.' It specifies the verb ('Get') and resource ('posts from a specific user'), making it immediately understandable. However, it doesn't explicitly differentiate from siblings like 'get_posts' or 'get_timeline' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'get_posts' (which might get posts more broadly) or 'get_timeline' (which might show a chronological feed). There's no context about prerequisites, authentication needs, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that if 'handle' is None, it gets the authenticated user's followers, which adds some context. However, it lacks critical details: it doesn't specify authentication needs (implied but not stated), rate limits, pagination behavior beyond the cursor parameter, or what the returned list structure looks like. For a tool with no annotation coverage, this is a significant gap.
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 well-structured and front-loaded with the core purpose, followed by clear sections for Args and Returns. Each sentence adds value without redundancy. It could be slightly more concise by integrating the default behavior into the main description, but overall it's efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description does a fair job: it covers the tool's purpose and parameters adequately. However, it lacks details on authentication requirements, error handling, and the structure of returned data (beyond 'List of follower accounts'), which are important for a social media API tool. It's minimally viable but has clear gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for all three parameters: 'handle' (optional, defaults to authenticated user), 'limit' (range 1-100), and 'cursor' (pagination). This goes beyond the schema's basic titles. However, it doesn't explain parameter interactions or provide examples, leaving some ambiguity (e.g., how 'handle' interacts with authentication).
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 clearly states the tool's purpose: 'Get users who follow an account.' It specifies the verb ('Get') and resource ('users who follow an account'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_follows' (which might get accounts that a user follows rather than followers of an account), leaving room for potential confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_follows' or 'get_profile' that might retrieve related data, nor does it specify prerequisites such as authentication requirements or context for when fetching followers is appropriate. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral information. It mentions it returns 'The requested post' but doesn't describe error conditions, authentication requirements, rate limits, or what happens when parameters don't match. For a read operation with no annotation coverage, this leaves significant behavioral gaps.
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 well-structured with clear sections (Args, Returns) and front-loads the core purpose. However, the 'ctx: MCP context' in Args is unnecessary clutter since MCP context is implicit in all tools, and the Returns section could be more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain error cases, authentication requirements, or what the return structure looks like. The parameter documentation helps but doesn't compensate for the lack of behavioral and output information needed for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides parameter documentation in the Args section, explaining post_rkey as 'The record key of the post', profile_identify as 'Handle or DID of the post author', and cid as 'Optional CID of the post'. With 0% schema description coverage, this adds meaningful semantic context beyond the bare schema, though it doesn't fully explain parameter relationships or constraints.
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 clearly states the tool's purpose with 'Get a specific post' - a specific verb (Get) and resource (post). It distinguishes from siblings like get_posts (plural) and get_post_thread by focusing on a single post. However, it doesn't explicitly mention how it differs from get_author_feed or get_timeline which might also retrieve posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like get_posts, get_post_thread, get_author_feed, and get_timeline that all retrieve post data, there's no indication of when this single-post retrieval is preferred over batch retrieval or thread context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves posts by URIs but lacks behavioral details such as error handling (e.g., invalid URIs), rate limits, authentication requirements, or whether it's read-only. The mention of 'ctx: MCP context' is vague and adds little value.
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 front-loaded with the core purpose, followed by structured sections for args and returns. It's efficient with minimal waste, though the 'ctx' parameter could be omitted or better explained to improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, the description is moderately complete. It covers the basic operation and parameters but lacks details on behavior, error cases, and output structure. For a tool with 1 parameter and many siblings, it should provide more context to guide usage effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It documents the 'uris' parameter as a list of post URIs to retrieve, which adds meaning beyond the schema's basic type definition. However, it doesn't specify URI format, constraints, or examples, leaving gaps in understanding.
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 clearly states the tool's purpose with a specific verb ('Get') and resource ('posts'), specifying retrieval by URIs. It distinguishes from siblings like 'get_post' (singular) and 'get_author_feed' (by author), but could be more explicit about how it differs from 'get_post_thread' or 'get_timeline'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'get_post' (for single posts) or 'get_author_feed' (for posts by author). The description implies usage for multiple URIs, but lacks context on prerequisites, limitations, or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a thread but doesn't describe what 'full' means (e.g., pagination, rate limits, error handling, or authentication requirements). For a read operation with no annotation coverage, this is a significant gap in transparency about how the tool behaves in practice.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by structured sections for Args and Returns. Each sentence earns its place by defining parameters and output, though the 'ctx' parameter is unexplained and could be trimmed for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no annotations, no output schema), the description is incomplete. It lacks details on authentication, error cases, return format (beyond 'Thread'), and how depth/parent_height interact. For a tool that retrieves nested data, more context is needed to use it effectively without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists all parameters (uri, depth, parent_height) and provides brief explanations (e.g., 'How many levels of replies to include' for depth), adding meaning beyond the bare schema. However, it doesn't clarify units (e.g., depth in levels vs. count), default behaviors, or constraints, leaving some ambiguity.
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 clearly states the tool's purpose: 'Get a full conversation thread.' This specifies the verb ('Get') and resource ('conversation thread'), distinguishing it from siblings like get_post (single post) or get_timeline (timeline feed). However, it doesn't explicitly differentiate from get_author_feed or get_posts which might also return threads, making it slightly less specific than ideal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose get_post_thread over get_post (for a single post) or get_author_feed (for a user's posts), nor does it specify prerequisites like authentication or context for thread retrieval. This leaves the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool 'reposts' content, implying a write/mutation operation, but doesn't specify permissions needed, whether this creates notifications, rate limits, or what happens if the same post is reposted multiple times. The return value description ('Status of the repost operation') is vague.
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 efficiently structured with a clear purpose statement followed by parameter and return sections. However, the 'ctx: MCP context' parameter documentation adds no value since this is standard boilerplate, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and 2 parameters at 0% schema coverage, the description is insufficient. It doesn't explain authentication requirements, error conditions, what the 'status' return contains, or how this operation affects the social graph compared to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists both parameters (uri and cid) and indicates they're for 'the post to repost,' providing basic semantic context. However, it doesn't explain what format these identifiers should be in, whether they're interchangeable, or if both are always required together.
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 clearly states the verb ('repost') and resource ('another user's post'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'unrepost' or explain how this differs from simply sharing content through other means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'send_post' (for original posts) or 'unrepost' (to undo). The description only states what the tool does, not when it's appropriate or what prerequisites might exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool resolves a handle to DID information but lacks behavioral details: it doesn't specify error handling (e.g., invalid handles), rate limits, authentication requirements, or what 'DID information' includes (e.g., format, additional metadata). This is a significant gap for a tool with no annotation coverage.
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 appropriately sized and front-loaded, with the core purpose stated first. The Args and Returns sections are structured but slightly verbose for a single parameter; the example is helpful but could be integrated more seamlessly. Overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (resolving identifiers in a social media context), no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on authentication, error cases, return format, and how it fits among sibling tools (e.g., vs. 'get_profile'). The agent would need to guess or test to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds value by explaining the 'handle' parameter as a 'User handle to resolve' with an example ('user.bsky.social'), which clarifies semantics beyond the schema's basic string type. However, it doesn't cover constraints (e.g., format rules) or other potential parameters, leaving some gaps.
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 clearly states the verb 'resolve' and the resource 'handle to a DID', making the purpose understandable. It distinguishes from siblings by focusing on handle resolution rather than social media actions like posting or following. However, it doesn't explicitly differentiate from potential similar tools like 'get_profile' which might also handle user identification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication status), compare to sibling tools like 'get_profile' that might retrieve similar information, or specify use cases (e.g., converting handles for API calls). The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a deletion operation ('delete' in the args explanation) and returns a status, but lacks critical behavioral details: whether this requires authentication, if it's reversible, what happens to related data, rate limits, or error conditions. For a mutation tool with zero annotation coverage, this is insufficient.
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 appropriately sized and front-loaded with the core purpose first. The Args and Returns sections add structure, though 'ctx: MCP context' is redundant boilerplate. Every sentence serves a purpose, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain the return value format (what 'Status' entails), error handling, side effects, or dependencies. For a tool that modifies user relationships, more context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'follow_uri' as 'URI of the follow record to delete', adding meaning beyond the schema's generic 'Follow Uri' title. However, it doesn't clarify the URI format, how to obtain it, or examples. With one parameter and some added context, this meets the baseline for minimal compensation.
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 clearly states the verb ('Unfollow') and resource ('a user'), making the purpose immediately understandable. It distinguishes from siblings like 'mute_user' or 'unmute_user' by focusing on the follow relationship. However, it doesn't explicitly differentiate from 'delete_post' or other deletion operations beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., must be following the user first), when-not scenarios, or how it differs from similar tools like 'unmute_user' or 'delete_post'. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It mentions the operation returns a 'Status' but doesn't specify what that entails (e.g., success/failure indicators, error conditions, or side effects like notifications). For a mutation tool, this is inadequate.
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 appropriately brief and front-loaded with the core purpose. The Args/Returns sections are structured but could be more integrated; however, every sentence contributes without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a mutation tool with behavioral implications, the description is incomplete. It lacks details on permissions, error handling, return values, and how it interacts with sibling tools like 'get_likes' or 'like_post'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It documents the 'like_uri' parameter but only states it's the 'URI of the like' without explaining format, source, or how to obtain it. This adds some meaning but doesn't fully address the coverage gap.
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 clearly states the action ('Unlike') and target ('a previously liked post'), providing specific verb+resource. However, it doesn't explicitly differentiate from sibling tools like 'unrepost' or 'delete_post', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., the post must be currently liked) or contrast with similar tools like 'delete_post' or 'unrepost'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral insight. It mentions a 'Status' return but doesn't detail what that entails (e.g., success/failure, error conditions). It lacks information on permissions required, side effects (e.g., does muting affect notifications?), or reversibility, which is critical for a mutation tool.
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 front-loaded with the core purpose ('Mute a user.'), followed by structured sections for Args and Returns. It avoids unnecessary verbosity, though the 'ctx' parameter in Args is redundant for the agent and could be omitted for better clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain the return value 'Status' in detail, potential errors, or the operational impact of muting. Given the complexity of user management actions, more context on behavior and outcomes is needed for safe and effective use.
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?
The description adds meaningful context for the single parameter 'actor', specifying it as a 'Handle or DID of the user to mute', which clarifies the expected format beyond the schema's generic 'string' type. With 0% schema description coverage and only one parameter, this adequately compensates, though it could note if 'actor' must be a valid, existing user.
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 clearly states the action ('Mute') and target ('a user'), making the purpose immediately understandable. However, it doesn't differentiate from its sibling 'unmute_user' beyond the obvious directionality, nor does it specify what 'mute' entails in this context (e.g., hiding posts, preventing interactions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'unfollow_user' or 'block_user' (if available), nor does it mention prerequisites such as authentication status. The presence of 'unmute_user' as a sibling implies a toggle relationship, but this isn't explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions pagination via 'cursor' and a 'limit' parameter, which is helpful. However, it doesn't address important behavioral aspects like rate limits, authentication requirements, error conditions, or whether this is a read-only operation (though 'get' implies it).
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 well-structured with clear sections (Args, Returns) and front-loads the core purpose. Each sentence earns its place, though the 'ctx' parameter explanation could be more specific about its role. The structure is efficient but not perfectly minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations and no output schema, the description covers parameters well but lacks behavioral context. It explains what the tool returns ('List of likes for the post') but doesn't describe the response format, error handling, or authentication requirements. Given the complexity and lack of structured data, it's adequate but has clear gaps.
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?
With 0% schema description coverage, the description compensates well by explaining all 4 parameters in the Args section. It clarifies that 'uri' is required, 'cid' is optional, 'limit' has a range (1-100), and 'cursor' enables pagination. This adds significant value beyond the bare 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 clearly states 'Get likes for a post' which is a specific verb+resource combination. It distinguishes this tool from siblings like 'get_post' or 'get_reposted_by' by focusing specifically on likes. However, it doesn't explicitly contrast with similar tools like 'get_reposted_by' which might have overlapping use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of when this tool is appropriate compared to other data retrieval tools in the sibling list like 'get_post' or 'get_reposted_by', nor any context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a post-creation tool ('Send a post'), implying a write/mutation operation, but doesn't mention authentication requirements, rate limits, error conditions, or what 'Status of the post creation' actually means. The description lacks crucial behavioral context for a mutation tool.
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 well-structured with clear sections (purpose, Args, Returns) and front-loaded the core functionality. Every sentence earns its place, though the 'Args:' section could be slightly more concise. The structure efficiently communicates the tool's capabilities without unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters, no annotations, and no output schema, the description provides good parameter documentation but lacks critical behavioral context. It doesn't explain authentication needs, error handling, rate limits, or what the return value contains. The parameter coverage is strong, but the overall context for a post-creation tool remains incomplete.
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?
The description provides excellent parameter semantics through the 'Args:' section, which documents all 7 parameters with clear explanations. Since schema description coverage is 0%, this comprehensive parameter documentation fully compensates for the schema's lack of descriptions. Each parameter's purpose is clearly explained, adding significant value beyond the bare 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 clearly states the tool's purpose: 'Send a post with a single image.' It specifies the verb ('send') and resource ('post with a single image'), making it distinct from sibling tools like 'send_post' (text-only) and 'send_images' (multiple images). However, it doesn't explicitly differentiate from 'send_video' or other media-sending tools beyond the single-image focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'send_image' over 'send_post' (text-only), 'send_images' (multiple images), or 'send_video'. There's no discussion of prerequisites, constraints, or typical use cases beyond the basic functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a post (implying a write/mutation operation) but doesn't cover critical aspects like required permissions, rate limits, error conditions, or what 'Status of the post creation' entails. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 well-structured with clear sections (Args, Returns) and uses bullet-like formatting for parameters. It's appropriately sized—each sentence adds value without redundancy. Minor improvements could include front-loading more critical context about the tool's behavior or sibling differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, mutation operation) and lack of annotations/output schema, the description is moderately complete. It covers parameters adequately but lacks behavioral context, usage guidelines, and output details. For a post-creation tool in a social media context, more information about authentication, error handling, or response structure would enhance completeness.
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?
The description provides a comprehensive list of all 7 parameters with brief explanations (e.g., 'Base64-encoded video data', 'Optional alternative text description for the video'). Since schema description coverage is 0%, this compensates well by adding meaning beyond the bare schema. However, some parameters like 'facets' and 'reply_to' could benefit from more detailed examples or formatting guidance.
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 clearly states the tool's purpose: 'Send a post with a video.' It specifies the verb ('send') and resource ('post with a video'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'send_post' or 'send_image', which would require more specific context about when to use video vs. other media types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'send_post' or 'send_image'. It doesn't mention prerequisites (e.g., authentication status), use cases, or exclusions. The agent must infer usage from the tool name alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the operation type ('unmute') but doesn't mention permission requirements, whether this is reversible, rate limits, or what specific 'Status' information is returned. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
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 efficiently structured with a clear purpose statement followed by Args and Returns sections. Every sentence serves a purpose, though the 'ctx' parameter documentation is redundant since it's not in the actual input schema. The formatting is clean and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations, no output schema, and minimal behavioral disclosure, the description is incomplete. It doesn't explain what 'Status' means in the return, what errors might occur, or the broader implications of unmuting a user. The description should provide more context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal parameter semantics beyond the schema. It explains that 'actor' is the 'Handle or DID of the user to unmute', which provides some context about expected values. However, with 0% schema description coverage and only one parameter, this explanation is adequate but basic, meeting the baseline for minimal parameter documentation.
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 clearly states the action ('Unmute') and target ('a previously muted user'), making the purpose immediately understandable. It distinguishes from sibling tools like 'mute_user' by specifying the opposite operation. However, it doesn't explicitly mention what platform or system this applies to, which prevents a perfect score.
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?
The description implies usage context by stating 'previously muted user', suggesting this tool should be used to reverse a mute operation. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'unfollow_user' or any prerequisites (e.g., authentication status). The context is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions pagination via 'cursor' and result limiting via 'limit', which is helpful, but doesn't cover important aspects like authentication requirements, rate limits, error conditions, or what constitutes 'your home timeline' (e.g., authenticated user's timeline). The return format is minimally described as 'Timeline feed with posts' without detail.
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 efficiently structured with a clear purpose statement followed by organized sections for Args and Returns. Every sentence earns its place, with no redundant information. The formatting makes it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, the description provides basic but incomplete coverage. It explains parameters well and states the return type, but lacks details about authentication, error handling, rate limits, and the structure of the returned feed. Given the complexity of timeline operations, more behavioral context would be beneficial.
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?
The description explicitly lists all three parameters with brief explanations, adding meaningful context beyond the schema's 0% description coverage. It clarifies that 'algorithm' is optional and for timeline selection, 'cursor' is for pagination, and 'limit' controls maximum results. This adequately compensates for the schema's lack of parameter descriptions.
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 clearly states the action ('Get posts') and resource ('from your home timeline'), making the purpose immediately understandable. It distinguishes this from siblings like get_author_feed or get_post by specifying the home timeline context, though it doesn't explicitly contrast with all similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_author_feed, get_posts, or get_post_thread. It mentions 'your home timeline' which implies personal content, but offers no explicit when/when-not instructions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that it returns a 'List of followed accounts' and includes pagination via 'cursor', but it doesn't specify authentication requirements, rate limits, error conditions, or what happens if the handle doesn't exist. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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 well-structured and front-loaded with the purpose, followed by clear sections for Args and Returns. Every sentence adds value without redundancy, making it efficient and easy to parse. The bullet-point-like format enhances readability without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and parameters but lacks details on authentication, error handling, and output structure (e.g., what fields are in the returned list). Without annotations or an output schema, more context would be helpful for reliable use.
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?
The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'handle' is optional and defaults to the authenticated user, 'limit' has a range (1-100), and 'cursor' is for pagination. This compensates well for the schema's lack of descriptions, though it doesn't detail the format of 'handle' or 'cursor' values.
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 clearly states the tool's purpose: 'Get users followed by an account.' It specifies the verb ('Get') and resource ('users followed by an account'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_followers' (which gets followers rather than follows), though the distinction is implied by the name.
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?
The description provides some usage context by noting that if 'handle' is None, it gets follows for the authenticated user, which implies when to use this parameter. However, it doesn't offer explicit guidance on when to choose this tool over alternatives like 'get_followers' or 'get_profile', nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the authenticated user fallback, which is useful, but doesn't cover other important aspects like authentication requirements, rate limits, error conditions, or what 'Profile data' includes. For a read operation with zero annotation coverage, this leaves significant gaps.
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 efficiently structured with a clear purpose statement followed by Args and Returns sections. Every sentence adds value without redundancy, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single optional parameter, read operation), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and parameter behavior but lacks details on authentication, error handling, and the structure of returned 'Profile data', which would be helpful for an AI agent.
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?
The description adds meaningful context for the single parameter ('handle') by explaining its optional nature and the behavior when it's None (gets authenticated user's profile). With 0% schema description coverage and only one parameter, this adequately compensates, though it could specify what format the handle should be in.
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 clearly states the tool's purpose with a specific verb ('Get') and resource ('user profile'), making it immediately understandable. However, it doesn't explicitly differentiate this from sibling tools like 'resolve_handle' or 'check_auth_status', which might also retrieve user-related information.
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?
The description provides implied usage guidance by explaining that if no handle is provided, it gets the authenticated user's profile. However, it doesn't explicitly state when to use this tool versus alternatives like 'resolve_handle' or 'get_followers', nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions pagination via 'cursor' and a 'limit' range (1-100), which adds some context, but fails to describe authentication needs, rate limits, error conditions, or what the returned user list structure looks like. For a read operation with zero annotation coverage, this leaves significant behavioral gaps.
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 appropriately sized and front-loaded, with the core purpose stated first followed by structured parameter and return sections. Every sentence adds value, though the 'Args' and 'Returns' headers are slightly redundant given the schema context, keeping it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is partially complete. It covers parameters well but lacks output details, error handling, and behavioral context like authentication or rate limits. It's adequate as a minimum viable description but has clear gaps for a read operation in a social media context.
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?
The description adds substantial meaning beyond the input schema, which has 0% description coverage. It explains that 'uri' is for the post to get reposts for, 'cid' is optional and not strictly required, 'limit' has a range (1-100) and default behavior, and 'cursor' enables pagination. This compensates well for the schema's lack of descriptions, though it doesn't detail parameter formats or interactions.
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 clearly states the tool's purpose with a specific verb ('Get') and resource ('users who reposted a post'), distinguishing it from siblings like get_likes, get_followers, or get_post which target different resources. The opening sentence directly answers what the tool does 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_likes or get_post_thread, nor does it mention prerequisites or contextual constraints. While the purpose is clear, usage guidance is absent, leaving the agent to infer when this specific retrieval is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool removes a repost, implying a destructive mutation, but doesn't specify whether this requires specific permissions, what happens if the repost doesn't exist, or any rate limits. The description is minimal and doesn't add rich behavioral context beyond the basic action, leaving significant gaps for an agent to understand operational risks.
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 highly concise and well-structured: a clear purpose statement followed by brief sections for Args and Returns. Every sentence earns its place by directly contributing to understanding the tool's function, parameters, and output without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a destructive operation with one parameter), no annotations, and no output schema, the description is minimally adequate. It covers the basic action and parameter but lacks details on behavioral traits, error handling, or return value specifics. It meets the minimum viable threshold but has clear gaps that could hinder an agent's effective use.
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?
The description adds meaningful semantics for the single parameter 'repost_uri' by specifying it's 'URI of the repost to remove,' clarifying its purpose beyond the schema's generic 'Repost Uri' title. With 0% schema description coverage, this compensates well by providing essential context. However, it doesn't detail the URI format or examples, preventing a perfect score.
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 clearly states the tool's purpose with a specific verb ('Remove') and resource ('a repost of another user's post'), making it immediately understandable. It distinguishes from siblings like 'delete_post' by specifying it's for removing reposts rather than original posts. However, it doesn't explicitly contrast with 'unlike_post' or other undo operations, keeping it from a perfect score.
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?
The description implies usage context by specifying it's for 'a repost of another user's post,' suggesting it should be used when undoing a repost action. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'delete_post' (for original posts) or mention prerequisites such as authentication status. The context is clear but lacks explicit when-not-to-use statements or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the action ('send a post') and image limits, but fails to disclose critical behavioral traits: whether this is a write operation (implied but not stated), authentication requirements, rate limits, error conditions, or what 'Status of the post creation' entails. The description is insufficient for a mutation tool with zero annotation coverage.
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 well-structured with a clear purpose statement followed by organized parameter and return value sections. It's appropriately sized for a tool with 7 parameters, though some sentences could be more concise (e.g., 'Returns: Status of the post creation' is vague).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, mutation operation) with no annotations and no output schema, the description is incomplete. While parameter semantics are well-covered, it lacks crucial behavioral context (authentication, side effects, error handling) and the return value description is too vague ('Status of the post creation'). For a mutation tool with this complexity, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides comprehensive parameter semantics beyond the input schema, which has 0% description coverage. Each parameter is clearly explained with its purpose and constraints (e.g., 'images_data: List of base64-encoded image data (max 4)', 'facets: Optional list of facets (mentions, links, etc.)'). This fully compensates for the schema's lack of descriptions.
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 clearly states the tool's purpose: 'Send a post with multiple images (up to 4).' This specifies the verb ('send'), resource ('post'), and a key constraint ('multiple images up to 4'), distinguishing it from sibling tools like 'send_post' (text-only) and 'send_image' (single image).
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?
The description implies usage context through parameter descriptions (e.g., 'reply_to' for replying, 'profile_identify' for author specification), but lacks explicit guidance on when to use this tool versus alternatives like 'send_post' or 'send_image'. No when-not-to-use scenarios or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it states the action ('Send a post') and return value, it doesn't mention authentication requirements, rate limits, error conditions, or whether this is a destructive operation. For a write tool with zero annotation coverage, this leaves significant behavioral gaps.
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 well-structured with clear sections for Args and Returns. Each sentence earns its place by explaining parameter semantics. While efficient, it could be slightly more front-loaded by stating the core purpose more prominently before diving into parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with 6 parameters and no annotations or output schema, the description does well on parameters but lacks critical behavioral context. It explains what the tool does and its parameters but doesn't cover authentication, error handling, or operational constraints that would be essential for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing clear semantic explanations for all 6 parameters. Each parameter gets a meaningful description that explains its purpose, optionality, and default behavior (e.g., 'If not provided, sends to current profile', 'defaults to ['en']'), adding substantial value beyond the bare schema.
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 clearly states the specific action ('Send a post to Bluesky') and resource ('post'), distinguishing it from sibling tools like 'send_image', 'send_video', or 'repost'. It explicitly identifies the core function 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating posts on Bluesky but provides no explicit guidance on when to use this versus alternatives like 'send_image' or 'repost'. It mentions optional parameters but doesn't explain scenarios where they're appropriate or when other tools might be better suited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly identifies this as a destructive operation ('Delete') and specifies the authentication context ('by the authenticated user'), which are crucial behavioral traits. However, it doesn't mention potential side effects (e.g., removing associated likes/reposts), error conditions, or whether the operation is reversible.
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 appropriately sized with a clear purpose statement followed by structured Args and Returns sections. While efficient, the 'ctx: MCP context' parameter documentation adds minimal value since it's boilerplate for MCP tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description provides adequate basics (purpose, authentication context, parameter meaning) but lacks important details about return values (what 'Status' means), error handling, and operational constraints. Given the tool's complexity, more completeness would be beneficial.
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?
With 0% schema description coverage and only one parameter, the description adds meaningful context by explaining that 'uri' refers to 'URI of the post to delete'. This clarifies the parameter's purpose beyond what the bare schema provides, though it doesn't specify the URI format or provide examples.
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 clearly states the specific action ('Delete') and resource ('a post created by the authenticated user'), distinguishing it from sibling tools like 'get_post' or 'like_post'. It explicitly identifies the target resource scope (user's own posts) and the destructive nature of the operation.
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 provides clear context about when to use this tool ('Delete a post created by the authenticated user'), establishing the prerequisite of ownership. However, it doesn't explicitly mention when NOT to use it (e.g., for posts by other users) or name alternative tools for related operations like 'unlike_post' or 'unrepost'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively explains that authentication is automatic via environment variables, lists the required and optional variables, and mentions the return value (authentication status). However, it lacks details on error handling or specific status formats, leaving some behavioral aspects unclear.
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 front-loaded with the core purpose in the first sentence, followed by necessary details about authentication and returns. Each sentence adds essential information without redundancy, making it efficient and well-structured for quick understanding.
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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is largely complete, covering purpose, usage, and behavioral context. However, it could be more detailed on the return format (e.g., what 'Authentication status' entails) to fully compensate for the lack of output schema, leaving minor gaps.
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?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description adds value by explaining the authentication mechanism (environment variables) and the return type, which goes beyond the empty input schema, making it more informative for users.
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 clearly states the specific verb ('Check') and resource ('if the current session is authenticated'), distinguishing it from all sibling tools which perform actions like deleting posts, following users, or retrieving content. It precisely defines what the tool does without being vague or tautological.
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 provides clear context for when to use this tool (to verify authentication status) and implies prerequisites (environment variables must be set), but it does not explicitly state when not to use it or name alternatives. This makes it helpful but not fully comprehensive for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bluesky-social-mcp MCP server](https://glama.ai/mcp/servers/gwbischof/bluesky-social-mcp/badges/card.svg)](https://glama.ai/mcp/servers/gwbischof/bluesky-social-mcp)

Score Badge

Copy to your README.md:

[![bluesky-social-mcp MCP server](https://glama.ai/mcp/servers/gwbischof/bluesky-social-mcp/badges/score.svg)](https://glama.ai/mcp/servers/gwbischof/bluesky-social-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gwbischof/bluesky-social-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server