bluesky-mcp

Server Quality Checklist

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

Latest release: v1.1.1
Disambiguation5/5
Each tool maps to a distinct resource and action, from account management (follow, mute, block) to read operations (get_timeline, get_feed, get_author_feed). Even similar tools like get_followers vs get_follows are clearly differentiated by descriptions. No two tools appear to do the same thing.
Naming Consistency5/5
Tool names follow a predictable verb_noun pattern: get_* for reads, search_* for searches, create_*/delete_* for post lifecycle, and paired verbs like follow/unfollow, mute/unmute, block/unblock, like/unlike, repost/unrepost. The naming is uniform and easy to anticipate.
Tool Count2/5
At 41 tools, the server exceeds the 25+ threshold that signals an overgrown surface. While each tool serves a distinct purpose, the sheer number makes the toolset heavy for agents to navigate and select from efficiently. This could have been consolidated somewhat without losing core functionality.
Completeness4/5
The toolset covers the full social media lifecycle on Bluesky: posting, threads, likes, reposts, follows, blocks, feeds, lists, notifications, and search. Notable gaps include direct messages and list creation/management, but these are peripheral to the core workflows an agent typically needs.
Average 4/5 across 41 of 41 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 75 commits in the last 12 weeks
- Last stable release on September 3, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context such as pagination, ordering, or the meaning of the cursor parameter, so it contributes little beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, with no filler words, but it is under-specified rather than appropriately concise. It conveys only the basic function and lacks useful structure or context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, no output schema, and a one-line description, the tool definition is incomplete. It does not explain return value format, pagination behavior, or how the 'account' parameter affects execution, which an agent needs for correct invocation.
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 schema covers 75% of parameters with descriptions, but the tool description itself mentions no parameters. The description does not compensate for the remaining 25% (cursor is undocumented) and adds no meaning 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 states a specific verb ('List') and resource ('accounts on a list'), making its core purpose clear. It distinguishes from sibling tools like get_list_posts by focusing on accounts, though it does not explicitly contrast with them.
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. There is no mention of scenarios, exclusions, or references to sibling tools such as get_list_posts or get_list_members as an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond what the annotations already disclose (readOnlyHint=true, idempotentHint=true, destructiveHint=false). It does not mention pagination, authentication needs, rate limits, or any output formatting. Unlike the high-calibration example, it provides no extra context such as filtering scope or side effects.
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, short sentence with no redundancy or wasted words. It fully captures the tool's purpose without padding, making it easy to read and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with four well-documented parameters, the description is adequate but minimal. It tells the agent what the response conceptually contains (accounts that reposted) but does not explain cursor pagination mechanics beyond what the schema already provides. Since there is no output schema, a bit more context about the structure of results could improve completeness, but the tool is not complex.
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?
Input schema has 100% description coverage for all four parameters (uri, limit, cursor, account), so the schema already carries the semantic weight. The description adds no parameter-specific meaning, which aligns with the baseline of 3 for high schema coverage.
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 'The accounts that reposted a specific post' clearly identifies the resource (reposters of a post) and distinguishes it from sibling tools that operate on likes or quotes. While it lacks an explicit verb like 'fetch' or 'list', the meaning is unambiguous and the scope is specific.
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 a use case (e.g., when you need to see which accounts reposted a post) but does not explicitly state when to use this tool over alternatives or when not to use it. There are no 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the operation is not read-only (readOnlyHint: false), is idempotent, and is not destructive. The description adds a small behavioral insight: the effect is making an account's posts visible again. This is useful but not extensive, so a score of 3 is appropriate given 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, focused sentence with no filler words. It is appropriately sized and conveys the core action efficiently.
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 tool with two parameters, full schema coverage, and safety-related annotations, the description is minimally adequate. However, it omits usage context such as the relationship to mute_account or when this action is appropriate, making it less complete than ideal.
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?
Input schema coverage is 100% for both 'actor' and 'account', each with clear descriptions. The description itself adds no extra parameter meaning, so the baseline of 3 applies.
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 'Stop hiding an account's posts' clearly identifies the tool's function as reversing a mute. It is specific and avoids tautology, but it does not explicitly name the sibling mute_account tool or mention how it differs from blocking/unblocking, so it lacks 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like mute_account or unblock_account. There is no mention of prerequisites or scenarios, leaving the agent to infer usage from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the useful behavioral detail that results are 'newest first' but says nothing about pagination, rate limits, or error 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 a single clear sentence with no wasted words. It is appropriately concise, though it could have mentioned the need for a post URI without significantly reducing 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?
For a simple read-only tool, the description plus schema and annotations cover most operational needs. However, it lacks usage guidance among siblings and does not hint at the output shape beyond 'accounts', leaving some ambiguity for a tool without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents all four parameters with descriptions (100% coverage). The description adds no extra meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving the accounts that liked a specific post, with ordering ('newest first'). This distinguishes it from get_liked_posts (posts liked by a user) and get_reposted_by (accounts that reposted), so an agent can select it correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that a post URI is required, nor does it reference sibling tools like get_liked_posts or get_reposted_by for contrasting 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?
The only behavioral disclosure is 'Following twice is harmless', which merely restates the idempotentHint annotation. No additional behavioral context (e.g., effects on notifications, follower counts, permission requirements) is provided beyond what annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first explains the operation, second adds a helpful idempotency note. No wasted words, clearly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the essential call semantics. However, it omits any explicit mention of side effects or return behavior, though these are largely implicit for a follow operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already well-documented. The description's 'by handle or DID' adds no new information beyond the actor parameter's existing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states the exact verb 'Follow' and resource 'an account', with the specific input format 'by handle or DID'. It clearly distinguishes from sibling tools like unfollow, mute, and block.
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 ('Follow an account') but does not explicitly state when to use this tool versus alternatives like mute or block. The idempotency note offers some guidance but no exclusion criteria.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it specifies the ordering ('newest first') and the automatic pagination past Bluesky's 100 ceiling, which directly affects how results are returned and how limit/cursor behave. This goes beyond what annotations provide, earning a solid score.
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 two concise sentences with zero filler. The core function is front-loaded ('Accounts that follow a given account'), followed by a brief, important behavioral note about pagination. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with a clear schema, the description covers the essential behavior (what is returned, ordering, pagination). It does not explain the return format, but the function's output is self-evident (a list of accounts). The lack of an output schema means the description could have added a bit more detail, but the overall definition is complete enough for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, with descriptions for actor, limit, and account, leaving cursor undocumented. The description does not explicitly explain any parameters, but it mentions automatic pagination which indirectly clarifies limit and cursor behavior. Since the schema already covers most parameters, a baseline of 3 is appropriate; the description adds marginal value but does not compensate for the undocumented cursor.
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 'Accounts that follow a given account', which clearly identifies the tool as listing followers of a given actor. It also adds ordering ('newest first') and a key pagination behavior. However, it does not explicitly distinguish itself from the sibling tool 'get_follows', leaving some potential ambiguity for an agent comparing them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_follows' or 'search_actors'. It simply describes what the tool does without any contextual cues such as 'use this when you need the list of accounts that follow X' or 'for accounts that X follows, use get_follows instead'. An agent is left to infer usage from the name and title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds minimal behavior beyond that—only that results are 'in order'. It doesn't disclose pagination, limits, or other operational details, which is acceptable given annotations but adds little extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first sentence front-loads the resource and ordering; the second adds actionable next steps. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one optional parameter, the description covers what the tool returns and how to use the results. Lacking an output schema, it doesn't describe response structure, but the mention of URIs gives a hint. Minor gaps remain around pagination or account scoping, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the 'account' parameter is 100% complete, so the schema carries the full parameter documentation. The tool description doesn't add further parameter meaning; it repeats 'connected account' context already implied by the parameter description. Baseline 3 applies.
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 verb ('list') and resource ('feeds and lists pinned to a connected account's home screen'), and mentions ordering. It also hints at downstream usage with get_feed/get_list_posts, which helps distinguish it from other feed-related tools, though it doesn't explicitly contrast with sibling tools.
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 suggesting to pass returned URIs to get_feed or get_list_posts, but it doesn't state when to choose this tool over alternatives or when not to use it. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is read-only, idempotent, and non-destructive. The description adds useful behavioral context: the feed is ordered newest-first and requires a connected account, but it does not disclose output shape or pagination behavior beyond what the parameter schema already states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences carry all the essential context: what the feed contains, its ordering, the alternative parameter mode, and the account requirement. There is no filler or repetition.
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 rich parameter schema and read-only annotations, the description covers the remaining invocation requirement (connected account) and clarifies the mode switch. The lack of an output schema is a minor gap, but the tool's purpose and return concept are clear from the home-timeline phrasing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four parameters explained in the input schema. The description's mention of since_hours restates what the schema already says, so it adds no additional parameter-level meaning.
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 title and description clearly identify the tool as reading the user's home timeline ('Your following feed, newest first'), which distinguishes it from custom-feed and author-feed siblings. However, it does not explicitly name or contrast any sibling tool, so it stops short of full differentiation.
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 gives a concrete usage choice for since_hours versus a fixed post count and states the connected-account prerequisite. It does not provide when-not-to-use guidance or name alternatives such as get_feed or get_author_feed, so the cross-tool routing is left implied.
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?
Description discloses a key behavioral side effect: 'Any follows the block severed do not come back. Both sides have to follow again.' This adds value beyond annotations by warning that unblocking does not restore severed follow relationships. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, with the primary action front-loaded and the critical side effect immediately after. Every word earns its place; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with annotations covering idempotency and destructiveness, the description provides purpose and side effects. However, it lacks usage context and any mention of return value or error conditions. Acceptable but minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already well-documented in the schema. The description adds no additional meaning about the parameters, such as formats or edge cases. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a clear verb and resource: 'Remove a block.' This directly identifies the operation and distinguishes it from siblings like unfollow or unmute. The title reinforces the purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like unfollow or unmute_account. The description only states the action but no context, prerequisites, or exclusions. Agents must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already mark the operation as read-only, idempotent, and non-destructive, the description adds meaningful behavioral detail: it works without credentials and the follow-relationship fields only appear when a connected account is available. This goes beyond what annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the core action and then lists return content. Every clause adds value without redundancy or extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two well-documented parameters and no output schema, the description provides a clear picture of what is returned and under what conditions. It lacks some potential edge-case detail but is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover both parameters fully (100% coverage), so the schema already explains meaning and usage. The description's mention of 'one or more accounts' only paraphrases the actors parameter and adds no new semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns the full profile for one or more accounts and enumerates specific content: bio, follower counts, labels, and follow relationships. This distinct resource and content list differentiates it from siblings such as get_followers or get_author_feed.
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 prefer this tool over alternatives or when not to use it. The note about working without credentials is a credential context, not a selection criterion, and no sibling comparisons are made.
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 readOnlyHint and idempotentHint already covering the safety profile, the description adds behavior beyond annotations by specifying newest-first ordering and the list-feed scope. It does not discuss pagination or errors, but the annotation coverage lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: the first states what the tool returns and its ordering, and the second tells the agent how to construct the required parameter. No filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list feed with one required parameter, the description plus schema covers core invocation needs. It does not explain cursor-based pagination or response shape, but no output schema is present and the operation is simple.
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 schema already documents list, limit, and account; the description adds practical sourcing instructions for the required list parameter and clarifies accepted input forms. Cursor still lacks explanation in both schema and description, but the core parameter is enriched.
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 says this returns posts from a curated list in newest-first order, and the title reinforces the action as reading a list feed. The curated-list scope separates it in meaning from sibling feed tools, though it does not explicitly name or contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides useful setup guidance by telling the agent to take the list URI from get_pinned_feeds or a bsky.app/lists link. However, it does not explicitly state when to prefer this over similar feed tools like get_timeline or get_feed, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the pagination behavior ('Pages automatically') and the limit/cursor semantics, which are not in the annotations. However, it does not disclose the return format or whether posts include full thread context, which for a feed-reading tool could be useful but is not critical given the schema and simplicity.
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 two short sentences, front-loaded with the core action and resource format, and the finding alternatives come after. Every sentence earns its place; there is no filler or repetition of schema fields.
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?
The tool is a read-only list retrieval with no output schema, and the annotations already carry the safety profile. The description covers the input format, pagination behavior, and account selection, which are the main operational concerns. It lacks an explicit return-value description, but for a list tool this is minor; a 4 is generous but fair given the strong alignment with expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, meaning the feed, limit, and account parameters already have descriptions. The description adds marginal value by confirming the pagination ('Pages automatically') and tying the account parameter to list_accounts, but it doesn't add format or syntax details for the feed URI beyond what the schema says. The cursor parameter remains undocumented, but the description's mention of pagination partially compensates. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' with a specific resource 'posts from a custom feed' and identifies the feed by its at:// URI or bsky.app link. It distinguishes the tool from siblings like get_timeline and get_author_feed by specifying 'custom feed' and by naming the search/owned-feeds alternatives, making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context: it says to find a feed with search_feeds or get_pinned_feed, which tells an agent when this tool is appropriate and when those alternatives are better. It falls one point short of a 5 because it doesn't explicitly say when NOT to use it (e.g., for a raw timeline), but the named alternatives imply the boundary.
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?
Annotations already establish read-only, open-world, idempotent, and non-destructive behavior. The description adds the useful 'Pages automatically' behavior, which goes beyond what the annotations state.
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 very short and front-loads the core purpose, then adds the key pagination behavior. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with a documented required parameter and safety annotations, the description is nearly complete. It could mention the return shape, but the tool name and title make the expected output clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes actor, limit, and account, leaving only cursor without a description. The description contributes no parameter-level meaning, but schema coverage is strong enough that the gap is minor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly indicate the tool lists the accounts a given account follows. It is easily distinguished from the sibling get_followers, which lists followers instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool to call for seeing an account's follow list, but it does not explicitly state when to prefer it over get_followers or other list tools. The 'Pages automatically' note is behavior, not usage guidance.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by stating the ordering ('newest first') and the practical distinction between notification types (which need answering), which is helpful beyond what annotations provide.
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 two sentences with no fluff. The first sentence states the content and ordering; the second adds a practical filtering tip. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with comprehensive annotations and high schema parameter coverage, the description is nearly complete. It omits explicit mention of pagination behavior, but that is disclosed in the schema's limit description ('Pages automatically'). The only slight gap is the lack of a note about the return format, which is acceptable since no output schema is provided.
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 80%, so most parameters (limit, account, reasons, unread_only) already have descriptions in the schema. The description reinforces the 'reasons' parameter's filtering purpose but adds no new semantic detail beyond that. Since coverage is high, the baseline of 3 applies.
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 that the tool retrieves the user's notifications (likes, reposts, follows, mentions, replies, quotes) and orders them newest first. It is specific about the resource and the verb, but it does not explicitly distinguish itself from sibling tools like get_unread_count or mark_notifications_seen, so it loses one point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear contextual guidance: it explains that filtering by 'mention' and 'reply' is useful for surfacing items that actually need an answer. However, it does not mention alternative tools for unread counts or marking as seen, so the when-not-to-use guidance is incomplete compared to a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it is a safe read. The description adds the batching note — one call for a list, which is useful scale context, but there's no mention of output format, ordering, or per-account failure handling. Beyond annotations, the description contributes limited but relevant context.
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 two sentences, begins with the core purpose, and packs the main request/response shape (per account, follows/follows-back) and the main usage tip (batch before bulk operations) without any waste. Highly legible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only check with a clear input schema and no output schema, the description conveys what the tool does and when to reach for it. It omits the exact output shape, but the semantics of 'follows them' and 'follows back' are understandable and there is little hidden behavior for a read-only tool. A slightly richer description could mention the response for each actor (e.g., booleans), but the gap is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (actors, account), and the description does not add any parameter-specific semantics. With 100% schema coverage, this is the baseline 3; no extra meaning is provided beyond what the schema already gives.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise verb ('check') and resource ('follow relationships'), and it tells the agent exactly what it returns — whether a connected account follows each named account and whether they follow back. It clearly distinguishes itself from sibling tools like get_followers or get_follows by focusing on relationship status, not lists of follows/followers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it: before a bulk follow or unfollow, and discourages using it to read a profile every time. It names an alternative approach (reading profiles via a profile tool, likely get_profile), though it doesn't explicitly rule out other tools like get_followers. This is solid usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior, so the description need not repeat that. It adds a hint about the 'actor' behavior and the suggestion basis, but does not disclose other operational details (e.g., how suggestions are generated for the logged-in user, rate limits). Given the strong annotation coverage, this is acceptable but not rich.
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 two concise sentences, front-loading the core function and then adding the key actor nuance. Every word contributes meaning, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with full schema coverage and no output schema, the description provides sufficient context. It explains the main purpose and the actor special case. Minor omission: it doesn't mention the 'account' parameter for multi-account scenarios, but that is fully covered in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the schema already explains all parameters. The description adds no extra meaning beyond what the schema states, which is the baseline expected. No reason to score higher.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: returning accounts Bluesky suggests following. It highlights the actor parameter's special behavior (finding similar accounts), which distinguishes it from related tools like follow or search_actors. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical usage context: with an actor, it finds similar accounts and labels that as 'the better way to find a niche.' This implies when to use the tool (discovery) but does not explicitly exclude alternatives or mention when not to use it. Slight gap for not referencing sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read‑only safety is well covered. The description adds behavioral context beyond the annotations: it says the tool works without credentials (auth autonomy), and it tells the agent the response will include a feed link for each trending topic. It does not disclose pagination or further details about the feed link's usage, but that's a minor omission given the 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, front‑loaded sentence that states the core output (trending topics with feed links) and then adds a crucial caveat (works without credentials). It contains no filler, no redundancy, and every word carries meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the annotations that already define its safety and idempotency, the description is complete enough: it tells the agent exactly what will be returned (feed links) and the auth requirement. Minor gaps like the exact response structure or pagination are left out, but they are not critical for an agent to call this tool correctly, as the schema covers all parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all three parameters (limit, account, include_suggested) with explicit descriptions, so the schema coverage is 100%. The description does not add any extra details about these parameters, but it also doesn't need to — the schema is self‑sufficient. Baseline 3 is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('get') and a specific resource ('current trending topics on Bluesky'), and it adds the detail that each item includes a feed link showing the posts behind it. This distinguishes it from other read operations like get_feed or get_timeline, which are about specific feeds or timelines, whereas trends are a broader, public snapshot.
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 its use when the caller wants current trending topics, but it does not explicitly contrast it with alternatives or state when not to use it. It does note that it works without credentials, which serves as a contextual, but it doesn't direct the agent to prefer it over other similar tools in specific situations. There's no explicit guidance on when to pick this over get_feed or search_posts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the description doesn't need to restate them. It adds context about being 'one cheap call', which is useful. It doesn't detail what 'seen' means or how the count is calculated, but the annotations are sufficient for a baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the purpose front-loaded and the recommended usage immediately following. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only count tool with zero required parameters and no output schema, the description is complete enough to invoke correctly. The only minor gap is not mentioning the output format, but the lack of an output schema makes that less critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description doesn't need to add parameter details. The description does not go beyond the schema, but since the schema covers everything, a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does—'How many notifications have arrived since you last marked them seen'—which uses a specific verb and resource, and distinguishes it from related tools like get_notifications and mark_notifications_seen.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use it ('before you pull the full list') but does not explicitly exclude alternatives or mention when not to use it. The sibling tool get_notifications exists, so differentiating it further would have earned a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the contextual behavior that the job 'usually finishes on its own', which is helpful but does not detail return states or poll semantics. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and conditional usage. Every clause earns its place, and there is zero redundancy beyond the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only status checker with fully covered parameters and complete annotations, the description is nearly sufficient. It lacks explicit mention of output shape or error handling, but no output schema exists and the tool's low complexity makes those less critical. The guidance about when to use it is complete enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, and both parameters (job_id, account) have descriptions. The tool description adds no new parameter detail beyond what the schema provides, but the schema itself is self-sufficient. Baseline 3 is appropriate because the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Check a Bluesky video transcoding job by id'), making the tool's purpose unambiguous. It clearly differentiates from nearby siblings like create_post by explaining it is a status-check follow-up. The title and description align.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Only needed when create_post reported that a video was still processing when it gave up waiting,' which gives a clear when-to-use. It also notes 'The job usually finishes on its own,' implying it is often unnecessary, but it does not name an alternative tool or explicitly map to a fallback action. This is clear guidance with a minor gap in explicit alternatives.
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?
The annotations already provide idempotentHint, so the idempotency is known. The description adds the specific behavior that a duplicate like returns the existing like instead of creating a second one, which is beyond annotations. It also clarifies the input URI formats, which is useful for actual invocation.
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 two sentences with no filler. It front-loads the core action, then immediately provides input format and important behavioral nuance. Every sentence earns its place, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description provides enough to invoke the tool correctly: what to pass, the idempotency behavior, and a hint about the return (existing like). It does not explain the full return structure, but for a single like action this is sufficient. It might have mentioned the account parameter, but that is already in the schema with 100% coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both 'uri' and 'account' are already described in the schema. The description only repeats the URI format without adding new meaning (e.g., no example usage or edge conditions). Therefore, it adds little beyond the schema, sustaining the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'like' and the resource 'post', and further specifies the accepted input formats (at:// URI or bsky.app link). This distinguishes it from sibling tools like unlike_post, repost, or delete_post, making its purpose unmistakable.
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 gives some usage context by noting that liking twice is harmless and returns the existing like, implying that re-calling is safe. However, it does not explicitly compare with alternatives (e.g., unlike_post) or state conditions for when to use this tool versus others, so guidance is 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?
Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds non-obvious details: it works without credentials and returns each account's bio and follower counts specifically to help distinguish real accounts from impersonators, enhancing the transparency beyond annotation flags.
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?
Three short sentences with no filler. The first states the core action, the second covers the credential requirement, and the third explains the output value and intended use. The structure is front-loaded and each sentence justifies its inclusion.
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?
The description covers purpose, access requirements, and the most relevant return fields (bio and follower counts), giving an agent enough to judge when to use it. The absence of an output schema makes the incomplete return structure a minor gap, but the parameter schema and concise summary are sufficient for a read-only search tool.
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 75%, and the schema itself describes q, limit, and account. The tool description adds meaning to q by specifying it accepts a name, handle, or bio keyword. However, cursor remains undocumented, and the description does not elaborate on limit or account beyond the schema, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with "Find Bluesky accounts by name, handle or bio text," which names a specific action and resource. This clearly distinguishes it from sibling tools like search_posts and search_feeds, which target other object types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context ('Works without credentials') and highlights a use case (spotting impersonators), but it never explicitly contrasts this tool with alternatives or states when not to use it. Usage must be inferred rather than directly guided.
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?
Annotations already provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false, establishing the operation's safety profile. The description adds context about how the like record is discovered from the post's viewer state, which is useful beyond annotations and clarifies the input requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The action is front-loaded, and the second sentence efficiently explains why only the post is needed, eliminating potential confusion about a like parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description combined with annotations covers the essential context for a correct call. It lacks explicit failure-mode disclosure, but the idempotentHint mitigates that need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented there. The description adds a useful hint that only the post URI is needed, reinforcing the minimal input, but does not go beyond the schema's parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'remove your like from a post.' It clearly states the action and clarifies that only the post URI is needed, not the like record itself. This uniquely identifies the tool's purpose and differentiates it from like_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you want to remove a like) but does not explicitly mention alternatives or when not to use it. The sibling like_post is present but not referenced, leaving the choice an agent must infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, which cover the key behavioral traits. The description adds no additional context such as permissions, side effects, or error conditions, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It front-loads the action and resource, making it instantly understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple undo operation with only two parameters and full schema coverage, the description plus annotations provide sufficient context. It does not explain edge cases like absence of an existing repost, but this is minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with clear descriptions for 'uri' and 'account'. The tool description adds no extra parameter detail, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove your repost of a post' uses a clear verb and resource, exactly matching the tool's purpose. It is easily distinguished from its sibling 'repost', which performs the opposite action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the operation's intent clear ('remove your repost'), which implicitly tells an agent when to use it: after a repost exists. However, it does not explicitly mention when to use an alternative or provide exclusion conditions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior, so the description does not need to restate safety. It adds useful context about returning ancestors and replies, but it says 'everything above it' without acknowledging the parent_height/depth limits, and it does not describe output ordering or truncation 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 three short sentences with no wasted words. It front-loads the core behavior, then adds accepted input forms, then gives the practical usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with full parameter documentation, annotations for safety, and no output schema, the description explains what will be returned (post, ancestors, replies) and the canonical use case. An agent has enough information to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and all four parameters are documented with meaningful descriptions. The tool description adds little beyond restating that the URI can be an at:// URI or bsky.app link, so the schema carries the parameter-semantics burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as reading a post plus its surrounding conversation, and it explicitly defines the scope as everything above the post and replies below it. This distinguishes it from sibling read tools like get_timeline, get_author_feed, and get_post_likes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit use case: 'Use this before replying, so the reply lands with context.' This tells the agent when to invoke the tool, though it does not mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
在已有注释（idempotentHint=true、destructiveHint=false等）的基础上，描述额外说明了内部机制（从viewer state查找记录），这增加了对调用行为的具体理解。没有矛盾之处，且提供了超越注释的细节。
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?
两句话结构紧凑，第二句解释了为何只需一个参数，有价值。第一句与标题略有重复，但整体没有冗余词汇，长度恰当。
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?
对于这个简单操作，结合注释和schema，描述足以让代理正确调用。虽然没有提及返回结果（因为无输出schema），但操作本身是单向的，不影响调用。唯一可补充的是account参数的默认行为，但schema已覆盖。
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对两个参数（actor和account）的说明覆盖率100%，描述中'所以只需要handle'与actor参数对应，但并未在schema之外增加新的参数含义或格式细节。按规则，schema覆盖高时基线为3。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述以具体动词'Stop following'开头，明确操作对象是'an account'，与兄弟工具如follow、mute等形成清晰区别。虽然没有显式命名替代工具，但动作本身无歧义。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述解释了它通过viewer state找到自己的follow记录，因此只需提供handle，这隐含了使用场景——当你有handle时即可调用，无需额外ID。但未明确说明与其他工具（如unfollow与unmute）的选择条件，不过从语境上足够清晰。
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?
Annotations already declare destructiveHint=true, and the description adds concrete behavioral details: the deletion cannot be undone, does not remove from feeds/caches, and requires explicit confirmation. These go beyond the annotation flags, giving the agent realistic expectations.
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?
Three concise sentences front-load the key facts: what is deleted, irreversibility, cache caveat, and confirmation requirement. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, but for a delete operation the description covers the critical aspects: what is deleted, irreversible consequences, cache behavior, and the need for confirmation. Given the parameter schema and annotations, this is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description reinforces the confirm requirement but does not add extra meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete') and resource ('one of your own posts'), clearly distinguishing it from siblings like unrepost or unlike_post. It also clarifies scope ('your own posts') and confirms destructive intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says this deletes a post and cannot be undone, implying it should be used when the user wants permanent removal. It doesn't name alternatives (e.g., unrepost) but the 'one of your own posts' scope and destructive warning provide adequate context for an agent.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral details: 'newest first' ordering, automatic pagination (implied by 'Pages automatically' in the schema but reinforced by the description's simplicity), and credential-free access. It does not overpromise side effects and aligns with the read-only annotation.
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 two sentences and front-loads the core behavior ('Posts by one account, newest first') before giving auth context and filter usage. Every clause earns its place, with no redundant phrasing or restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list-retrieval tool with read-only annotations, the description is adequate: it states scope, ordering, credential requirements, and filter semantics. It does not describe the return format, but with no output schema and a straightforward list result, this is a minor gap. The presence of 7 parameters is mitigated by high schema coverage, so the description need not repeat everything.
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 86%, so the schema already documents most parameters. The description adds meaningful guidance for the 'filter' parameter, explaining the practical difference between 'posts_no_replies' and others. However, it does not elaborate on other parameters like 'since_hours' or 'include_pins', which are already well-described in the schema. This is a solid baseline with a slight boost for the filter clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' with a clear resource ('an account's posts'), states the ordering ('newest first'), and distinguishes itself from sibling tools by clarifying it shows one account's posts. The filter guidance further sharpens the purpose by separating original posts from replies/reposts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it works for anyone with or without credentials, which helps with auth context. It also gives a concrete use case for the filter ('posts_no_replies is what you want when studying how someone writes'), implying when to choose this option. It does not explicitly state when to prefer other sibling tools like get_timeline or get_feed, but the scope is clear enough.
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?
Beyond the readOnlyHint annotation, the description adds ordering ('newest first') and a critical scoping constraint (only works for your own accounts). These disclose behavior not covered by structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences, first stating the primary function and second adding a necessary constraint. No fluff; both sentences earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description sufficiently conveys what the operation returns (list of liked posts, newest first). However, it omits pagination details (cursor mechanism) which an agent might need, but that is partially covered by the parameter schema.
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 67%, with limit and account documented. The description mentions 'connected account' which reinforces the account parameter, but it does not add details about cursor pagination or error handling. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns posts a connected account has liked, newest first. The verb 'read' and resource 'posts you have liked' differentiate it from sibling tools like get_post_likes (which likely list likers of a specific post).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit conditions: 'Only works for your own accounts' and explains why ('because Bluesky does not expose anyone else's likes as a feed'). It does not explicitly mention alternatives, but the restriction guides when to use this tool over others.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to repeat safety traits. It adds useful behavioral context by revealing that the output contains URIs usable as identifiers for the get_list_posts and get_list_members tools, which is not derivable from the annotations alone.
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 compact and front-loaded: the first sentence states the core purpose, and the second sentence is a focused, pragmatic note on how to use the results. No wasted words or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool, the description is complete enough: it defines the contained resource and tells the agent how to chain the result into sibling tools. The lack of an output schema is mitigated by the URI-pointer hint, though a short note on the list object shape would have made it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides thorough descriptions for all four parameters, yielding full 100% coverage. The description adds no parameter-specific detail, which is acceptable at the baseline of 3 since the agent can rely on the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists curated lists an account has created, a specific verb+resource. It distinguishes itself from related get_list_posts and get_list_members by describing those as separate follow-up operations on the returned URI, avoiding confusion without even needing to open the schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It directly tells the agent what to do after obtaining lists—pass a returned URI to get_list_posts or get_list_members. It does not explicitly state when to avoid this tool vs alternatives, but the workflow guidance is clear and effectively frames the tool as the entry point to list-related operations.
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the behavioral nuance that quotes carry commentary, which is not in the annotations, helping the agent anticipate the kind of content returned. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A two-sentence description with zero wasted words. It front-loads the core purpose and adds a valuable distinguishing trait, and every clause serves a function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with a fully described schema and strong annotations, this description is sufficient. It states what is returned, hints at the use (argument discovery), and differentiates from reposts. The absence of output schema is fine because the result is a list of posts. No critical information is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage of all four parameters (uri, limit, cursor, account) with a description for each. The description adds no additional parameter-level details, so the baseline of 3 is appropriate given the structure carries the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Posts that quote a specific post' with a specific verb (get) and resource (quotes). It also contrasts quotes with reposts, distinguishing from siblings like get_reposted_by and indicating the semantic purpose (commentary). This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an implicit usage context: 'This is where the argument about a post usually lives: quotes carry commentary, reposts do not.' This signals that you use this to see quote commentary rather than reposts, but it does not explicitly name sibling tools or give explicit when-not-to-use conditions. The guidance is clear, though indirect.
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?
Annotations already cover readOnly, openWorld, idempotent, and non-destructive behavior. The description adds that it works without credentials, which is useful authentication context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences each earn their place: definition, usage direction, and authentication note. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with rich annotations and full schema coverage, the description is complete. It even explains the follow-up action with get_feed, which an agent needs to fully use the result. The lack of an output schema is partially mitigated by the URI hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents q, limit, and account. The description adds no parameter-specific details but implies that results contain feed URIs for use with get_feed; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description defines the verb 'Find' with a specific resource 'custom feeds' and clarifies that these are algorithmic feeds published on Bluesky. It also contrasts with get_feed, making the tool's purpose distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: search for feeds, then pass a feed's URI to get_feed. It implicitly distinguishes from get_feed and search_posts, though it doesn't explicitly state when not to use it or list alternatives.
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?
Adds useful behavioral context beyond annotations: clarifies the post is already published and that 'existing replies stay unless you hide them'. This is genuinely informative and does not contradict the annotations (readOnlyHint=false matches the mutation described).
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?
Three short sentences with zero waste. The primary purpose is front-loaded, the secondary capability follows, and the usage context closes. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 4 parameters and no output schema, the description explains what it does and when to use it, and the schema covers parameter details. It could mention side effects more explicitly, but the combination of description and annotations is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are fully documented in the schema. The description adds marginal value by paraphrasing the 'who' and 'hide_replies' purposes, but it does not provide additional semantics beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Change') and resource ('existing posts, after it is already published'), and clearly distinguishes from siblings by focusing on reply permissions after publication. It also mentions the secondary capability of hiding replies, making the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: it is 'the main tool for a post that is going badly', which signals when to use it. Does not explicitly list alternatives or exclusion conditions, but the context is strong enough for an agent to select it appropriately.
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?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds concrete details about what the tool actually does at runtime—returns a live profile and follower counts—and why that matters for credential verification. This goes beyond the generic annotation profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first sentence states the purpose, and the second gives concrete use cases. Every word contributes to the agent's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description adequately conveys what the tool returns (live profile, follower counts) and when to invoke it (me/my, credential check). It does not enumerate every possible response field, but none are necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional 'account' parameter, and the schema already explains the default and how to list accounts. The tool description itself adds no parameter-level detail, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear, specific action: 'Authenticate and return the live profile for a connected account, including follower counts.' It also distinguishes the tool by tying it to credential verification and resolving 'me'/'my' references, which no sibling tool description does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Use this to confirm credentials work, or when the user says "me" or "my" and you need their handle and DID.' This clearly states when to use the tool, though it does not mention when not to use it or provide alternatives. Still, the context is unambiguous.
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?
Annotations already flag destructiveHint=true and readOnlyHint=false. Beyond those, the description adds valuable behavioral context: parts are fully validated before publication ('a thread never half-publishes'), media/quote/reply apply only to the first post, and the posting is public immediately. This goes beyond the annotations and helps the agent understand side effects and atomicity.
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 about four sentences and about 60 words. It front-loads the main purpose, then adds atomicity, scoping, and confirmation in a logical order. Each sentence serves a distinct factual purpose with no redundancy or filler.
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 this is a complex tool with 9 parameters and no output schema, the description covers the most important runtime behaviors: atomic publish, confirmation requirement, and how first-post-specific arguments behave. It probably could mention that it can also start a thread as a reply (reply_to) or that it requires an authenticated account, but these are either in the schema or inferable from sibling tools. Overall it's sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 89% schema coverage, the schema already documents most parameters. The description adds key semantic clarification: every part must be within the 300-character limit, and media, quote, and reply controls all apply to the first post. This is meaningful beyond the schema, which does not state that scoping. It also re-emphasizes the confirm parameter requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and object: 'Publish several posts as one thread', which makes it immediately clear what the tool does. It also adds the structural detail that posts 'reply to the last' and explicitly draws a distinction from a single-post tool, so an agent would not confuse it with create_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states when to use the tool implicitly (for a multi-post thread) and gives concrete usage constraints: media, quotes and reply controls only apply to the first post, and the tool 'needs confirm: true' because it publishes publicly. It doesn't explicitly name the alternative (create_post) or say when not to use this tool, but the context is clear enough.
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?
Annotations already declare readOnlyHint=false, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds valuable context beyond annotations: all notifications up to now are affected, the unread count resets, and the action is invisible to other users. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, information-dense sentences. The action and effect are front-loaded, followed by a concise privacy note. There is no redundant or filler wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation-style tool with two optional parameters and no output schema, the description plus schema covers what the tool does, its effect, its defaults, and its privacy implications. Nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters: account with default behavior and handle examples, and seen_at as an ISO timestamp defaulting to now. The description's 'up to now' reinforces the seen_at parameter but adds no new parameter-specific meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action: mark every notification up to now as seen, and the observable result: the unread count resets. It also clarifies the privacy scope, making it easy to distinguish from read-only notification tools like get_notifications and get_unread_count.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly communicates when to use the tool: when the user wants to clear or reset the unread notification count. It provides context about scope ('affects only your own view') but does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and idempotentHint=true. The description adds meaningful context: the action is private ('without them knowing') and reversible. It does not contradict any annotation and goes beyond the structured fields with behavioral nuance.
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?
Three short sentences, each earning its place: the first states the action, the second adds key properties (private, reversible), the third contrasts with block. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema and robust annotations, the description fully covers what an agent needs to understand the operation. There are no missing critical details such as permissions or side effects beyond what annotations already disclose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both 'actor' and 'account' have clear descriptions in the schema. The description adds no extra param-level meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Hide an account's posts from your feeds') and clearly differentiates itself from a block by stating the target can still see and reply. It is unambiguous what the tool does and how it differs from related actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use it ('Unlike a block, they can still see and reply to you') and implies when not to use a block. It does not explicitly name the unmute_account alternative, but the reversible nature is stated, which helps an agent understand the lifecycle.
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?
Annotations already flag readOnlyHint=false, destructiveHint=true and idempotentHint=false, so the safety profile is disclosed structurally. The description adds the crucial behavioral consequence — 'Public the moment it runs' — and pairs it with the confirm:true gate. That is genuinely informative context beyond the annotations; the connection between necessity and the confirmation requirement is exactly the kind of practical guidance an agent needs.
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?
Four sentences with no padding. The opening states the verb and payload types, then the behavioral scope, then the size constraint, then the confirmation requirement. Every part earns its place and the most decision-relevant detail (the length boundary) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 parameters, four nested objects, an enum, and no output schema, the description is adequately comprehensive. It establishes the input types, the length limit, the auto-linking behavior, the confirmation gate, and the length-based sibling. It doesn't describe what happens after posting or the response shape, which would be useful given that no output schema exists, but the safety-critical details are all present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented in the input schema. The description adds marginal value by noting that URLs, hashtags, and mentions in the text are auto-linked — 'You do not need to format them' — which helps the agent choose between providing formatting and relying on the tool. It also repeats the 300-char constraint already present in the schema. Given the schema carries most of the semantic load, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — 'Publish a post' — and lists the payload forms (text, images, video, link card, quote, replies). It distinguishes itself from the sibling create_thread by citing the 300-character boundary. An agent can tell this tool apart from create_list and the other publishing siblings without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to route elsewhere: 'for anything longer use create_thread'. It also states that the required confirm flag must be true and includes the precondition that the account defaults to the first connected account. This is concrete, actionable guidance that selects between alternatives with minimal left to inference.
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?
The description reinforces the idempotency hint with concrete language ('Reposting twice is harmless') and clarifies that adding a comment is out of scope for this tool, directing to create_post. Annotations already cover read-only/write and destructive status, so the description adds useful behavioral context without contradicting them.
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?
Three short sentences carry exactly the needed information: primary action, idempotency, and alternative. No wasted words, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema coverage and rich annotations, the description covers the essentials: what it does, idempotency, and the main alternative. Minor absence of return-value details is acceptable given no output schema, and the core behavior is fully specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both uri and account have clear descriptions. The description does not add additional semantic meaning about parameters beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Repost') and resource ('a post'), and specifies the audience ('to your followers'). It clearly distinguishes this from create_post by offering an explicit alternative for adding comments, so an agent can tell it apart without needing the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that reposting twice is harmless, indicating idempotent usage. It also directly instructs when to use create_post with 'quote' instead, providing a clear when-not and alternative condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints, so the bar for adding behavioral context is lower. The description adds critical behavioral details beyond annotations: authentication requirement (requires connected account) and endpoint refusal by public API, which informs an agent of failure modes and prerequisites. This meaningfully extends the structured metadata.
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?
Three concise sentences with zero filler. The first sentence states the core purpose, the second enumerates the supported operators in a scannable list, and the third covers prerequisites. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 8 parameters and no output schema, the description provides essential context: the query language, authentication needs, and the specific limitation regarding the public API. It does not describe the return structure or explicit error handling, but given the schema covers parameters and pagination is mentioned in the schema, the description is sufficiently complete for the agent to use the tool correctly. A small gap remains in not describing typical response shape or rate limits.
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 88%, so the schema already documents most parameters thoroughly. The description repeats the operator syntax that is already partially covered in the q field's description and adds no new parameter-specific semantics beyond what the schema provides. Baseline 3 is appropriate because the schema carries the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a full-text search across public posts with a specific verb and resource. It lists supported search operators that distinguish it from sibling search tools like search_actors and search_feeds, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: to search public posts using Bluesky's search syntax. It mentions the requirement of a connected account and warns that Bluesky's public API refuses this endpoint, giving clear preconditions. However, it does not explicitly state exclusions or direct comparisons to alternatives, but the tool name and resource scope make that evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true, readOnlyHint=false, idempotentHint=false), the description adds essential behavioral details: the action is visible to the target, it removes follows in both directions, hides posts, is reversible only via unblock_account but without restoring follows, and requires confirm=true. This fully discloses the real-world impact and meets the confirmation requirement without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no filler. It front-loads the core action, then packs behavioral details, reversibility caveat, and confirmation requirement into a tight, readable structure. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, non-idempotent tool with a confirmation parameter, the description covers all critical aspects: what happens, who sees it, reversibility, follow loss, and the confirm requirement. Annotations cover the safety profile, and the schema covers parameter details, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents actor, account, and confirm. The description adds little parameter-specific guidance beyond restating that confirm must be true, which the schema already states. It does not explain additional nuances like the format of actor or how account selection defaults, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Block') and resource ('an account'), and elaborates the exact effects: visible to the target, severs the relationship both ways, removes follows, hides posts. This clearly distinguishes it from siblings like mute_account (hidden, less severe) and unblock_account (reversal).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear behavioral context for when to block: it severs the relationship and hides posts, implying a stronger action than muting. It also names the reversal path (unblock_account) and warns that follows do not return, which helps an agent decide if blocking is appropriate. However, it does not explicitly contrast with mute_account or list all alternative tools, so guidance is good but not exhaustive.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds context that these are accounts the server can act as, and the handles are to be used elsewhere. No contradictions or hidden side effects implied.
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?
Three sentences, each purposeful: what it does, how to use its result, and when to call it. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with no parameters and no output schema. The description covers purpose and downstream usage, but doesn't specify the exact return structure (e.g., whether profile data is included beyond the handle). Still, all essential information for correct invocation and follow-up is present.
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?
No parameters exist, so the baseline is 4. The description mentions the `account` argument used elsewhere but doesn't need to describe parameters for this tool itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb 'List', a resource 'Bluesky accounts', and scope 'every...server can act as'. It clearly distinguishes itself from siblings by being the only account enumeration tool, and explains that it returns handles used as account arguments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this first when the user has multiple accounts and hasn't specified which one, and explains how the handle integrates with the `account` argument of other tools. This provides clear conditions and routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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/thenavidm/bluesky-mcp-cli'

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