Server Quality Checklist

Tool Scores

• bluesky_get_followersC
  2.7/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the burden of disclosing behavioral traits. It only states 'List the accounts' without mentioning pagination (cursor), result limits, authentication needs, or whether this is a read-only operation. Compared to the update_drive example, this lacks even minimal behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that efficiently communicates the core function. It earns its place without unnecessary words. However, it is slightly under-specified for a tool with three parameters and no other documentation, so it does not reach the highest tier.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, no annotations, and only a minimal description, the tool lacks critical context about return format, pagination behavior, and how it differs from sibling tools. The single sentence does not sufficiently equip an agent to use this tool correctly in all situations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 33% (actor only). The tool description adds no parameter meaning beyond the schema. It does not explain 'limit' or 'cursor', and does not reinforce the actor omission behavior. Since coverage is low, the description should compensate, but it does not.

  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 'List the accounts that follow a given user' clearly identifies the action (list) and resource (followers of a user). It is specific enough to distinguish from bluesky_get_following, which would list accounts a user follows, though it does not explicitly contrast with that sibling tool.

  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 bluesky_get_following. It does not mention use cases, prerequisites, or exclusions. The only usage hint comes from the schema's actor parameter description ('Omit for your own account'), which is not part of the tool description.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bluesky_get_followingB
  3.1/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals no behavioral traits beyond the basic read operation, such as pagination via cursor, potential rate limits, or whether authentication is required. The description is accurate but fails to add useful behavioral 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 a single sentence that is clear and directly front-loaded. It contains no filler or unnecessary words, and every word contributes to the purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is relatively simple, but the description omits important context such as pagination (cursor, limit) and does not differentiate from the similar 'get_followers' tool. With no output schema and minimal description, the agent lacks sufficient information to understand response shape or usage boundaries.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 33% (only 'actor' has a description). The description adds minimal semantic value by referring to 'a given user,' which hints at the actor parameter, but it does not clarify the handle/DID format or the omission default. Limit and cursor remain undocumented both in schema and 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?

  The description clearly states the verb 'List' and the resource 'accounts a given user follows,' making the tool's purpose unambiguous. It distinguishes itself from the sibling tool 'bluesky_get_followers' by specifying 'following' rather than 'followers.'

  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 the distinction between 'get_following' and 'get_followers' or suggest contexts where this should be preferred.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bluesky_search_postsB
  3.2/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that search covers 'public' posts and omits important behavioral details such as pagination via cursor, result shape, rate limits, or authentication requirements. This is insufficient given the absence of an output schema and annotations.

  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, front-loaded sentence with no wasted words, but it is also terse to the point of omitting useful context. It earns each word, yet the brevity limits its overall informational value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has three parameters, no annotations, and no output schema, the description is underpowered. It does not explain what a search result looks like, how pagination works, or what limit/cursor parameters control, making it insufficient for an agent to invoke the tool with confidence in non-trivial scenarios.

  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 has 0% description coverage, and the tool description does not explain any parameters. While 'query' can be inferred from 'full-text search', the semantics of 'limit' and 'cursor' (e.g., pagination behavior, defaults) are entirely undocumented, leaving the agent to guess.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('search') and resource ('public Bluesky posts'), distinguishing it from sibling tools like get_timeline and get_author_feed, which are feed-based rather than search-based. The public scope is also explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for full-text search queries but provides no explicit guidance on when to prefer this tool over alternatives like get_author_feed or get_timeline, nor does it mention exclusion criteria. The context of 'full-text search' is a hint, but no direct comparative guidance is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bluesky_get_author_feedB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must convey behavioral traits, but it only states the basic function. It does not disclose pagination behavior, ordering, error handling, or effects. The description adds no context beyond what the tool's name implies.

  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, no-waste sentence that immediately states the tool's purpose. It is appropriately sized for a simple getter tool, with no redundant or filler language.

  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?

  Despite being a low-complexity tool, the description does not explain how to use cursor/limit for pagination or handle edge cases like invalid actor handles. It also does not mention that omitting actor uses the authenticated user, a key detail present only in the schema. The description is incomplete for a first-time user.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is only 33% (actor has a description, but limit and cursor do not). The tool description mentions 'specific account' but says nothing about limit or cursor semantics, failing to compensate for the low coverage. Actor's meaning is clear, but the other parameters remain undocumented.

  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 gets posts from a specific account's profile feed, using 'Get' as the verb and 'posts' as the resource. It distinguishes from siblings like bluesky_get_post (single post) and bluesky_get_timeline (followed accounts' feed).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when you need a specific account's posts ('their profile feed'), which differentiates from timeline/search tools, but it does not explicitly state when to use it versus alternatives. No exclusions or explicit when-not-to-use guidance is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bluesky_get_profileB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the operation ('Get profile info') without mentioning authentication requirements, rate limits, error handling, or return format. A simple read operation is implied, but no behavioral traits are explicitly disclosed beyond the basic action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is front-loaded with the key action ('Get profile info') and provides a helpful list of example contents. Every word earns its place; there is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is simple (one optional parameter, no output schema), and the description provides enough to know it returns profile information. However, it does not clarify the return shape, possible errors, or any access constraints. For a read tool of this simplicity, the description is minimally adequate but lacks depth that would help an agent anticipate edge cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already provides 100% coverage for the single parameter 'actor', including its meaning ('Handle or DID') and usage ('Omit to get your own profile'). The description adds no additional parameter semantics beyond restating that it's for an account. Baseline 3 is appropriate when the schema fully documents parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Get profile info') and the target resource ('for an account'). It explicitly mentions example fields (bio, follower counts), making its purpose unambiguous. It is distinct from sibling tools like bluesky_get_author_feed (posts) or bluesky_get_followers (lists).

  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. The description does not mention exclusions or alternative tools. The only hint (omitting actor for own profile) lives in the schema, not the description, so the description itself fails to provide usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bluesky_resolve_handleB
  3.4/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description should disclose behavioral traits, but it only states that the tool looks up a DID. It does not mention error handling, handle format requirements, rate limits, or the response structure. The implication of a read-only lookup is present but not explicit, so this falls short of full transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the primary action and no extraneous words. It efficiently conveys the core purpose and a use case.

  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 one-parameter lookup tool with no annotations or output schema, the description provides a clear purpose and a usage hint. However, it omits potential errors, response format, and whether the handle is case-insensitive or requires a specific prefix. This is adequate for basic understanding but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides only a string parameter named 'handle' with zero description coverage. The description adds that it is a handle for which the DID is looked up, but it does not explain valid handle formats (e.g., '@username.bsky.social'), casing, or examples. Thus it 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 resolves a handle to a DID, using the specific verb 'look up' and identifying the resource (DID for a handle). It distinguishes from sibling tools by focusing on resolution rather than feeds or actions, and adds context that the DID is a permanent account id.

  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 an implied context for use: 'Needed for some actions like following.' However, it does not explicitly state when not to use this tool or mention alternatives such as get_profile, which may also return a DID. This makes usage guidelines clear but not fully explicit, earning a 3.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bluesky_get_timelineA
  3.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden for behavioral disclosure. It mentions the feed is 'chronological' and tied to the 'authenticated account', providing some transparency about ordering and auth. However, it does not disclose pagination behavior, rate limits, or response structure beyond what the schema implies.

  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-loaded with the core purpose. The second sentence adds valuable usage context without excess. Every word earns its place.

  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 2-parameter tool with no output schema, the description gives the essential purpose and context. It lacks explicit mention of what is returned (e.g., list of posts) and does not detail authentication requirements. It is adequate but has gaps for a fully self-contained description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% and the description does not explain the 'limit' or 'cursor' parameters. The word 'scroll' hints at pagination but does not directly describe how the parameters work. With simple parameters and no description compensation, this is below minimal.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets the authenticated account's chronological following feed, which is a specific verb+resource combination. It distinguishes from sibling tools like bluesky_get_author_feed by emphasizing 'following feed' and 'home timeline', though it does not explicitly name alternatives.

  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 phrase 'This is the main way to scroll Bluesky' provides clear context for when to use it—as the primary feed browsing tool. It does not explicitly exclude alternatives like bluesky_get_author_feed, 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.

