mcpbluesky

by awaku7

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation5/5
Every tool has a distinct purpose with clear boundaries, such as bsky_follow vs bsky_unfollow, bsky_get_author_feed vs bsky_get_timeline, and bsky_search_posts vs bsky_search_local_posts. The descriptions specify unique actions on specific resources, making it easy for an agent to differentiate and select the correct tool without confusion.
Naming Consistency5/5
All tools follow a consistent 'bsky_verb_noun' or 'bsky_verb_adjective_noun' pattern, using snake_case throughout. Examples include bsky_create_list, bsky_get_followers, and bsky_search_users. This predictability aids in understanding and usage without any deviations in naming conventions.
Tool Count3/5
With 36 tools, the count is high for a social media API server, potentially overwhelming for agents. While it covers many features, it might be borderline heavy, as typical well-scoped servers have 3-15 tools. However, given Bluesky's broad functionality, it's not extreme but leans toward the upper limit of appropriateness.
Completeness5/5
The tool set provides comprehensive coverage for Bluesky operations, including user management (follow, block, mute), content actions (post, like, repost), data retrieval (feeds, profiles, notifications), and administrative tasks (login, logout). There are no obvious gaps, and it supports full CRUD/lifecycle for lists, posts, and interactions, ensuring agents can handle most workflows without dead ends.
Average 2.8/5 across 36 of 36 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states the action ('refreshes a session') without explaining what this entails: whether it requires authentication, modifies server state, has side effects (e.g., extending session lifetime), returns new tokens, or handles errors. For a session management tool with zero annotation coverage, this is critically inadequate.
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 extremely concise—a single Japanese sentence—with zero wasted words. It's front-loaded with the core action. While under-specified, it's not verbose or poorly structured from a brevity perspective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's likely complexity (session management often involves authentication state, tokens, and expiration) and the presence of an output schema (which might describe return values), the description is incomplete. It fails to explain the tool's role in the authentication flow, prerequisites, or behavioral outcomes. With no annotations and minimal parameter coverage, the description doesn't provide enough context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter ('acting_handle') with 0% description coverage in the schema itself. The tool description provides no information about parameters—it doesn't mention 'acting_handle' at all or explain its purpose (e.g., optional user handle for session refresh). With low schema coverage and no compensation in the description, parameter understanding is severely lacking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'セッションを更新します' (Refreshes a session) is a tautology that essentially restates the tool name 'bsky_refresh_session' in Japanese. It doesn't specify what type of session (authentication/API), what resource it operates on, or how it differs from sibling tools like 'bsky_login' or 'bsky_logout'. While the verb 'refresh' is clear, the description lacks specificity and sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing session), timing (e.g., when sessions expire), or relationships to sibling tools like 'bsky_login' (for initial authentication) or 'bsky_logout' (for ending sessions). There's complete absence of usage 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 the full burden of behavioral disclosure. It mentions authentication requirements, which is useful, but fails to describe critical traits: whether the deletion is permanent, if it affects associated data (e.g., list members), what permissions are needed beyond authentication, or any rate limits. For a destructive operation with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence that is front-loaded with the core action. There is no wasted language, and it efficiently states the purpose and authentication requirement. However, it could be slightly more structured by separating the action from prerequisites for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a destructive operation with no annotations, 0% schema coverage, and an output schema (which might help with return values), the description is incomplete. It lacks details on behavioral traits, parameter meanings, usage context, and fails to address the implications of deletion. For a tool that permanently removes data, this level of description is inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It adds no information about the two parameters (list_uri and acting_handle), such as what a list_uri is, how to obtain it, or the purpose of acting_handle. The description fails to provide any semantic context beyond what the bare schema offers, leaving parameters largely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('削除します' - delete) and resource ('リスト' - list), making the basic purpose clear. However, it doesn't distinguish this from sibling tools like bsky_delete_post or bsky_remove_from_list, nor does it specify what type of list is being deleted (e.g., social list, feed list). The description is functional but lacks specificity about the resource scope.
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 minimal guidance with '要認証' (requires authentication), indicating a prerequisite but not when to use this tool versus alternatives. No context is given about when deletion is appropriate versus other list operations like bsky_remove_from_list or bsky_get_list, nor are there exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the basic action ('search users by keyword') without mentioning any behavioral traits such as rate limits, authentication requirements, pagination behavior (implied by the 'cursor' parameter but not explained), or what the search returns. For a search tool with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence ('ユーザーをキーワードで検索します') that efficiently conveys the core action. It is front-loaded with the main purpose and wastes no words. However, it could be slightly improved by adding a bit more context without sacrificing brevity, but it's already well-structured for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no annotations, but an output schema exists), the description is incomplete. It lacks details on parameter usage, behavioral traits, and differentiation from siblings. While the output schema may cover return values, the description doesn't provide enough context for the agent to understand when and how to use this tool effectively, especially compared to other search tools in the set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters (term, limit, cursor, acting_handle) have descriptions in the schema. The description does not compensate by explaining any parameters—it only mentions 'keyword' generically, which loosely relates to the 'term' parameter. This fails to add meaningful semantics beyond the schema, leaving parameters largely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'ユーザーをキーワードで検索します' (Search users by keyword) clearly states the verb ('search') and resource ('users'), providing a basic purpose. However, it doesn't differentiate from sibling tools like bsky_search_posts or bsky_search_local_posts, which also perform keyword searches but on different resources. The purpose is understandable but lacks specificity about what makes this tool unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling search tools (e.g., bsky_search_posts for searching posts instead of users), nor does it specify any prerequisites or contexts for usage. Without such information, the agent must infer usage from the tool name alone, which is insufficient for optimal selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'gets details' but doesn't disclose whether this is a read-only operation, requires authentication, has rate limits, or what the output format looks like. The description is minimal and fails to provide essential behavioral context for a tool with multiple parameters and an output schema.
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, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly. Every part of the sentence contributes to understanding the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 1 required, with an output schema) and lack of annotations, the description is incomplete. It doesn't explain parameter usage, behavioral aspects like authentication needs, or how the output relates to the input. While the output schema exists, the description should still provide context on what 'details' entail and when to use this tool, which it fails to do adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters (list_uri, limit, cursor, acting_handle) are documented in the schema. The description doesn't add any semantic information about these parameters—it doesn't explain what 'list_uri' is, how 'limit' and 'cursor' affect pagination, or what 'acting_handle' does. This leaves parameters largely unexplained, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '指定リストの詳細を取得します' (Get details of a specified list) clearly states the verb ('取得します' - get) and resource ('リスト' - list), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'bsky_get_lists' (which likely lists multiple lists) or explain what 'details' specifically means. The purpose is clear but lacks specificity about what details are returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'bsky_get_lists' (for listing multiple lists) or 'bsky_get_profile' (which might include list information), nor does it specify prerequisites such as authentication. Usage is implied only by the action of getting list details, with no explicit context or exclusions 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?
No annotations are provided, so the description carries the full burden. It mentions authentication is required, which is a basic behavioral trait, but fails to disclose other critical aspects: whether this is a read-only or mutative operation (implied as a write since it's a reply), potential side effects (e.g., posting publicly), rate limits, error conditions, or response format. For a tool with 6 parameters and no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—a single sentence in Japanese that states the action and authentication requirement. It's front-loaded with the core purpose and wastes no words, though it could benefit from more detail given the tool's complexity. The brevity is efficient but may be too sparse for full understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (5 required), no annotations, 0% schema description coverage, and an output schema exists (which reduces the need to describe return values), the description is incomplete. It lacks essential context: no explanation of parameter roles, no behavioral details beyond auth, and no guidance on usage relative to siblings. For a mutative tool with multiple inputs, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 6 parameters have descriptions in the schema. The tool description adds no information about what parameters like 'parent_uri', 'parent_cid', 'root_uri', 'root_cid', or 'acting_handle' mean or how they should be used. It only implies 'text' is the reply content but provides no details. With low coverage and no compensation in the description, this score reflects the lack of parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '特定投稿へ返信します' translates to 'replies to a specific post.' It specifies the verb (reply) and resource (post), though it doesn't explicitly differentiate from siblings like bsky_post (which creates new posts). The mention of authentication ('要認証') adds context but doesn't fully distinguish it from other tools that may also require auth.
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 minimal guidance: it mentions authentication is required ('要認証'), but offers no explicit context on when to use this tool versus alternatives like bsky_post for new posts or how it relates to other reply-related tools (none listed). There's no mention of prerequisites, exclusions, or comparisons to sibling tools, leaving usage ambiguous.
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 but provides almost none. It doesn't indicate whether this is a read-only operation, what authentication is required, rate limits, error conditions, or what happens when a profile doesn't exist. The single sentence offers no behavioral context 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 extremely concise - a single Japanese sentence that directly states the tool's purpose. There's zero wasted language or unnecessary elaboration. While it may be too brief for complete understanding, it's perfectly structured and front-loaded with the essential information.
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 that there's an output schema (which will define the return structure), the description doesn't need to explain return values. However, for a profile retrieval tool with no annotations and 2 parameters (one required), the description is minimally adequate. It states what the tool does but leaves too many behavioral and parameter questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for both parameters, the description provides no information about what 'handle' and 'acting_handle' mean, their format, or how they differ. The description doesn't compensate for the schema's lack of parameter documentation, leaving both parameters semantically undefined for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('取得します' - get/retrieve) and resource ('Blueskyのプロフィール' - Bluesky profile), making the purpose immediately understandable. It distinguishes itself from siblings like bsky_update_profile (which modifies profiles) and bsky_search_users (which searches for users). However, it doesn't specify what profile information is retrieved, keeping it at a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose bsky_get_profile over bsky_search_users for finding user information, or how it relates to bsky_resolve_handle. There's no context about prerequisites, authentication requirements, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions authentication requirements ('要認証'), which is useful, but fails to describe other critical traits: whether this is a mutation (implied by 'likes'), what happens on success/failure, rate limits, or if likes are reversible. For a write operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that front-loads the core action ('likes a specific post') and includes an essential prerequisite ('requires authentication'). Every word earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with 3 parameters (0% schema coverage), no annotations, and an output schema (which might cover return values), the description is incomplete. It mentions authentication but omits parameter meanings, behavioral details like idempotency or effects, and doesn't leverage the output schema to clarify results. For this complexity, it should do more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 3 parameters (uri, cid, acting_handle) are documented in the schema. The description adds no information about what these parameters mean, their formats, or how they relate to 'liking a post'. It fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('いいねします' = 'likes') and the target ('特定投稿' = 'specific post'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'bsky_get_likes' (which retrieves likes) or 'bsky_repost' (which shares posts), missing explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite ('要認証' = 'requires authentication'), which gives some context, but offers no guidance on when to use this tool versus alternatives like 'bsky_repost' or 'bsky_get_likes'. It lacks explicit when/when-not statements or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions authentication requirement but doesn't disclose other behavioral traits like whether this is a destructive operation (it likely is since it updates profile data), what happens to existing profile fields not mentioned, rate limits, or error conditions. The description is minimal and leaves critical behavioral aspects unspecified.
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 extremely concise - a single Japanese sentence that gets straight to the point. There's no wasted verbiage, though one could argue it's too brief given the tool's complexity. The authentication requirement is appropriately included in the main statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with 3 parameters, 0% schema description coverage, no annotations, but with an output schema, the description is inadequate. It doesn't explain what fields can be updated, how null values are handled (all parameters accept null), or what the tool returns. The output schema existence means the description doesn't need to explain return values, but it should cover more about the update operation itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, the description provides no information about the three parameters (displayName, description, acting_handle), their purposes, formats, or constraints. The schema only provides titles and types, leaving semantics completely undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('更新します' - update) and resource ('自分のプロフィール' - my profile), making the purpose unambiguous. However, it doesn't differentiate this tool from potential sibling tools like bsky_get_profile, which is a read operation versus this write operation.
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 mentions authentication requirement ('要認証'), which provides some context about when to use this tool. However, it doesn't explain when to use this versus alternatives like bsky_post (for content creation) or bsky_set_threadgate (for thread settings), nor does it specify any prerequisites beyond authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions authentication requirement, which is useful, but fails to describe other critical traits: whether this is a mutation (implied by 'adds'), what permissions are needed, how errors are handled, or what the output contains. For a tool that modifies data, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence in Japanese that states the action and authentication requirement. It's front-loaded with the core purpose and wastes no words, making it efficient despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with 3 parameters, 0% schema description coverage, no annotations, but with an output schema, the description is insufficient. While the output schema may cover return values, the description lacks crucial context: parameter explanations, behavioral details beyond authentication, and differentiation from sibling tools. For a tool that adds users to lists in a social platform, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds no information about the three parameters (subject_did, list_uri, acting_handle), their meanings, formats, or examples. It doesn't compensate for the complete lack of schema descriptions, leaving parameters semantically undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('追加します' - adds) and resource ('ユーザーをリストに' - user to list), making the purpose specific and understandable. It distinguishes from siblings like 'bsky_remove_from_list' by indicating addition rather than removal, though it doesn't explicitly contrast with other list-related tools like 'bsky_create_list' or 'bsky_get_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 includes a prerequisite ('要認証' - requires authentication), which provides some context, but offers no guidance on when to use this tool versus alternatives like 'bsky_remove_from_list' or other list management tools. It lacks explicit when/when-not instructions or named alternatives for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions authentication requirement ('要認証'), which is useful context. However, it lacks critical details: it doesn't specify whether this is a mutating operation (implied by 'create' but not explicit), what permissions are needed, rate limits, or what happens on success/failure. The description is too sparse for a tool that creates resources.
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 extremely concise - a single sentence with 7 Japanese characters. It's front-loaded with the core action. However, this brevity comes at the cost of completeness; while structurally efficient, it may be too terse for effective tool selection.
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 this is a creation tool with 4 parameters, 0% schema description coverage, no annotations, but with an output schema present, the description is incomplete. The output schema existence means return values don't need explanation, but the description lacks crucial context about authentication scope, parameter meanings, and behavioral expectations. It meets minimum viability but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. The description provides no information about any of the 4 parameters (name, purpose, description, acting_handle). It doesn't explain what 'name' represents, what 'purpose' options exist (though schema shows a default), or how 'acting_handle' affects the operation. This leaves significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('新しいリストを作成します' - creates a new list) and resource (list), which is specific and unambiguous. It distinguishes from siblings like bsky_delete_list (deletion) and bsky_get_list (retrieval). However, it doesn't specify what type of list or platform context beyond the tool name hinting at Bluesky.
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 minimal guidance with '要認証' (requires authentication), indicating a prerequisite. However, it offers no explicit guidance on when to use this tool versus alternatives like bsky_get_lists (for viewing) or bsky_add_to_list (for modifying existing lists), nor does it mention any exclusions or specific contexts for creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions authentication requirement. It lacks critical behavioral details: whether deletion is permanent/reversible, rate limits, permissions needed beyond authentication, or effects on related content (e.g., likes, replies). The authentication hint is useful but insufficient 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 extremely concise - a single sentence in Japanese that directly states the action and key requirement. There's no wasted language, though this brevity contributes to gaps in other dimensions.
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 tool with no annotations, 0% schema coverage, and 2 parameters, the description is inadequate. While an output schema exists (reducing need to describe returns), it fails to address critical context: authentication details, deletion behavior, parameter meanings, or usage scenarios. The presence of authentication hint is minimal compensation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'post_uri' represents (e.g., format, how to obtain) or when 'acting_handle' is needed versus optional. With 2 parameters undocumented in both schema and description, this creates significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('削除します' - delete) and resource ('投稿' - post), making the purpose specific and understandable. It distinguishes from siblings like 'bsky_post' (create) and 'bsky_repost' (share), though it doesn't explicitly mention these alternatives in the description itself.
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 minimal guidance with '要認証' (requires authentication), indicating a prerequisite but no explicit when-to-use context. It doesn't differentiate from similar tools like 'bsky_delete_list' or explain when deletion is appropriate versus alternatives like editing or hiding content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions authentication requirement but doesn't describe what the follow operation entails (e.g., creates a social connection, appears in feeds), potential rate limits, error conditions, or what the output contains. For a social action tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Japanese sentence that states the core action and authentication requirement. There's no wasted text, though it could benefit from slightly more detail given the tool's complexity.
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 this is a social action tool with 2 parameters, 0% schema description coverage, no annotations, but with an output schema, the description is minimally adequate. The output schema existence means return values don't need explanation, but the description should provide more context about the follow operation's behavior and parameter usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. The description only mentions '指定DID' (specified DID) which corresponds to 'subject_did', but doesn't explain the optional 'acting_handle' parameter or provide any context about parameter formats, constraints, or relationships between them.
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 ('フォローします' - follow) and target resource ('指定DID' - specified DID), making the purpose immediately understandable. It distinguishes from siblings like 'bsky_unfollow' by being the follow operation, though it doesn't explicitly contrast with other social actions like 'bsky_block' or 'bsky_mute'.
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 minimal guidance - only mentioning authentication requirement ('要認証'). It doesn't explain when to use this versus alternatives like 'bsky_add_to_list' for list management or 'bsky_block' for blocking users, nor does it specify prerequisites beyond authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a retrieval operation ('取得します'), implying it's read-only, but doesn't confirm this explicitly. It mentions getting a 'thread (reply tree)' which suggests hierarchical data, but doesn't describe pagination, rate limits, authentication requirements, or what happens with invalid URIs. For a tool with 3 parameters and no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose. There's no wasted language or redundancy. However, it could be slightly more front-loaded by specifying it's for Bluesky/AT Protocol (context implied by 'bsky' prefix but not in description text). The structure is appropriate for a simple retrieval tool.
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 has an output schema (which will define the return structure), the description doesn't need to explain return values. However, for a read operation with 3 parameters (one required, two with defaults) and no annotations, the description should provide more context about parameter usage, authentication needs, and error conditions. The current description is minimally adequate but leaves the agent guessing about important operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions '特定投稿' (specific post) which loosely relates to the 'uri' parameter, but doesn't explain what format the URI should be, what 'depth' controls (default 6 but meaning unclear), or what 'acting_handle' does (possibly for authentication or perspective). With 3 undocumented parameters, the description adds minimal semantic value beyond the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('取得します' - get/retrieve) and resource ('特定投稿のスレッド（返信ツリー）' - specific post's thread/reply tree), making the purpose unambiguous. It distinguishes from siblings like bsky_get_timeline or bsky_get_author_feed by focusing on thread structure rather than chronological feeds. However, it doesn't explicitly contrast with bsky_get_profile or bsky_get_lists, which are also read operations but for different 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 versus alternatives. It doesn't mention when to prefer bsky_get_post_thread over bsky_get_author_feed (which might show replies) or bsky_search_posts (which might find related content). There's no discussion of prerequisites (e.g., needing a valid post URI) or performance considerations. The only implied usage is when you want a thread structure, but this is minimal 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 provided, the description carries full burden but only mentions authentication requirement. It doesn't disclose what muting entails (e.g., hides posts from timeline, is reversible via 'bsky_unmute', doesn't notify user), rate limits, or error conditions. The authentication note is helpful but 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Japanese sentence that states the core purpose upfront. No wasted words, though it could benefit from slightly more detail given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 2 parameters, 0% schema coverage, no annotations, but with an output schema present, the description is minimally adequate. The authentication note is helpful, but more behavioral context and parameter explanation would improve completeness given the tool's social media impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. It doesn't explain what 'handle' represents (user identifier) or what 'acting_handle' is for (optional override of authenticated user). Two parameters remain completely undocumented.
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 ('ミュートします' - mutes) and target ('指定ユーザー' - specified user), providing a specific verb+resource. However, it doesn't explicitly differentiate from sibling tools like 'bsky_block' or 'bsky_unmute' beyond the basic action name.
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 only mentions authentication requirement ('要認証'), but provides no guidance on when to use this tool versus alternatives like 'bsky_block' or 'bsky_unfollow', nor any context about when muting is appropriate versus other actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions authentication is required, which is a critical behavioral trait. However, it doesn't describe other important aspects: whether this is a destructive/mutative operation (implied by '設定します' but not explicit), rate limits, error conditions, or what the output contains. For a tool that likely modifies post permissions, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded with the core purpose. The authentication note is relevant but could be more integrated. There's no wasted text, though it might be overly brief given the tool's complexity.
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 has an output schema (which reduces the need to describe return values), no annotations, and a 0% schema coverage for 4 parameters, the description is moderately complete. It covers the purpose and authentication need but lacks parameter explanations, behavioral details, and usage context. This is adequate as a minimum but has clear gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description adds no information about parameters beyond what's in the schema (e.g., it doesn't explain what post_uri is, how allow_mentions/allow_following work, or what acting_handle does). With 4 parameters and 0% coverage, the description fails to compensate, leaving parameter meanings unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '投稿に対する返信制限を設定します' (sets reply restrictions for posts). It specifies the verb '設定します' (sets) and the resource '返信制限' (reply restrictions). However, it doesn't explicitly differentiate from sibling tools like bsky_post or bsky_reply, which are related but distinct operations.
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 minimal guidance: it mentions authentication is required ('要認証'), but offers no explicit when-to-use criteria, no exclusions, and no alternatives. It doesn't clarify when to use this vs. other posting or moderation tools like bsky_post or bsky_block, leaving usage context largely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions authentication requirement ('要認証') which is valuable, but doesn't describe what 'unblock' actually does behaviorally (e.g., whether it allows the unblocked user to see your posts, interact with you, etc.), what happens if the block_uri is invalid, or what the response looks like. For a social action tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just one short sentence with a parenthetical note. While perhaps too brief for full understanding, every word serves a purpose: the main action and an important constraint. There's no wasted language or unnecessary elaboration.
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 that there's an output schema (which should document return values), the description's main gaps are in parameter explanation and behavioral context. For a social action tool that modifies user relationships, the description should provide more context about what unblocking means and how to use the parameters. The authentication note is helpful but insufficient for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds no information about the two parameters (block_uri and acting_handle). It doesn't explain what a 'block_uri' is, how to obtain it, what format it should be in, or what 'acting_handle' represents. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'ブロックを解除します' (unblocks) with the parenthetical '(要認証)' (requires authentication). It specifies the verb (unblock) and implies the resource (a blocked entity), but doesn't explicitly differentiate from sibling tools like 'bsky_unmute' or 'bsky_unfollow' which perform related but distinct social 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'bsky_block' (for blocking) or 'bsky_unmute' (for unmuting), nor does it explain prerequisites or appropriate contexts for unblocking versus other social actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions authentication is required, which is useful, but fails to disclose other behavioral traits such as whether the action is reversible, potential side effects (e.g., notifications), rate limits, or error conditions. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the purpose and authentication requirement. It is appropriately sized and front-loaded with no wasted words, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 2 parameters), no annotations, and an output schema present (which reduces need to explain returns), the description is incomplete. It covers authentication but misses key details like parameter semantics and behavioral context, making it minimally adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds no information about the parameters 'follow_uri' or 'acting_handle', leaving their meaning, format, or usage undocumented. This fails to address the coverage gap, resulting in a low score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('unfollow') in Japanese, which translates to 'unfollow' in English, clearly indicating it removes a follow relationship. It distinguishes from siblings like 'bsky_follow' (opposite action) and 'bsky_block' (different relationship type). However, it doesn't specify the resource beyond 'follow', making it slightly less precise than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions authentication is required ('要認証'), providing some context, but offers no guidance on when to use this tool versus alternatives like 'bsky_unblock' or 'bsky_unmute', nor when not to use it. It lacks explicit sibling differentiation or prerequisites beyond authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states that authentication is required ('要認証'), which is useful but insufficient. It doesn't describe what 'unmuting' entails (e.g., does it restore notifications, affect timeline visibility, or have side effects?), whether it's reversible, or what the output looks like. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence) and front-loaded with the core action and key requirement. There's no wasted language, making it efficient despite its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations, 0% schema description coverage, and an output schema (which helps but isn't described), the description is incomplete. It lacks details on behavior, parameters, and usage context, making it inadequate for safe and effective tool invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It provides no information about the two parameters ('handle' and 'acting_handle'), their meanings, formats, or how they relate to the unmute operation. This fails to add value beyond the bare schema, leaving parameters semantically unclear.
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 ('ミュートを解除します' - unmutes) and specifies it requires authentication ('要認証'), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'bsky_mute' or 'bsky_unblock', though the name itself suggests it's the inverse of 'bsky_mute'.
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 mentions authentication is required, but doesn't specify prerequisites, when this operation is appropriate, or how it differs from related tools like 'bsky_unblock' or 'bsky_unfollow'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions authentication requirement ('要認証') which is valuable context, but fails to describe other critical behavioral aspects: what 'blocking' actually does (e.g., hides content, prevents interactions), whether the action is reversible (though bsky_unblock exists as sibling), rate limits, permissions needed beyond authentication, or what the response looks like. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Japanese sentence that states the core action and authentication requirement. It's front-loaded with the primary purpose. However, for a mutation tool with behavioral implications, this brevity comes at the cost of completeness rather than representing efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool (blocking is clearly a write operation) with no annotations, 2 parameters, and 0% schema coverage, the description is incomplete. While an output schema exists (which reduces need to describe return values), the description fails to address: what blocking entails behaviorally, parameter meanings, error conditions, or relationship to sibling tools like bsky_unblock. The authentication note is helpful but insufficient for safe, informed use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. It mentions '指定DID' (specified DID) which aligns with the required 'subject_did' parameter, but doesn't explain what a DID is, format requirements, or how to obtain it. The optional 'acting_handle' parameter receives no mention at all. With 2 parameters and 0% schema coverage, the description adds minimal value beyond what's inferable from parameter names.
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 ('ブロックします' - blocks) and target resource ('指定DID' - specified DID), making the purpose immediately understandable. It distinguishes from siblings like bsky_unblock (inverse action) and bsky_mute (different moderation action). However, it doesn't explicitly differentiate from other blocking-related tools since none exist in the sibling 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 context through '要認証' (requires authentication), suggesting this tool should be used when authenticated. However, it provides no explicit guidance on when to use this vs alternatives like bsky_mute (which appears to be a different moderation action) or bsky_unblock (the inverse operation). No when-not-to-use scenarios or prerequisite conditions beyond authentication are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a retrieval operation ('取得します'), which implies read-only behavior, but doesn't mention authentication requirements, rate limits, pagination, error conditions, or what 'custom feeds' specifically means in the Bluesky context. The description is too minimal for a tool that likely requires authentication.
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, efficient Japanese sentence that gets straight to the point with zero wasted words. It's appropriately sized for what it does convey, though it could benefit from additional context.
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 that there's an output schema (which means return values are documented elsewhere), the description's main job is to explain purpose and usage. However, with no annotations, 2 parameters with 0% schema coverage, and multiple sibling tools in the same domain, the description should provide more context about authentication requirements, what 'custom feeds' means, and differentiation from other feed tools. It's minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for both parameters, the description provides no information about what 'handle' and 'acting_handle' mean, their format requirements, or their relationship. The description mentions '指定したユーザー' (specified user) which hints at the handle parameter, but doesn't explain the acting_handle parameter at all. This is inadequate compensation for the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('取得します' - get/retrieve) and the resource ('指定したユーザーのカスタムフィード一覧' - specified user's custom feed list). It distinguishes itself from siblings like bsky_get_author_feed (which gets author posts) and bsky_get_timeline (which gets timeline posts). However, it doesn't explicitly mention Bluesky/AT Protocol context, which would make it fully specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate compared to other feed-related tools like bsky_get_author_feed or bsky_get_timeline, nor does it specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions fetching a feed but doesn't describe pagination behavior (implied by the cursor parameter), rate limits, authentication requirements, or what happens if the user doesn't exist. This leaves significant gaps for a tool that likely requires authentication and has pagination.
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, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and 4 parameters with 0% schema coverage, the description is incomplete. It covers the basic purpose but misses key contextual details like authentication needs, pagination behavior, and parameter explanations, making it minimally adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions the 'handle' parameter implicitly ('指定したユーザー' - specified user) but doesn't explain the purpose of 'limit', 'cursor', or 'acting_handle'. This leaves 3 of 4 parameters undocumented, failing to add meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('取得します' - get/fetch) and resource ('指定したユーザーの最新投稿フィード' - specified user's latest post feed), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like bsky_get_timeline or bsky_get_post_thread, which also retrieve feeds or posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like bsky_get_timeline (for the user's own timeline) or bsky_get_post_thread (for a specific post's replies). It only states what the tool does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does (get followers) without mentioning any behavioral traits like whether it's read-only, requires authentication, has rate limits, pagination behavior (implied by 'cursor' parameter but not explained), or what the output contains. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance. Every part of the sentence earns its place by conveying the core functionality.
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 that there is an output schema (which should document return values), the description doesn't need to explain outputs. However, with no annotations, 4 parameters (0% schema coverage), and a read operation that likely involves pagination and authentication, the description is incomplete. It covers the basic purpose but lacks crucial details about behavior and parameters, making it only minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the parameters have descriptions in the schema. The tool description does not mention any parameters, failing to compensate for this gap. It doesn't explain what 'handle', 'limit', 'cursor', or 'acting_handle' mean or how they affect the operation, leaving all 4 parameters undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '指定ユーザーのフォロワー一覧を取得します' (Get a list of followers for a specified user). It specifies the verb '取得します' (get) and the resource 'フォロワー一覧' (list of followers). However, it doesn't explicitly differentiate from sibling tools like 'bsky_get_follows' (which likely gets who a user follows rather than who follows them), so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons with related tools such as 'bsky_get_follows' or 'bsky_get_profile'. This leaves the agent without context for selecting this tool appropriately among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('取得します'), implying a read-only operation, but doesn't cover other behavioral aspects such as authentication requirements, rate limits, pagination behavior (hinted by 'cursor' parameter), or what happens with invalid inputs. The description is minimal and misses key operational details.
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, efficient sentence in Japanese: '指定ユーザーのフォロー一覧を取得します.' It's front-loaded with the core action and resource, with zero wasted words. Every part of the sentence directly contributes to stating the tool's purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 1 required, no annotations, but with an output schema), the description is minimally adequate but incomplete. The output schema likely covers return values, reducing the burden, but the description lacks context on usage, parameters, and behavioral traits. It meets a baseline for a read operation but doesn't fully address gaps from missing annotations and low schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema, which has 0% schema description coverage. It doesn't explain parameters like 'handle' (the user to query), 'limit' (number of results), 'cursor' (for pagination), or 'acting_handle' (context for authentication). With low coverage, the description fails to compensate, leaving parameters undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '指定ユーザーのフォロー一覧を取得します' (Get the follow list of a specified user). It uses a specific verb ('取得します' - get/retrieve) and resource ('フォロー一覧' - follow list), making the action unambiguous. However, it doesn't explicitly differentiate from its sibling tool 'bsky_get_followers', which retrieves followers rather than follows, though the distinction is implied by the tool names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'bsky_get_followers' (for followers) or 'bsky_get_profile' (for user details), nor does it specify prerequisites (e.g., authentication) or exclusions. Usage is implied by the purpose but lacks explicit context 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action ('get likes') without mentioning rate limits, pagination, authentication requirements, error conditions, or what the output contains (though an output schema exists). For a read operation with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose. It's front-loaded with no wasted words, 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?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is minimally adequate. The output schema reduces the need to explain return values, but the lack of behavioral context and parameter semantics leaves gaps. It meets a bare minimum but doesn't fully prepare an agent for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions '指定投稿' (specified post), which hints at the 'uri' parameter, but doesn't explain what a URI is in this context or mention the optional 'acting_handle' parameter at all. This leaves key semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '指定投稿のいいね一覧を取得します' translates to 'Get a list of likes for a specified post.' This is a specific verb ('get') + resource ('likes') combination. However, it doesn't explicitly differentiate from siblings like bsky_get_post_thread or bsky_get_author_feed, which might also return engagement data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), compare it to siblings like bsky_get_post_thread (which might include likes), or specify use cases (e.g., analyzing engagement). This leaves the agent to infer usage from the tool 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it retrieves lists but doesn't describe pagination behavior (implied by 'cursor' and 'limit' parameters), authentication needs, rate limits, or what happens if the user doesn't exist. For a read operation with multiple parameters, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), 4 parameters with 0% schema coverage, and no annotations, the description is minimally adequate but incomplete. It covers the core purpose but lacks parameter explanations and behavioral context, leaving the agent to infer details from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only mentions '指定ユーザー' (specified user), which maps to the 'handle' parameter, but doesn't explain 'limit', 'cursor', or 'acting_handle'. With 4 parameters total, this leaves 75% undocumented, failing to add meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('取得します' - get/retrieve) and resource ('指定ユーザーのリスト一覧' - specified user's list collection), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'bsky_get_list' (singular) or 'bsky_get_followers', but the focus on lists is clear.
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 doesn't mention sibling tools like 'bsky_get_list' (for a specific list) or 'bsky_get_followers' (for a different resource type), nor does it specify prerequisites or contextual constraints beyond the required 'handle' parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions authentication requirement, which is useful. However, it doesn't describe pagination behavior (implied by cursor parameter), rate limits, response format, or whether this is a read-only operation. For a tool with 3 parameters and output schema, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that communicates the core purpose and authentication requirement. Every word earns its place with no redundancy or unnecessary elaboration. It's front-loaded with the main 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?
Given the tool's moderate complexity (3 parameters, authentication requirement) and the presence of an output schema (which handles return values), the description covers the basic purpose and auth need. However, with no annotations and 0% schema coverage, it should provide more parameter guidance and behavioral context to be truly complete for an authenticated API call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides no information about any of the 3 parameters (limit, cursor, acting_handle). The description doesn't explain what these parameters do, their expected values, or how they affect the notification retrieval. This is inadequate given the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('取得します' - get/retrieve) and resource ('通知一覧' - notifications list) with the scope ('ログインユーザー' - logged-in user). It distinguishes from siblings like bsky_get_timeline or bsky_get_profile by specifying notifications. However, it doesn't explicitly differentiate from other notification-related tools (none exist in siblings), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions authentication requirement ('要認証'), which is a basic usage condition. However, it provides no guidance on when to use this tool versus alternatives like bsky_get_timeline for timeline updates or bsky_get_profile for user info. No explicit when-not-to-use or sibling comparison is included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions authentication requirement, which is helpful, but fails to describe other critical behaviors: whether this is a destructive/mutative operation (implied by 'creates'), rate limits, error conditions, or what happens upon success. For a post-creation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single Japanese sentence that directly states the core purpose and key requirement. Every word earns its place with zero waste or redundancy, making it front-loaded and efficient.
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 this is a mutation tool with no annotations, 0% schema description coverage, but with an output schema present, the description is minimally adequate. The authentication warning is crucial, but more behavioral context would be needed for full completeness. The output schema reduces the burden to explain return values, but the description still lacks sufficient operational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It provides no information about the 'text' parameter (content of the post) or 'acting_handle' parameter (optional user context). The description doesn't add any meaning beyond what the bare schema provides, failing to address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '新規投稿を作成します（要認証）' clearly states the action (creates a new post) and resource (post), distinguishing it from siblings like bsky_reply or bsky_repost which modify existing posts. However, it doesn't explicitly differentiate from other creation tools like bsky_create_list, leaving room for improvement.
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 mentions authentication is required ('要認証'), which provides some context, but offers no guidance on when to use this tool versus alternatives like bsky_reply for threaded responses or bsky_repost for sharing existing content. No explicit when-not-to-use instructions or sibling comparisons 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions searching a local database for Japanese posts, which implies read-only behavior and language filtering, but doesn't cover aspects like rate limits, authentication needs, error handling, or what 'local DB' entails. The description adds some context but is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's function. It's appropriately sized and front-loaded with no wasted words, 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?
Given the tool has an output schema (which reduces the need to describe return values) but no annotations and 0% schema description coverage, the description is incomplete. It covers the basic purpose but lacks parameter guidance, behavioral details, and sibling differentiation. For a search tool with undocumented parameters, this is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It doesn't mention any parameters or their semantics. With 2 parameters (keyword and limit) and no schema descriptions, the description fails to add meaning beyond the bare schema, leaving key usage details unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: searching Japanese posts stored in a local database. It specifies the verb 'search' and the resource 'Japanese posts', but doesn't differentiate from sibling tools like 'bsky_search_posts' which might search different scopes or languages. The description is specific but lacks sibling 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. It doesn't mention when to prefer this over 'bsky_search_posts' or other search-related tools, nor does it specify prerequisites or exclusions. The description only states what it does, not when 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?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'public posts' which suggests read-only access, but doesn't cover rate limits, authentication needs, pagination behavior (cursor usage), or response format. This is inadequate for a search tool with 4 parameters.
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 extremely concise - a single Japanese sentence that directly states the tool's function. There's no wasted language or unnecessary elaboration, making it efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search with pagination), no annotations, and 0% schema coverage, the description is insufficient. However, the presence of an output schema somewhat mitigates the need to describe return values. The description should explain more about the search scope and parameter usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It doesn't explain any of the 4 parameters (query, limit, cursor, acting_handle) or their purposes. The single sentence adds no parameter information beyond what's in the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('検索します' - searches) and resource ('公開投稿' - public posts), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'bsky_search_local_posts' or 'bsky_search_users', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'bsky_search_local_posts' or 'bsky_search_users'. The description only states what it does without context about appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions authentication requirement ('要認証'), which is valuable behavioral context. However, it doesn't disclose other important traits: whether this is read-only (implied but not stated), rate limits, pagination behavior (though cursor parameter hints at it), what data is returned, or error conditions. For a tool with 3 parameters and no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient Japanese sentence that communicates the core purpose and key constraint (authentication). It's appropriately sized for a simple retrieval tool, though it could be more front-loaded with parameter guidance. No wasted words, but could benefit from slightly more detail given the parameter count.
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 3 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. The output schema means return values don't need explanation, but the description should do more to explain parameter usage and behavioral context. For a timeline retrieval tool with pagination parameters, the description is incomplete but not entirely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. The 3 parameters (limit, cursor, acting_handle) are completely undocumented in both schema and description. The description doesn't explain what 'limit' controls, how 'cursor' enables pagination, or what 'acting_handle' represents. This fails to add meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('取得します' - get/retrieve) and resource ('ホームタイムライン' - home timeline) with the scope being for the logged-in user. It distinguishes from siblings like bsky_get_author_feed (author-specific) and bsky_get_timeline_page (page-specific), though not explicitly. However, it doesn't fully differentiate from all timeline/feed-related siblings like bsky_get_actor_feeds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'ログインユーザー' (logged-in user) and '要認証' (requires authentication), which suggests this tool is for authenticated users viewing their own timeline. However, it doesn't explicitly state when to use this versus alternatives like bsky_get_author_feed or bsky_get_timeline_page, nor does it provide exclusion criteria or prerequisites beyond authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses authentication requirement and summarization behavior, but lacks critical details: pagination mechanics (cursor usage), rate limits, error conditions, or response format. For a read operation with 5 parameters, this leaves significant behavioral gaps unexplained.
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, efficient sentence in Japanese that front-loads the core purpose. It wastes no words, though it could be slightly more structured (e.g., separating authentication note). Overall, it's appropriately concise for the tool's complexity.
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 has an output schema (which handles return values), 5 parameters with 0% schema coverage, and no annotations, the description is moderately complete. It covers authentication and summarization scope but misses parameter explanations and behavioral details like pagination. It's adequate as a starting point but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions summarization ('要約または全文'), which loosely relates to 'summary' and 'text_max_len' parameters, but doesn't explain 'limit', 'cursor', or 'acting_handle' at all. With 5 undocumented parameters, the description adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('取得します' - get/fetch) and resource ('ホームタイムライン' - home timeline), specifying it retrieves content either summarized or in full. It distinguishes from siblings like bsky_get_author_feed (author-specific) or bsky_search_posts (search-based), though not explicitly. However, it doesn't fully differentiate from bsky_get_timeline (similar function), keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching home timeline content with optional summarization, and notes authentication requirement ('要認証'). It doesn't provide explicit when-not-to-use guidance or name alternatives (e.g., vs. bsky_get_timeline or bsky_get_author_feed), leaving usage context somewhat implied rather than fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions authentication requirement ('要認証'), which is valuable context. However, it doesn't describe what happens after removal (e.g., whether it's reversible, confirmation messages, error conditions), rate limits, or permission requirements beyond authentication. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core action and key constraint (authentication). No wasted words or redundant information. However, it could be more front-loaded by explicitly mentioning the tool removes list items rather than just 'users from lists'.
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 this is a mutation tool with no annotations, 2 parameters (0% schema coverage), but with an output schema present, the description is moderately complete. The authentication requirement is helpful, but missing details about parameter meanings, behavioral outcomes, and error conditions leave gaps. The output schema existence means return values documentation isn't needed in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. The description mentions 'ユーザーをリストから' (user from list) which partially explains the purpose of 'listitem_uri' but doesn't clarify parameter meanings, formats, or relationships. No information about 'acting_handle' parameter is provided. The description adds minimal value beyond what's implied by the tool name.
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 ('削除します' - remove) and target resource ('ユーザーをリストから' - user from list), which is specific and unambiguous. It distinguishes from siblings like 'bsky_add_to_list' by specifying removal rather than addition. However, it doesn't explicitly mention what 'listitem_uri' represents, leaving some ambiguity about the exact resource being manipulated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the authentication requirement ('要認証'), suggesting this tool requires authenticated access. However, it doesn't explicitly state when to use this versus alternatives like 'bsky_delete_list' (which deletes entire lists) or 'bsky_unfollow' (which handles different relationships). No explicit guidance on prerequisites or exclusions is 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 provided, the description carries the full burden of behavioral disclosure. It mentions the authentication requirement ('要認証'), which is valuable context. However, it doesn't describe what 'repost' means behaviorally (e.g., does it share to the user's feed, notify the original poster, have visibility settings, or support undo operations?). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just one sentence in Japanese, front-loading the core action ('リポストします') and key constraint ('要認証'). There is zero wasted language, making it efficient despite its brevity. Every word earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with 3 parameters, no annotations, but an output schema exists), the description is incomplete. While the output schema may cover return values, the description lacks crucial details: it doesn't explain parameter meanings, behavioral implications of reposting, or error conditions. For a social media interaction tool, this leaves too much unspecified for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. The description mentions no parameters at all, failing to clarify what 'uri', 'cid', or 'acting_handle' represent or how they relate to reposting a '特定投稿'. This leaves all three parameters undocumented, creating a significant gap in understanding required inputs.
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 states the specific action ('リポストします' - reposts) and resource ('特定投稿' - specific post), making the purpose clear. It distinguishes from siblings like 'bsky_like' or 'bsky_post' by focusing on reposting rather than creating new content or liking. However, it doesn't explicitly differentiate from similar actions like sharing or forwarding, which might be implied in the Bluesky context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through '要認証' (requires authentication), suggesting this tool should be used when authenticated. However, it doesn't provide explicit guidance on when to use this vs. alternatives like 'bsky_post' for creating new content or 'bsky_like' for engagement. The authentication requirement is helpful but insufficient for full usage 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 the full burden of behavioral disclosure. It states the conversion function but doesn't describe error conditions (e.g., invalid handles), rate limits, authentication requirements, or what the output looks like. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's function. It's front-loaded with the core purpose and contains no unnecessary information, making it highly concise and well-structured.
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 has an output schema (which likely describes the return value), the description doesn't need to explain return values. However, with no annotations, 0% schema description coverage, and two parameters (one unexplained), the description is incomplete. It covers the basic purpose but misses key contextual details like parameter explanations and behavioral traits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'handle name' which maps to the 'handle' parameter, adding some semantic meaning. However, it doesn't explain the 'acting_handle' parameter at all, leaving half of the parameters undocumented. The description partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: converting a handle name to a DID. It uses specific verbs ('変換します' - converts) and identifies the resource (handle name to DID). However, it doesn't differentiate from sibling tools like bsky_get_profile or bsky_search_users that might also resolve handles indirectly, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication needs), context for the 'acting_handle' parameter, or how it differs from sibling tools like bsky_get_profile that might return DID information. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool destroys a login session, implying a mutation with side effects, but lacks details on permissions needed, whether it's reversible, rate limits, or what happens to other sessions. This is a significant gap for a destructive operation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's function without redundancy. It's appropriately sized and front-loaded, 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 tool's complexity (destructive operation), lack of annotations, and presence of an output schema (which may cover return values), the description is minimally adequate but incomplete. It covers the basic action but misses critical behavioral details like authentication requirements or error conditions, leaving gaps for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description specifies that the 'handle' parameter identifies the session to destroy, adding meaning beyond the schema's minimal coverage (0%). With only one parameter, the description effectively clarifies its purpose, though it doesn't detail format constraints (e.g., handle syntax).
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 ('destroy login session' / logout) and the target resource ('specified handle'), which is specific and unambiguous. It distinguishes from siblings like bsky_login (login) and bsky_refresh_session (refresh), but doesn't explicitly contrast with other session-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites (e.g., must be logged in first), or consequences. It doesn't mention sibling tools like bsky_login for re-authentication or bsky_refresh_session for session renewal, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses that existing sessions are logged out before re-login, and that credentials can be sourced from environment variables if not provided. It doesn't mention rate limits, error conditions, or session persistence details, but provides more than minimal 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 well-structured and appropriately sized: a clear purpose statement followed by two behavioral notes in bullet points. Every sentence earns its place with no redundancy or fluff. The information is front-loaded with the core functionality stated first.
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 complexity (authentication with side effects), no annotations, and an output schema (which handles return values), the description is reasonably complete. It covers the main behavior, parameter handling, and environment integration. However, it lacks details about error cases, session duration, or what the output contains.
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 input schema has 0% description coverage, so the description must compensate. It explains that handle/password can be unspecified (None) and will be completed from environment variables, listing the specific variable names and formats. This adds meaningful semantics beyond the schema's basic type definitions, though it doesn't detail validation rules or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Blueskyにログインしてセッションを開始します' (Login to Bluesky and start a session). It specifies the verb (login) and resource (Bluesky session), but doesn't explicitly differentiate from sibling tools like bsky_refresh_session or bsky_logout, which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance: it mentions handling existing sessions (logout then re-login) and environment variable fallback for credentials. However, it doesn't explicitly state when to use this vs. alternatives like bsky_refresh_session or bsky_logout, nor does it mention prerequisites or exclusions.
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:

[![mcpbluesky MCP server](https://glama.ai/mcp/servers/awaku7/mcpbluesky/badges/card.svg)](https://glama.ai/mcp/servers/awaku7/mcpbluesky)

Score Badge

Copy to your README.md:

[![mcpbluesky MCP server](https://glama.ai/mcp/servers/awaku7/mcpbluesky/badges/score.svg)](https://glama.ai/mcp/servers/awaku7/mcpbluesky)

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/awaku7/mcpbluesky'

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