Bluesky MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools target distinct resources and actions, but a few pairs like get-post-likes vs. get-liked-posts or get-user-posts vs. get-timeline-posts could cause confusion. Descriptions largely clarify these differences, making the set mostly unambiguous.
Naming Consistency5/5
All tool names follow a consistent hyphenated verb-noun pattern (e.g., get-profile, create-post, unfollow-user), making the set predictable and easy to navigate. No mixed conventions or vague verbs are present.
Tool Count2/5
With 32 tools, the server exceeds the 25+ threshold for too many tools. While the broad scope of Bluesky interactions justifies many operations, the count feels heavy and several retrieval tools could potentially be consolidated.
Completeness3/5
Core social interactions are covered (posts, follows, likes, lists, DMs), but notable gaps exist: no post deletion, no profile editing, and no block/mute functionality. These omissions could hinder common workflows.
Average 3.5/5 across 32 of 32 tools scored.
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 status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action ('Get a user's profile') but does not mention return format, authentication needs, rate limits, or error conditions. This is minimal but not misleading.
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 a single concise sentence that is front-loaded with the action and resource. It is appropriately sized for a simple tool with one parameter, and every word is useful. There is no wasted or redundant text.
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 straightforward getter with one parameter and no output schema, the description is minimally viable. It tells the user what the tool does, and the schema documents the parameter. However, it lacks detail about what exactly is included in the profile and when to prefer this over sibling tools, leaving some gaps.
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 schema description for 'handle' is clear and complete, covering 100% of parameters. The description adds no additional parameter meaning, but the baseline for high schema coverage is 3, and the schema already provides sufficient semantics.
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') and the resource ('user's profile') with a specified context ('from Bluesky'). It is unambiguous and distinct from siblings like get-my-handle-and-did or search-people, though it does not explicitly call out those alternatives.
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. It does not mention that it is preferred for fetching a specific profile by handle, nor does it exclude use cases like searching for people. The description offers no selection 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 responsibility. It only says 'fetch posts' without explicitly stating read-only behavior, permission requirements, rate limits, or output format. The verb 'fetch' implies a read, but this is not fully disclosed.
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 a single, concise sentence with no unnecessary words. While it is very brief, it is not overly verbose. However, it lacks any structured sections or additional context that might be expected for a tool with three required parameters.
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 no annotations and no output schema, the description is too sparse. It does not explain the 'type' parameter (posts vs hours), which is critical to understanding count semantics, nor does it clarify output or handle resolution (handle vs DID). This leaves significant gaps for an agent to reason about correct 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?
Schema coverage is 100%, with each parameter (user, count, type) having a descriptive definition. The tool description adds no additional parameter context beyond the schema, so the baseline of 3 applies.
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 'Fetch posts from a specific user' clearly identifies the action (fetch), resource (posts), and scope (specific user). It distinguishes this tool from siblings like get-timeline-posts or get-feed-posts by emphasizing the 'specific user' target.
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?
There is no guidance on when to use this tool versus alternatives such as get-feed-posts, get-list-posts, or search-posts. No prerequisites, exclusions, or alternative recommendations are provided.
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 responsibility for disclosing behavioral traits. It only states the action without mentioning that the post becomes publicly visible, requires authentication, or has any side effects. There is no information about rate limits, error behavior, or the fact that it is a write operation.
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 a single, clear sentence with no filler or redundancy. It is appropriately sized for the tool's simplicity and front-loads the core purpose.
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?
The tool is a write operation with no output schema and no annotations. The description is minimal and fails to include important context such as how to construct a reply (via replyTo), expected response, or any prerequisites. Given the availability of sibling tools like 'convert-url-to-uri' and 'get-post-thread', this description leaves gaps for an agent to correctly invoke the tool in all scenarios.
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 input schema has 100% coverage with descriptions for both parameters ('text' and 'replyTo'). The description adds no additional meaning beyond the schema, but schema ambiguity is minimal. Baseline 3 is appropriate given full schema coverage.
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 function with a specific verb ('Create') and resource ('a new post on Bluesky'). This distinguishes it from sibling tools like 'repost' or 'like-post', which have different actions.
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. It does not mention that it should be used for original posts, or that to reply to an existing post, the replyTo parameter should be populated with a URI. There is no explicit context or exclusion.
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 responsibility for behavioral disclosure. It only says 'fetch posts' and omits details such as pagination, sorting, rate limits, or return format. The read-only nature is implied but not explicitly stated.
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 a single, clear, front-loaded sentence with no wasted words. It is appropriately sized for the simple operation.
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?
Although the schema fully documents parameters, the lack of an output schema means the description should clarify what the tool returns. The description is too terse and does not mention response structure, which could leave an agent uncertain about expected output.
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 input schema provides descriptions for all three parameters (feed, type, count) with full coverage. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
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 fetches posts from a specified feed, using a specific verb and resource. It distinguishes from sibling tools like get-user-posts or get-liked-posts by identifying the feed as the source.
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 such as get-timeline-posts or get-list-posts. The description only states the basic function without any context 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, the description carries the full burden of behavioral disclosure. It implies a read-only operation but doesn't explicitly state safety, authentication requirements beyond 'authenticated user', rate limits, or side effects. Minimal context beyond the action itself.
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 a single concise sentence with no wasted words. It is front-loaded and efficiently communicates the core action and resource.
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 zero-parameter read tool, the description is adequate but incomplete. There is no output schema, so the description should explain what the response contains, but it only says 'pinned feeds and lists' without defining their structure or scope. An agent would need to infer the return shape.
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 zero parameters, so the baseline is 4. The description doesn't need to explain parameter behavior because none exist, and the schema confirms no inputs are required.
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') and resource ('the authenticated user's pinned feeds and lists'), which is specific and unambiguous. However, it doesn't explicitly distinguish this from sibling tools like get-lists or search-feeds, though 'pinned' provides some implicit 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?
No guidance is provided on when to use this tool versus alternatives. There is no context about typical use cases, prerequisites, or exclusions, so an agent gets no help in deciding between this and similar feed/list 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?
With no annotations provided, the description must disclose behavioral context. It only says 'Get current trending topics' without noting whether the tool is read-only, whether authentication is required, what the response format looks like, or any rate-limit considerations. This is minimal behavioral disclosure beyond the basic verb.
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 a single, concise sentence that conveys the core purpose without waste. However, it is extremely terse, bordering on under-specification for a tool with two parameters and no annotations.
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 simple query tool, the description plus complete parameter schema provide a basic understanding, but the lack of an output schema and any behavioral notes leaves some gaps. The description does not explain what 'trending topics' includes or how includeSuggested modifies the result.
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 input schema fully describes both parameters (limit, includeSuggested) with ranges and defaults, so the description does not need to add parameter details. However, the description also does not add any extra meaning or context about how these parameters affect results.
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 action ('Get'), the resource ('current trending topics'), and the platform ('Bluesky'). It distinguishes from sibling tools like get-timeline-posts and search-posts by specifying trends specifically.
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 or when to prefer an alternative. It does not mention any distinguishing use cases, exclusions, or relationships to sibling tools like search-posts or get-feed-posts.
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 for behavioral disclosure. It only states the action without mentioning side effects (e.g., creating a public repost record), authentication needs, rate limits, or reversibility. This is insufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It conveys the essential purpose immediately and is appropriately sized for a tool with one parameter.
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 absence of annotations and output schema, the description should provide more context about invocation behavior, such as what the response contains or any side effects. The description only states the purpose, leaving critical behavioral aspects unspecified.
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 input schema describes the parameter 'uri' as 'The AT URI of the post to repost', which is complete and unambiguous. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
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 action ('Repost') and the resource ('a post on Bluesky'), using the clarifying synonym '(retweet)' to remove ambiguity. It distinguishes itself from sibling tools like like-post and create-post by the specific verb and object.
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 repost versus alternatives like like-post or create-post. The description does not mention any contextual triggers, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and target, with no mention of read-only behavior, pagination, rate limits, authentication requirements, or what a 'custom feed' entails. This is a significant gap for a search operation.
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 a single concise sentence that directly states the tool's purpose without redundancy. It is front-loaded and contains no filler, earning a high score for 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?
With no output schema, no annotations, and simple parameters, the description should compensate by explaining expected results or limitations. It does not mention return format, feed selection criteria, or any constraints beyond what the schema provides, leaving the tool poorly contextualized.
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 100% as both 'query' and 'limit' have descriptions. The tool description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate.
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 'Search for custom feeds on Bluesky' clearly states the action (search) and the target resource (custom feeds), distinguishing it from sibling tools like search-posts and search-people. It lacks extra specificity about feed attributes but is unambiguous enough to identify the tool's core purpose.
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 this tool should be used when searching for feeds specifically, given the resource is 'custom feeds'. However, it provides no explicit when-to-use guidance or alternatives, leaving the agent to infer based on sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 only states the action without any details about side effects, success/failure conditions, rate limits, or error handling. This is a mutation tool, yet nothing is disclosed about what happens after the send or whether it creates a new conversation.
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 a single, front-loaded sentence with no extraneous words. It uses the standard verb-object structure and is highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter send operation with no output schema, the description is largely sufficient. The main gap is the lack of behavioral context (e.g., error cases), but given the low complexity and full parameter coverage, this is a minor omission.
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?
All parameters are fully described in the schema (100% coverage), so the baseline is 3. The description adds no extra meaning beyond the schema's own field descriptions, but it doesn't need to since the schema already documents handle and text clearly.
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 uses a specific verb ('Send') and resource ('a direct message to a user on Bluesky'), clearly distinguishing it from sibling tools like get-conversations and get-dm-messages which are read-oriented. It unambiguously states what the tool does.
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. For instance, it doesn't mention that this is the only tool for sending DMs, nor does it explain any prerequisites such as the user needing to have DMs open. The context is implied by the tool's name, but there is no explicit 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and does not mention auth requirements, idempotency, error behavior, or side effects, similar to a minimal mutation description.
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 a single concise sentence, front-loaded with the action, and contains no filler or unnecessary detail.
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?
The tool is simple with two well-documented parameters and no output schema, so the description is minimally adequate for invocation. However, it lacks behavioral context and usage prerequisites, making it not fully complete.
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 input schema already provides 100% coverage for both parameters (handle and listUri) with clear descriptions. The description adds no additional parameter semantics, so the baseline score of 3 applies.
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 verb 'Add' and the resource 'a user to a Bluesky list'. It is specific enough to distinguish this from sibling tools such as remove-from-list and create-list.
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 explicit when-to-use guidance or alternatives. Usage context is only implied by the tool name and description, with no mention of prerequisites or when not to use it.
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?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It implies a read operation ('Get') but does not mention pagination behavior (e.g., limit cap of 500), return format, sorting, rate limits, or authentication needs. This lack of context leaves important operational details undisclosed.
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 a single, direct sentence with no filler words. It front-loads the verb and resource, making it immediately scannable. It is appropriately concise for a simple tool, though minimal in content.
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 simplicity (2 params, no output schema, no annotations), the description covers the core purpose but omits useful contextual details like pagination handling (limit caps at 500), the structure of returned user objects, and guidance on when to use this tool over get-follows. It is a minimum viable descriptor with clear gaps.
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 input schema already provides complete descriptions for both parameters (user and limit) with 100% coverage. The tool description adds no parameter-specific semantics beyond what the schema offers, so the baseline score of 3 is appropriate.
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 uses a specific verb 'Get' and clearly identifies the resource as 'list of users that follow a person,' which unambiguously distinguishes it from the sibling tool get-follows (which would list who a person follows). This is a clear, specific statement of purpose.
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. It does not mention that get-follows is the counterpart for 'following' lists, nor any exclusions or preferred contexts. The description states only the action, leaving the agent to 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 the full burden of behavioral disclosure. It only states the basic purpose and does not mention pagination, the default/maximum limit of 500, authentication requirements, rate limits, or the structure of the returned user objects. While it is a read-only operation, the description lacks depth expected for a complete behavioral picture.
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 a single, concise sentence that immediately states the tool's purpose. It avoids unnecessary words or repetition, and every word contributes to clarity. This is an example of efficient, front-loaded writing.
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?
The tool is simple with only two parameters and no output schema, but the description is minimal. It lacks any mention of return value details (e.g., what fields are included in each user object), how pagination works, or the distinction from 'get-followers'. While the core purpose is clear, the lack of behavioral context and sibling differentiation leaves gaps.
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 input schema already provides full descriptions for both parameters: 'user' (handle or DID) and 'limit' (1-500 with default 500). Schema description coverage is 100%, so the description does not need to add parameter details. The description adds no extra meaning beyond the schema, but the baseline of 3 is appropriate since the schema is comprehensive.
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 function: 'Get a list of users that a person follows.' It uses a specific verb ('Get') and resource ('list of users'), and the phrase 'that a person follows' distinguishes it from the sibling tool 'get-followers' (which would return users who follow a person). This is a precise and unambiguous purpose statement.
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, and notably fails to differentiate it from 'get-followers'. There is no mention of context, prerequisites, or exclusions. The only implicit signal is the word 'follows' in the description, which a user might infer as directionality, but there is no explicit guidance.
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 must fully disclose behavioral implications. It states only the action ('Like a post') without mentioning side effects, idempotency, permissions, or return behavior. For a mutation tool, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single five-word sentence, front-loaded and free of any filler. Every word earns its place, making it maximally concise.
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?
The tool is simple with one parameter and no output schema, so minimal description is acceptable. However, it does not explain return values, failure modes, or whether the like is reversible, leaving some ambiguity for a complete 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?
Schema description coverage is 100% and the sole parameter 'uri' is already described in the schema as 'The URI of the post to like'. The tool description adds no additional meaning or syntax details, so the baseline of 3 applies.
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 'Like a post on Bluesky' uses a specific verb and resource, clearly distinguishing this tool from siblings like 'repost' and 'create-post'. It fully conveys the tool's purpose.
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 'repost' or 'create-post'. There is no mention of prerequisites, context, or exclusions, leaving usage entirely to inference.
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 must carry the full burden. It only states the removal action without disclosing side effects, error behavior, or permission requirements. This is minimal beyond the tool name.
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?
A single, direct sentence with no superfluous words. It is front-loaded with the verb and resource, making it easy to parse 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 simple two-parameter mutation with no output schema, the description conveys the core action. However, it omits details about what the API returns, whether the operation is idempotent, or what happens if the user is not on the list, leaving room for improvement.
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 input schema covers both parameters with clear descriptions (handle, listUri), so the schema has 100% coverage. The description adds no additional meaning beyond what the schema already provides, which is acceptable per baseline.
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 verb (Remove), resource (a user), and target container (a Bluesky list). This distinguishes it from sibling tools like add-to-list (opposite action) and delete-list (deletes the entire list).
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 does not mention prerequisites (e.g., list must exist, user must be on the list) or any context where another tool would be preferred.
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 only says 'Unfollow a user' and does not disclose side effects, idempotency, error cases, or any underlying behavior beyond the basic action.
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 a single, concise sentence that is front-loaded with the action. It contains zero wasted words and is appropriately sized for the tool's simplicity.
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?
The tool is simple with one parameter and no output schema, but the description lacks any context about usage, prerequisites, or effects. It is minimally viable but leaves questions about edge cases and expected outcomes.
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 input schema already describes the 'handle' parameter as 'The handle of the user to unfollow' (100% schema coverage). The description adds no additional parameter information, so the baseline of 3 applies.
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 'Unfollow a user on Bluesky' uses a specific verb and resource, clearly distinguishing this tool from its sibling 'follow-user'. It is direct and unambiguous about the action performed.
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?
There is no guidance on when to use this tool vs alternatives, no mention of prerequisites (e.g., must be following the user), and no exclusions. The description merely states the action without any contextual 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, the description carries the full burden of behavioral disclosure. It only states the action without revealing that deletion is permanent, requires ownership, or what happens to list contents. This is a significant gap for a destructive operation.
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 a single, front-loaded sentence with no redundant information. It conveys the core purpose efficiently.
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 destructive mutation tool with no annotations or output schema, the description should mention permanence, ownership constraints, or possible errors. The current text is too sparse to fully prepare an agent for invoking the tool safely.
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 input schema already fully describes the single parameter (listUri) with its purpose, and the tool description adds no extra semantic detail. Baseline of 3 holds due to 100% schema description coverage.
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 action (Delete) and the resource (a list on Bluesky), distinguishing it from sibling tools like remove-from-list and create-list. The verb is specific and the scope is unambiguous.
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 the tool is for deleting an entire list, but provides no explicit when-to-use guidance or alternatives (e.g., use remove-from-list to delete individual items). No prerequisites such as ownership 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?
The description states only that it retrieves messages from a specific DM conversation, adding little beyond the tool name. With no annotations, it does not disclose pagination, ordering, authentication requirements, error behavior, or that this is a read-only operation, though 'get' implies a read.
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?
Single sentence, front-loaded with the verb, no filler. It conveys the core purpose in eight words and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter read tool with no output schema, the description is mostly sufficient: it names the action and target. However, without annotations or an output schema, it leaves unspecified return format and ordering, which would be useful. Overall it is adequate but not exhaustive.
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 itself adds no parameter information, but the input schema covers 100% of parameters with clear descriptions: convoId identifies the conversation (and references get-conversations) and limit controls fetch count. Therefore the schema carries the semantic weight, giving the baseline score.
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 uses the specific verb 'Get' paired with the resource 'messages from a specific DM conversation' and scopes it to Bluesky, clearly distinguishing it from sibling tools like get-conversations (lists conversations) and send-dm (sends messages).
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 when-to-use or alternative guidance is provided in the description. The only usage hint ('get from get-conversations') lives in the parameter schema, not the tool description, so an agent selecting this tool gets no context about prerequisites or when to prefer it.
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. The description only states 'Search for users/actors' and does not mention read-only status, return format, pagination, rate limits, or any other behavioral traits. This is a significant gap for a search tool.
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 a single sentence that directly states the purpose with no filler or redundancy. It is appropriately sized and front-loaded, making it easy to parse quickly.
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 absence of annotations and output schema, the description should provide more context about return values, result structure, or usage notes. The tool is under-specified for a search operation, leaving the agent uncertain about what to expect from the 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?
Schema description coverage is 100%, with both 'query' and 'limit' having descriptions in the schema. The tool description adds no new parameter-level information beyond the schema, so the baseline score of 3 applies.
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 'Search for users/actors on Bluesky' clearly specifies the action (search), the resource (users/actors), and the platform (Bluesky). This distinguishes it from sibling search tools like search-posts and search-feeds, which target different resource types.
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 when looking for people on Bluesky but provides no explicit when-to-use or when-not-to-use guidance, nor does it name alternative tools. The context is clear from the resource type but lacks formal usage boundaries.
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 only states the purpose, omitting details about result format, pagination, sorting behavior, or side effects. While 'search' implies a read-only operation, this is not explicitly disclosed, leaving significant behavioral ambiguity.
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 a single concise sentence ('Search for posts on Bluesky') that is front-loaded and free of fluff. Every word contributes meaning with no unnecessary additions.
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?
With no output schema, the description should at least indicate the return value (e.g., a list of posts). It does not, and also omits mention of authentication, rate limits, or result fields. The tool is simple, but this minimal description leaves important contextual gaps for an agent deciding to invoke it.
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 input schema has 100% coverage, with each parameter (query, sort, limit) having a clear description and the sort parameter documented with an enum. The description adds no extra parameter-level detail, so the baseline score of 3 is appropriate given the schema already carries the semantic weight.
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 'Search for posts on Bluesky' with a specific verb ('Search') and resource ('posts on Bluesky'). This distinguishes it from sibling tools like 'search-people' and 'search-feeds' by the target content type.
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 purpose implies when to use it (when searching posts) but provides no explicit guidance on when to choose this over alternatives like search-people or search-feeds. There are no exclusions or alternative names referenced, so it meets the baseline but lacks explicit differentiation.
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 responsibility for disclosing behavioral traits. It only states the action ('Follow a user on Bluesky') and does not mention idempotency, effects on existing relationships, return values, or failure modes. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. No unnecessary words or details, earning a top score for efficiency.
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?
The tool is simple with one parameter and no output schema, so the description is minimally adequate. However, without any annotation or output information, a truly complete description would mention what happens after following (e.g., returns nothing, or returns the follow record). It meets the minimum viability bar.
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 coverage for the parameter is 100%: the 'handle' property is clearly described as 'The handle of the user to follow'. The description adds no extra semantic value beyond the schema, so the baseline of 3 applies.
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 uses a specific verb ('Follow') and resource ('a user on Bluesky'), making the tool's purpose immediately clear. It also distinguishes from the sibling 'unfollow-user' tool by naming the action directly.
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 (call this to follow a user), and the sibling 'unfollow-user' provides a natural contrast, but there is no explicit statement about when to use vs. alternatives or any prerequisites. It is adequate for such a simple tool but lacks explicit guidance.
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 must fully disclose behavior. It only states that it gets liked posts but does not mention authentication requirements, ordering, pagination behavior beyond the limit parameter, error handling, or the response structure. This is minimal disclosure for a tool with no annotation support.
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 a single, concise sentence that is front-loaded with the key verb and resource. It contains no unnecessary words or repetition and is easy to parse 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 simplicity (one parameter, no output schema), the description is adequate but minimal. It lacks any mention of response format, empty-list behavior, or authentication side effects, which would be useful for agents to fully understand the tool's output and potential failure modes.
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 input schema fully describes the single 'limit' parameter (type, default, minimum, maximum). The description adds no extra meaning to this parameter, so the baseline of 3 applies given 100% schema coverage.
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 uses a specific verb ('Get') and clearly identifies the resource ('list of posts that the authenticated user has liked'), distinguishing it from sibling tools like get-post-likes (which lists users who liked a post) and get-user-posts (which lists posts created by a user).
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 clearly states the tool's purpose, implying it should be used when the authenticated user's liked posts are needed. However, it does not explicitly mention when not to use it or reference any alternative tools, though none of the siblings directly duplicate this 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?
No annotations are provided, so the description carries the full burden. It only states 'Fetch posts' with no additional behavioral details such as authentication requirements, rate limits, sorting, or pagination. This is a minimal disclosure.
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 a single, clear sentence with no wasted words. It is concise and front-loaded with the action and resource.
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?
The tool is relatively simple with no output schema, but the description could provide more context about the 'type' parameter (posts vs hours) or what constitutes a 'list'. As is, it is minimally complete but leaves some ambiguity about behavior and return value.
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?
All three parameters have schema descriptions (100% coverage), so the description does not need to explain them. The description itself adds no extra semantic value beyond what the schema already provides. Baseline score of 3 applies.
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 action (fetch posts) and the specific resource (users in a specified list). This distinguishes it from sibling tools like get-user-posts or get-timeline-posts, which fetch from different sources.
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 that this tool is for fetching posts from a list of users, but it does not explicitly state when to use it over alternatives or any exclusions. The context is implied, not explicit.
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 only states the purpose and does not describe what 'information about users' includes, whether authentication is required, error handling, or any other behavioral traits. For a read tool, the absence of these details limits transparency.
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 a single, front-loaded sentence with no unnecessary words. It conveys the essential purpose efficiently and is appropriately concise for a simple read operation.
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 simple tool with two well-documented parameters, the description is minimal but serviceable. However, the lack of an output schema and absence of any detail about the return payload or pagination behavior leaves it somewhat incomplete. Given the complexity, a slightly richer description would improve completeness.
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 input schema has 100% coverage, describing both 'uri' and 'limit' with examples and ranges. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
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 function: retrieving information about users who liked a specific post. It uses a specific verb and resource ('get information about users', 'specific post') and distinguishes from sibling tools like 'get-liked-posts' which focus on posts liked by a user, not likes on a post.
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 purpose is clear enough that usage is implied (when you need to see who liked a post). However, there is no explicit guidance on when not to use it or alternatives, such as using 'get-liked-posts' to see a user's liked posts. The description lacks any exclusions or alternative tool references.
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 bears full responsibility for behavioral disclosure. It does not mention edge cases (e.g., invalid URLs), whether only post URLs are supported (schema says 'post URL' but description says 'web URL'), or the exact shape of the returned value (plain string vs. object). This leaves significant unknowns for an agent.
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 a single, front-loaded sentence that immediately conveys the action and output. Every word serves a purpose, and it avoids extraneous detail.
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 output schema, the description should clarify the return value format (e.g., 'returns a string') and any input constraints (e.g., only post URLs). It does not, nor does it mention error handling or supported URL types, leaving the agent to guess about behavior that is not inferable from structured data.
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 schema covers the only parameter with a description and example, so schema_description_coverage is 100%. The tool description adds no additional parameter details beyond what the schema provides, which meets the baseline but does not elevate it.
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 a specific verb ('Convert') and resource ('Bluesky web URL') with a distinct output ('AT URI format'). This distinguishes it from sibling tools, which are all CRUD/search operations, making the tool's purpose unambiguous.
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 implies usage context: when you have a Bluesky web URL and need an AT URI for other tools. It does not explicitly state when not to use it or name alternative tools, but the conversion-focused purpose naturally separates it from siblings in the list.
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 only states the operation ('create a new list') and the two types; it does not mention permissions, reversibility, response format, or any side effects beyond the creation. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action ('Create a new list on Bluesky') and then adds a clarifying parenthetical for the two list types. Every word earns its place, with no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with full parameter coverage, the description is mostly sufficient. It clearly states the purpose and the two list types. However, the absence of an output schema means a brief mention of the return value (e.g., the created list) would improve completeness, but the current description is not grossly inadequate.
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 input schema provides 100% coverage with descriptions for all three parameters, including the enum values for purpose. The description does not add additional parameter semantics beyond what the schema already covers, so the baseline of 3 applies.
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 uses the specific verb 'create' with the resource 'list', names the platform 'Bluesky', and explicitly clarifies the two list types (curate or moderation). This distinguishes it from sibling tools like get-lists, add-to-list, and delete-list.
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 by naming the two purposes ('curate list or moderation list'), giving some context for when to use the tool. However, it does not explicitly state when to prefer this over related tools like add-to-list or delete-list, nor does it mention any exclusions or 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 the full burden of disclosing behavior. It only says 'List your recent DM conversations', which is a minimal statement. It does not mention that the operation is read-only, whether there is pagination, how 'recent' is defined, or what the response structure looks like.
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 a single, front-loaded sentence that directly states the tool's purpose. It contains no filler or redundant information, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter, the description is clear enough to inform the agent about the tool's primary function. However, the absence of annotations and an output schema means some context about safety and return format is missing, though the tool's simplicity mitigates this.
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 input schema covers the only parameter 'limit' with a full description. The tool description adds no extra meaning about the parameter, but since schema coverage is 100%, the baseline of 3 is appropriate.
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 uses the specific verb 'List' with the clear resource 'your recent DM conversations on Bluesky'. It is distinct from sibling tools like get-dm-messages (which lists messages within a conversation) and get-notifications, making the tool's purpose unambiguous.
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 by stating 'your recent DM conversations', which suggests this tool is for fetching a list of conversations. However, it does not explicitly state when to prefer this over get-dm-messages or other sibling tools, nor does it provide any exclusion criteria.
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 must carry the full burden of behavioral disclosure. It only states the basic purpose and does not mention pagination, response format, rate limits, authentication requirements, or whether the operation is read-only. This is a significant gap for a tool with no annotations.
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 a single sentence that directly conveys the tool's purpose with no redundant words or filler. It is front-loaded 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?
The tool is simple (one optional parameter, no output schema), so the description is minimally sufficient. However, because there is no output schema, the description could have better described the return value (e.g., list of list objects) and any pagination behavior to be fully complete.
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 input schema has 100% coverage for the single optional parameter 'handle', including its default behavior. The description does not add any parameter-specific detail, but per the rubric, a high coverage baseline of 3 is appropriate.
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 verb (get), resource (lists), and scope (created by a user on Bluesky). It is specific and distinguishes from sibling tools like get-list-posts (which fetches posts from a list) and create-list/delete-list (which mutate lists).
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 clearly implies when to use the tool: when you need all lists created by a user. However, it does not explicitly mention alternatives or exclusionary conditions, so it falls short of a 5.
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?
No annotations are provided, so the description carries the responsibility of disclosing behavioral traits. It states that notifications are 'recent' and scoped to the user ('your'), implying authentication and time-based ordering, but it does not explicitly state whether fetching notifications has side effects like marking them as read. Some behavioral details are left to inference.
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 a single sentence that immediately conveys the tool's function without any extraneous information. It is front-loaded with the verb 'Get' and the resource 'notifications.' This achieves maximum conciseness with no wasted words.
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?
The tool has no output schema and the description does not describe the return structure or format of notifications, which leaves some ambiguity about what the agent can expect. For a simple read operation with well-documented parameters, the description is adequate but not complete: it lacks details on ordering, pagination behavior, and read side effects. Given the absence of annotations, the description should provide more 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?
The input schema provides comprehensive descriptions for both parameters (limit and filter) with defaults and constraints, covering 100% of the parameters. The description adds no extra meaning beyond the schema; it mentions notification types that already appear in the filter enum. The baseline of 3 is appropriate as the schema does the heavy lifting.
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 retrieves the user's recent Bluesky notifications and enumerates the included types (likes, reposts, follows, mentions, replies). This specific verb+resource structure distinguishes it from sibling tools like get-timeline-posts or get-feed-posts, which serve different purposes. The purpose is unambiguous.
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 the tool is used when a user wants to see their notifications, but it does not explicitly state when to choose it over alternatives such as get-timeline-posts or get-feed-posts. No exclusions or comparisons are provided. The usage context is inferred from the tool's purpose rather than explicitly guided.
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, the description carries the full burden. It states the scope of listing 'all available' and that descriptions are included, which is useful. However, it does not mention any potential side effects, error conditions, or output format details. For a simple read-only list operation, this is minimally adequate.
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 a single sentence that exactly states the purpose. It is concise, front-loaded with the verb, and contains no filler or redundancy.
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 low complexity and empty input schema, the description is quite complete. It conveys what the tool returns (list of resources with descriptions) and the scope (all available). The absence of an output schema is compensated by this clear statement. A small gap is the lack of usage guidance, but that is minor for such a straightforward tool.
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 zero parameters, so the schema is empty and there is nothing to describe. Based on the rule, 0 params gets a baseline of 4. The description adds no parameter info because none exist.
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 uses a specific verb 'List', a specific resource 'MCP resources', and scope 'all available'. It clearly distinguishes from sibling tools which focus on posts, users, feeds, etc., while this tool targets the server's resources.
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 vs alternatives. There are no exclusions or alternative mentions. The context is only implicit, but no explicit usage guidance is given.
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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states that the tool returns replies and context, but it does not explicitly say whether the operation is read-only, how nested replies are handled, or whether the original post is included. The phrase 'full conversation thread' hints at completeness but lacks detail about limits or ordering.
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 a single sentence that is front-loaded with the primary action ('Get a full conversation thread') and ends with a brief elaboration on the output. It is concise with no wasted words.
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 simplicity (one parameter, no output schema, no annotations), the description is reasonably complete but lacks details about return structure, pagination, or any limitations on thread depth. It adequately states what is returned but leaves some operational ambiguity for an agent.
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 schema covers 100% of parameters, including a description for the single 'uri' parameter. The tool description does not add any additional parameter semantics, but with full schema coverage, this is adequate.
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 uses the specific verb 'Get' with the resource 'full conversation thread' and scopes it to a specific post, clearly distinguishing it from siblings like get-timeline-posts or get-post-likes. The phrase 'showing replies and context' adds clarity about what is returned.
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: when a full conversation thread for a specific post is needed. It does not explicitly mention alternatives or exclusions, but the use case is well-defined compared to other post-related tools.
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 burden of behavioral disclosure. 'Fetch' implies a read-only operation, and 'reverse chronological order' explains the ordering behavior. However, it does not mention authentication requirements, pagination, rate limits, or the exact response structure, leaving gaps for an agent assessing side effects and usage constraints.
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 a single, well-structured sentence that is immediately informative. It avoids fluff and provides the essential information (resource and content) in a clear, front-loaded manner.
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 and complete schema coverage, the description is nearly sufficient. It explains what the timeline contains and the ordering. However, because there is no output schema, a brief note about the return format (e.g., a list of post objects) would make it fully complete for an agent.
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 100%, so the input schema already thoroughly explains both parameters ('count' as number of posts or hours, and 'type' as posts/hours). The description adds no additional parameter semantics, which is acceptable because the schema handles the heavy lifting.
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 uses a specific verb 'Fetch' and clearly identifies the resource as 'your home timeline from Bluesky'. It further distinguishes this from sibling tools by explaining it contains posts from followed people in reverse chronological order, which separates it from get-user-posts, get-feed-posts, and get-list-posts.
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 what the tool does (home timeline of followed users), making it easy to infer when to use it. However, it does not explicitly state when not to use it or mention alternatives, but the context is strong enough to guide selection among similar timeline-related tools.
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, the description carries the transparency burden and does disclose the key behavioral trait: it returns the authenticated user's identifiers and implies session/auth requirements. It does not discuss error behavior without a session, but for a simple read-only getter this is sufficient.
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?
Two short sentences front-load the action and output. There is no filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description adequately states what is returned, for which user, and when it should be used. The absence of an output schema is compensated by explicitly naming the returned fields (handle and did).
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?
There are zero parameters, so schema coverage is trivially complete and no parameter documentation is needed. The description adds no parameter semantics, but none are required for this tool.
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 uses a specific verb ('Return'), names the exact resources (handle and did), and scopes them to the currently authenticated user's session. This clearly distinguishes it from sibling tools that operate on other users or arbitrary profiles.
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?
It explicitly gives a trigger condition: when someone asks about themselves using 'me' or 'my' on Bluesky. It does not mention alternatives or when not to use it, but the context is clear enough for selection.
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:

[![bsky-mcp-server MCP server](https://glama.ai/mcp/servers/ffylaktis/bsky-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/ffylaktis/bsky-mcp-server)

Score Badge

Copy to your README.md:

[![bsky-mcp-server MCP server](https://glama.ai/mcp/servers/ffylaktis/bsky-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/ffylaktis/bsky-mcp-server)

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/ffylaktis/bsky-mcp-server'

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