• bluesky_mark_notifications_readA
  3.5/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the full burden of behavioral disclosure. It states the action but does not disclose side effects or scope implications (e.g., that it affects all notifications for the authenticated user, is irreversible, or requires specific permissions). The word 'mark' implicitly suggests a mutation, but no safety or consequence details are provided.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no redundant content. It immediately states the action and target, achieving maximum conciseness.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no parameters, no output schema), the description is close to sufficient. However, the lack of usage context and behavioral transparency leaves gaps that could affect an agent's decision to invoke it safely and correctly among siblings. The description is adequate but not comprehensive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema is empty with 100% coverage. Per rubric, the baseline for 0 parameters is 4. The description adds no parameter information, but none is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('mark') on a specific resource ('all current notifications') with a defined outcome ('seen'). It is distinguishable from sibling tools like bluesky_get_notifications, which retrieves notifications, and other mutation tools with different targets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. There is no mention of typical workflows (e.g., after reading notifications) or exclusions. Sibling tools are not referenced, and no context signals indicate preferred usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bluesky_repostA
  3.6/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and parameter sourcing, without mentioning authentication needs, idempotency, reversibility, or side effects. This is a significant gap for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences with the action front-loaded. Every word earns its place, and it is appropriately sized for a simple operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter mutation tool, the description covers the core action and input sourcing, but lacks behavioral detail and return value information. Given no annotations and no output schema, it is minimally viable but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0% and the description does not explain what 'uri' and 'cid' represent beyond saying to get them from other tools. It adds minimal semantic value, leaving the meaning and format of these fields underspecified.

  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 'Repost a post' with a specific verb and resource, clearly distinguishing it from siblings like bluesky_unrepost and bluesky_post. It leaves no doubt about the tool's function.

  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 by instructing users to get uri and cid from specific tools (bluesky_get_post, bluesky_get_timeline, bluesky_search_posts). It does not explicitly mention when not to use it or name alternatives, but the usage context is well implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bluesky_unlikeA
  3.8/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden. It clarifies the input requirement but does not mention any side effects, authentication needs, or irreversibility of the action. This leaves a significant gap in behavioral disclosure for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is only two sentences, front-loaded with the action and immediately following with the key parameter nuance. Every word earns its place, and the structure is efficient.

  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 single-parameter mutation with no output schema and no annotations, the description provides the critical input distinction and enough context to select and invoke the tool correctly. It could be seen as complete for the agent's needs, though it omits error scenarios or response details.

  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 provides only the parameter name 'likeUri' with no description. The description compensates well by explicitly stating that it requires the AT-URI of the like record itself, not the post URI, and even tells the agent where to find it (viewer.like on a post view). This is critical, precise semantic guidance.

  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 tile and description clearly state the function: 'Remove a like' / 'Undo a like.' The verb is specific, and the resource (like) is unambiguous, distinguishing it from sibling tools like bluesky_like or bluesky_delete_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 usage context is implied by the name and description: use this when you want to undo a like. It gives an important cue about the input (like record URI, not post URI) but does not explicitly state when to use this tool vs alternatives or provide exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bluesky_followA
  3.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden of behavioral disclosure. It only says 'follow', implying a mutation, but does not mention side effects, authentication requirements, idempotency (e.g., what happens if already following), or error conditions. This is a significant gap for a state-changing operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences with no redundant information. Every word contributes meaning, and the prerequisite tip is placed immediately after the main action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simplicity of the tool, the description provides the core action and a key prerequisite, but lacks behavioral context such as return values, side effects, or error handling. With no annotations or output schema, more detail would be needed to fully equip an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides only a 'did' string parameter with no description (0% coverage). The description clarifies that 'did' is the identifier type, but does not add format details, examples, or additional semantics beyond the parameter name. It partially compensates but leaves room for ambiguity.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action ('Follow a user by DID'), which distinguishes it from sibling tools like unfollow and resolve_handle. The verb 'follow' and the resource 'user' are explicit, and the method (by DID) adds precision.

  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 tells the agent to use bluesky_resolve_handle first if only a handle is available, providing a clear alternative and prerequisite. This directly addresses when to use this tool versus a sibling.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bluesky_get_notificationsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden. It lists content types but does not mention pagination behavior, whether notifications are marked as read, or response format. 'Get' implies read-only, which is useful, but the lack of detail on side effects is a gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single concise sentence that explicitly lists the notification types and scope. It is front-loaded and every word earns its place without 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 simple list tool with two parameters and no output schema, the description is largely adequate. It defines the content scope but omits details like ordering or whether the list is filtered, and there is no mention of the cursor parameter, which is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not explain the 'limit' or 'cursor' parameters. The schema provides defaults/ranges for limit but cursor remains ambiguous, and the description offers no pagination context.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves notifications for the authenticated account, listing specific types (likes, reposts, replies, follows, mentions). This distinguishes it from siblings like bluesky_get_timeline or bluesky_get_author_feed, which have different scopes.

  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 implies usage for the user's own notifications, which contrasts with other feed/profile tools. However, it does not explicitly name alternatives or state when not to use this tool, though the 'authenticated account' scope provides clear context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bluesky_likeA
  3.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description must fully disclose behavioral traits. It only states the action and input sourcing; it does not mention side effects, authentication requirements, error behavior, or return values. This is a significant gap for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Despite limited detail, the description is efficient and front-loaded. The action is stated first, and the parameter source guidance is given in a single extra sentence. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple like action, the description provides the essential 'what' and 'how to get inputs,' but omits expected return value, idempotency behavior, and potential failures. With no annotations or output schema, more context would be valuable to fully inform the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% coverage, but the description compensates by telling users exactly where to obtain the uri and cid (from other named tools). This adds meaningful guidance beyond the bare string types in 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 action ('Like a post') with a specific verb and resource. It distinguishes from other sibling tools like repost or follow, and even tells where to obtain the needed identifiers.

  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 by instructing users to get the uri and cid from specific tools (bluesky_get_post, bluesky_get_timeline, bluesky_search_posts). However, it does not explicitly mention when not to use it or name alternatives like bluesky_unlike.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bluesky_postA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must carry the behavioral transparency burden. It discloses the core action (publish) and the ability to reply, but does not mention permissions, rate limits, publication visibility, or failure modes. This is adequate 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 a single, well-formed sentence that immediately identifies the tool's purpose and the key optional behavior. There is no filler or redundant phrasing.

  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 relatively simple (publish a post), and the description plus schema cover the essential aspects, including reply usage. Since there is no output schema, the description does not need to explain return values. The only minor gap is that the description does not hint at the thread-root requirements for nested replies, but the schema handles those details.

  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 80% of the parameters with detailed descriptions, especially the reply-related fields. The description adds the phrase 'optionally as a reply' but does not add parameter syntax or format details 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 (publish) and a clear resource (post/skeet), and distinguishes itself from sibling tools by indicating it creates new content rather than reading, deleting, or interacting with existing posts. The optional reply behavior is also stated, 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?

  The description clearly implies the tool is used for publishing new posts, which is the natural counterpart to read-only or interaction tools. It does not explicitly name alternatives or exclusions, but the context of sibling tools makes the intended use obvious enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bluesky_get_postA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must carry the behavioral disclosure burden. It adds useful context by noting the returned data includes like/repost counts and the cid needed for actions, but it doesn't explicitly state read-only behavior, error handling, or authentication requirements. It's not misleading, but it lacks comprehensive disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that is front-loaded with the verb and object, then provides key details. No wasted words, and it earns its place by adding semantic value.

  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 is a simple read operation with one parameter and no output schema, the description covers the essential input semantics and describes the return value's key fields. It lacks edge-case behavior but is largely complete for the tool's complexity.

  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 only defines 'uris' as an array of strings with min/max items. The description adds essential meaning by specifying the strings are at:// URIs, which is critical for correct invocation. This goes beyond the schema's structural definition.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool fetches posts by at:// URI, specifying it can handle one or more posts and includes like/repost counts and cid. This is a specific verb+resource+distinctive detail that differentiates it from siblings like get_author_feed or search_posts.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context by specifying input as at:// URIs, which tells an agent when to use this tool (when you have post URIs). It doesn't explicitly mention alternatives but the unique input format and purpose provide clear context without needing exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bluesky_delete_postA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the irreversibility ('Permanently') and ownership constraint ('your own posts'), which are critical for an agent to understand the tool's side effects and authorization requirements.

  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 sentence that is concise and front-loaded, with no wasted words. It conveys the action, permanence, and scope efficiently.

  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 simple one-parameter deletion tool with no output schema and no annotations, the description is complete. It covers what, the permanence, and the ownership requirement, leaving no critical gaps for an agent to function 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 already provides 100% parameter coverage, including a clear description for the 'uri' parameter. The tool description does not add further semantic detail, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('delete') and resource ('your own posts'), clearly distinguishing it from sibling tools like like, repost, or follow. It immediately tells the agent exactly what action is performed.

  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 phrase 'your own posts' provides essential usage context, clarifying that only the authenticated user's posts can be deleted. It does not explicitly name alternatives, but none are needed since this tool is unique among siblings for deleting posts.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bluesky_unfollowA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the transparency burden. It states the action and the key prerequisite, but does not disclose side effects, permissions, or error behavior. 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?

  Two concise sentences, front-loaded with the action and followed by essential contextual detail. No wasted words.

  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 one-parameter tool with no output schema, the description covers the purpose, the parameter semantics, and the source of the URI. It lacks explicit mention of return behavior, but that's a minor gap given the simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides no parameter description, but the description fully compensates by explaining that followUri must be the AT-URI of the follow record itself and how to retrieve it.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function with the verb 'Undo a follow' and specifies the resource (a follow record). It distinguishes itself from sibling tools, especially 'bluesky_follow'.

  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 provides explicit guidance on the required input (the follow record's AT-URI, not the profile URI) and where to obtain it (viewer.following on a profile view). While it doesn't name alternatives, the sibling list implies when to use this over other actions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bluesky_unrepostA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden of explaining behavior. It does disclose a key behavioral nuance (requiring the repost record URI, not the post URI) and implies a delete/undo action. However, it does not mention authentication requirements, idempotency, or failure behavior, which would enhance transparency for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences, front-loaded with the core purpose. The second sentence adds essential clarification without redundancy. Every word earns its place, making it concise and well-structured.

  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 (one parameter, no output schema, no annotations), the description adequately covers the core purpose and the only parameter's meaning. It lacks edge-case details like error handling or authentication prerequisites, but for a straightforward 'undo' action, it is reasonably complete. A slightly higher score would require explicit behavioral guarantees or failure semantics.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema only provides the parameter name repostUri and type string, with 0% coverage. The description fully compensates by explaining that the value must be the AT-URI of the repost record itself, returned as viewer.repost, and explicitly warns against using the original post's URI. This is exactly the semantic information needed to use the tool correctly.

  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 'Undo a repost,' which clearly states the action (undo/remove) and the resource (a repost). This distinguishes it from sibling tools like bluesky_repost, which creates a repost. The title 'Remove a repost' 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: use this to undo a repost. It also provides crucial usage guidance that the repostUri must be the AT-URI of the repost record itself, not the original post's URI, and explains where to find it (viewer.repost). It does not explicitly name alternative tools or list exclusions, but the guidance is sufficient for this simple operation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.