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

Beyond the destructiveHint annotation, the description discloses important behavioral traits: the block is visible to the target, severs follows in both directions, hides posts, and is only partially reversible since follows do not come back. It also reinforces the mandatory confirm flag. No contradiction with 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.

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

Three sentences, front-loaded with the core purpose. Each sentence contributes unique value: the relationship effects, the reversibility caveat, and the confirmation requirement. There is no fluff or repetition of schema content.

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

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

For a destructive mutation tool with no output schema, the description covers the purpose, side effects, reversibility limits, and call precondition (confirm=true). The actor format and account default are already in the schema. Nothing essential for correctly invoking the tool is missing.

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

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

The input schema already documents all three parameters with 100% coverage, including the confirm flag's requirement. The description adds no parameter-specific meaning beyond restating that confirm must be true. The schema carries the semantic burden, so a baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Block an account.' It then details the consequences (removes any follow either way, hides your posts), which clearly distinguishes it from related tools like mute_account. It also names unblock_account as the reversal counterpart, making scope unambiguous.

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

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

The description gives clear usage context: it severs the relationship, hides posts, is visible to the target, and is reversible only partially via unblock_account. It also explicitly notes the confirm requirement. However, it does not explicitly state when not to use it or name mute_account as a less severe alternative, so it stops short of full guidance.

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

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

The description adds valuable behavioral context beyond the annotations: automatic linkification, immediate public visibility, irreversible publication, the confirm requirement, and the video transcoder delay. These details explain the real-world side effects of invoking the tool, which is especially important given the destructiveHint annotation.

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

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

The description is four tight sentences with no filler. The primary action is front-loaded, capabilities are summarized compactly, and the most critical operational constraint (300 chars, use create_thread) and safety requirement (confirm: true) are stated directly.

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

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

Despite having 13 parameters and no output schema, the description covers the full scope of the tool's behavior well: what content it supports, the length limit, the automatic link handling, the video processing behavior, and the irreversible public nature. The rich parameter schema fills in the remaining details, so an agent has everything needed to invoke this correctly.

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

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 every parameter thoroughly. The description still adds useful cross-cutting semantics such as 'you do not need to format' links, the Bluesky-specific character counting, and the confirm-guardrail requirement, which helps an agent understand how parameters behave together.

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

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

The description opens with a clear verb and resource ('Publish a post') and explicitly enumerates the supported content types: text, images with alt text, video, link cards, quotes, and replies. It also distinguishes itself from create_thread by stating the 300-character boundary, so an agent can select this tool without ambiguity.

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

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

Usage guidance is explicit: it states the tool should be used for posts up to 300 characters and directs longer content to create_thread. It also tells agents that URLs, hashtags, and mentions will be linkified automatically, so no manual formatting is needed, and that confirm=true is mandatory because the post is public immediately.

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

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

Even though annotations already mark this as destructive, the description adds substantial behavioral detail: all parts are validated against the 300-character limit before anything publishes, so the thread never half-publishes; media/quote/reply controls only affect the first post; and the result is public immediately, requiring confirm: true. This goes well beyond the annotations and schema.

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

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

Four sentences with no filler. The core action is stated first, followed by atomicity, first-post scoping, and the confirmation requirement—each sentence earns its place and important behavior is front-loaded.

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

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

For a complex 9-parameter destructive tool with no output schema, the description covers the key invocation-critical behaviors: thread chaining, pre-publication validation, first-post scoping, public visibility, and mandatory confirmation. It does not mention return values, but that is not essential for safe invocation.

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

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

Schema coverage is 89%, so the schema already documents most parameters. The description adds meaningful semantics by explaining that the posts list forms a reply chain, that media/quote/reply controls apply only to the first post, and that length validation is all-or-nothing. This supplements rather than merely repeats the schema.

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

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

The description names a specific verb ('Publish') and resource ('several posts as one thread'), and distinguishes it from the single-post sibling create_post by describing the chained-reply structure. This makes the tool's purpose immediately identifiable.

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

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

The description clearly implies this tool is for multi-post threads and states that media, quotes, and reply controls apply to the first post. It does not explicitly name create_post as the alternative for single posts, but the context is clear enough for an agent to choose correctly.

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

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

Beyond the annotations (destructiveHint: true, idempotentHint: false), the description discloses two important consequences: the action cannot be undone and the post may persist in existing feeds and caches. It also reiterates the hard requirement that confirm must be true, reinforcing the safety gate.

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

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 packs irreversibility, cache/feed caveat, and the confirm requirement into the second sentence.

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

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

For a destructive delete operation without an output schema, the description covers the key operational facts: scope, irreversibility, residual visibility in feeds/caches, and the required confirmation. No critical detail an agent needs before invoking it is missing.

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

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 adds the ownership constraint on 'uri' (your own posts) and reinforces the confirm flag, but doesn't introduce new parameter semantics beyond that.

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

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

The description opens with 'Delete one of your own posts,' naming a specific verb, resource, and an ownership constraint. This clearly distinguishes it from sibling tools like unlike_post or unrepost, which remove interactions rather than the post itself.

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

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

The phrase 'one of your own posts' provides immediate context that this tool is only for deleting posts owned by the user, not for removing other users' content. It doesn't explicitly name alternative tools, but there is no competing deletion tool among the siblings, so the usage context is clear.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds a plain-language idempotency note ('Following twice is harmless') that aligns with the annotation, but otherwise doesn't disclose additional behavioral context like permissions 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.

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

Two short, front-loaded sentences with zero filler. The core action and input constraint come first, and the idempotency note is a useful second sentence without bloat.

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

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

For a simple two-parameter action with full schema coverage and safety annotations, the description provides adequate context: what the tool does, how the target is specified, and that repeated calls are harmless. No output schema exists, so return-value details are not needed.

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

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

Schema description coverage is 100%, with both `actor` and `account` documented clearly. The description only reiterates what the schema already says about `actor`, so it adds no meaningful semantic value beyond the structured parameter definitions.

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

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

The description states a specific verb ('Follow') and resource ('an account'), and specifies the addressing forms ('by handle or DID'). It clearly distinguishes this from sibling tools like unfollow and other account actions.

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

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

The description gives no guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The schema's account parameter hints at calling list_accounts, but that addresses account selection, not tool selection.

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

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 valuable context beyond annotations by stating that the tool works without credentials and that results are ordered newest first. It also explains the filter's effect with a concrete use case. No contradictions 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.

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

Three sentences with no fluff: purpose and ordering, auth requirements, and a practical filter tip. The core info 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.

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

With seven parameters but 86% schema coverage and strong annotations, the description covers purpose, auth, ordering, and one key parameter behavior. The main gap is the lack of an explicit return-shape description (no output schema exists), though 'Posts by one account' gives a good indication. Slightly more detail on pagination or return format would make it fully complete.

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

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

Schema coverage is high at 86%, so baseline is 3. The description adds meaningful guidance for the 'filter' parameter, recommending 'posts_no_replies' when studying how someone writes, which goes beyond the enum's generic descriptions. Other parameters are already well documented in the schema.

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

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

The description states a specific resource ('Posts by one account') and ordering ('newest first'), making the tool's function immediately clear. The title reinforces this, and the scoping to a single account distinguishes it from broader feed and timeline siblings like get_timline and get_feed.

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

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

The description provides some usage context: it works with or without credentials, and it recommends the 'posts_no_replies' filter for studying writing style. However, it never explicitly names alternative tools or states when not to use this one, leaving sibling comparison to inference.

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

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 safety profile is fully covered. The description adds no additional behavioral traits beyond the read operation itself, which is consistent. It does not contradict annotations, but it also does not enrich the agent's understanding of behavior such as pagination or rate limits.

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

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

Two sentences with no wasted words. The core action and input format are front-loaded, and the discovery guidance is kept to a single compact sentence. Every part earns its place.

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

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

For a read-only list operation with rich annotations and a well-described schema, the description is nearly complete. It explains the required input and how to find it. The main gaps are the absence of an output schema and the undocumented cursor parameter, which are not addressed in the description, but the 'Pages automatically' note in the limit parameter helps mitigate this.

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

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

Schema coverage is 75%, covering feed, limit, and account with useful descriptions. The tool description adds a helpful hint for finding feed URIs, but it does not explain the cursor parameter, which lacks a schema description. Since the schema already handles most parameters, the baseline of 3 is appropriate, though the cursor gap is a minor shortcoming.

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

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

The description clearly states a specific verb and resource: 'Read posts from a custom feed.' It also identifies the exact input forms (at:// URI or bsky.app link), making the tool's purpose immediately distinguishable from other feed-related tools like get_timeline 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.

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

The description gives concrete guidance on how to obtain a feed reference: 'Find one with search_feeds, or your own with get_pinned_feeds.' This names the relevant sibling tools and provides actionable context, though it does not explicitly exclude cases like using get_timeline for the home feed or get_author_feed for a user's posts.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond that: results come newest-first and pagination is handled automatically past Bluesky's 100-ceiling. This helps an agent understand the actual retrieval behavior without opening a schema.

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

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

The description is compact: two sentences deliver the core resource, ordering, and automatic pagination. It avoids restating schema fields or adding filler, and the most important scoping information is front-loaded.

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

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

For a simple read-only list operation with four parameters and no output schema, this is mostly complete. It identifies the returned objects, ordering, and pagination behavior, while annotations cover the safety profile. A bit more detail on response shape or connected-account behavior would be a minor enhancement, but it is not essential.

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

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

The description provides little parameter-level detail beyond what the input schema already covers. 'Given account' maps to actor, and the pagination note relates loosely to limit/cursor, but the semantics of cursor, limit, and the account parameter remain primarily schema-defined. Since schema description coverage is 75%, the baseline of 3 is appropriate.

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

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

The title 'List followers' names a specific verb and resource, and the description 'Accounts that follow a given account' precisely scopes the result set. This clearly distinguishes it from the sibling get_follows, which would list accounts a given account follows. Adding 'newest first' further clarifies the ordering.

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

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

The intended use is implied by the title and phrasing, and the pagination note suggests it is useful when all followers are needed. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternative like get_follows is named, leaving selection to inference.

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

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

Annotations already declare read-only, idempotent, open-world, and non-destructive. The description adds one useful behavioral detail, automatic pagination, but does not explain the result shape, how cursor/limit interract with the auto-paging, or behavior for missing actors.

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

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

Two short sentences with no filler; the resource statement is front-loaded and the pagination note is a separate, meaningful behavior. This is appropriately concise for a small read-only list tool.

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

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

With rich annotations, a mostly descriptive schema, and no output schema, the description is minimally adequate. However, the absence of output-schema and lack of clarity about how cursor/limit relate to 'Pages automatically' leaves some uncertainty about the exact return format and pagination behavior.

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

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

The input schema already covers 75% of parameters with descriptions for actor, limit, and account. The tool description adds no parameter-level meaning, and the cursor parameter still lacks explanation beyond the hint from 'Pages automatically.'

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

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

The description clearly identifies the resource: accounts a given account follows. The purpose is clear, but it does not explicitly differentiate this from siblings like get_followers or get_suggested_follows, and the main sentence is a noun phrase rather than a verb.

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

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

There is no guidance on when to use get_follows versus alternatives such as get_followers, get_suggested_follows, or get_relationshipps. 'Pages automatically' is an operational note, not usage guidance.

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

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

Annotations already establish read-only, open-world, and idempotent behavior. The description adds non-obvious behavior: result ordering, own-account-only enforcement, and the platform reason behind that limitation. 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.

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

Two short sentences, front-loaded with what the tool returns and the key constraint. No filler or repetition of schema defaults.

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

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

For a low-complexity read tool with zero required parameters and rich annotations, the description covers purpose, ordering, and a critical account limitation. It lacks explicit pagination/cursor behavior and return shape, but the core call is sufficiently scoped.

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

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

The schema already describes limit and account, and the description reinforces the account concept. However, the description adds no information about the undocumented cursor parameter or pagination. At 67% schema coverage, the description should compensate for the cursor gap and does not.

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

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

The description clearly identifies the tool as returning posts liked by a connected account, with a specific ordering ('newest first') and a scope limitation (own accounts only). It is distinguishable from list-like siblings because it specifies the liked-posts feed, though it does not explicitly name alternatives such as 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.

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

It gives clear context: use for a connected account's liked posts, not for other accounts, because Bluesky does not expose others' likes as a feed. This implicitly tells the agent when not to use it, but it does not name an alternative tool for other like-related queries.

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

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 safety profile is covered. But the description adds essentially nothing beyond the word 'curated' — it does not disclose pagination via cursor, ordering, rate limits, or what the returned account objects look like. With no output schema, these omissions matter.

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

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

Five words is not conciseness but under-specification — the description merely echoes the title with 'curated' appended. There is no front-loaded verb, no scoping detail, and no sentence structure. It does not earn its place because it adds almost no information beyond the title.

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

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

With 4 parameters, no output schema, and 40+ siblings including the closely related get_list_posts, the description is far from complete. It never explains what the response contains, how pagination works, or how to choose between this and the similarly named list tools. An agent could not confidently invoke this correctly from the description alone.

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

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

The schema covers 3 of 4 parameters well (list format 'at:// URI or bsky.app link', limit bounds/default, account handle selection and fallback), so the schema carries the burden. The description itself adds zero parameter meaning, and the cursor parameter remains undocumented in both schema and description.

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

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

The description 'The accounts on a curated list' is a noun phrase that conveys the resource being retrieved (accounts/members of a Bluesky list) and weakly distinguishes from siblings like get_list_posts (posts on a list) via the word 'curated'. However, it lacks a verb, is nearly a restatement of the title, and does not clearly differentiate from the many list-related siblings.

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

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

There is no guidance on when to use this tool versus alternatives. No sibling such as get_list_posts or get_lists is mentioned, no exclusions are stated, and the only cross-reference (list_accounts) lives in the parameter schema rather than the description. The agent is left to infer selection criteria entirely.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavior beyond annotations: it returns posts from list accounts, sorted newest first, and explains the input format (list URI or bsky.app link). It does not address pagination or access requirements, but this is relatively minor for a read-only feed tool.

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

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

The description is two tight sentences. The first states what the tool returns and its ordering; the second provides a concrete source for the required list URI. There is no redundant phrasing or fluff, and the most important information is front-loaded.

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

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

Given this is a simple read-only feed tool with no output schema and strong annotations, the description covers the core requirement: the resource type, the input source, and the ordering. It lacks explicit pagination guidance or a note about list visibility, but the schema provides a cursor parameter and the list URI source is clear enough for an agent to make a correct call.

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

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

Schema description coverage is 75%: list, limit, and account all have some description. The description adds helpful context for the list parameter by pointing to get_pinned_feeds or bsky.app links, but it does not clarify the undocumented cursor parameter or how pagination works. Overall it adds some value beyond the schema but leaves a gap for cursor.

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

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

The description clearly identifies the resource: posts from a curated list, with an explicit ordering of newest first. It distinguishes this tool from get_timeline and get_author_feed by saying 'accounts on a curated list', though it does not name sibling tools or explicitly contrast them.

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

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

The instruction to take the list URI from get_pinned_feeds or a bsky.app /lists/ link provides practical guidance on where to obtain the required parameter. However, it does not say when to use this tool instead of alternatives like get_feed or get_timeline, leaving usage context implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description contributes the scoping detail that results are lists created by the account and that returned URIs are meant to be passed onward, which adds modest behavioral 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.

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

The description is a single sentence that front-loads the core purpose and then immediately explains how to use the result with sibling tools. Every clause earns its place; there is zero filler.

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

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

With no output schema, the description partially compensates by saying the result is a set of curated lists with URIs that can be passed to get_list_posts or get_list_members. Together with the rich parameter schema and strong annotations, an agent has enough context to invoke the tool correctly, though a bit more detail on the response shape would make it fully complete.

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

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

Schema coverage is 100%, so the schema already documents all four parameters including actor, limit, cursor, and account. The description adds no parameter-level meaning beyond implying the actor is the account whose lists are being fetched, 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.

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

The description states a specific resource and action: curated lists an account has created. It also differentiates itself from sibling tools by explaining how the returned URIs are consumed by get_list_posts and get_list_members, so an agent knows exactly what this tool provides.

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

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

The description clearly frames when to use this tool: when you need to see the curated lists a given account has created. It names downstream tools and how the output feeds into them, providing useful routing context, though it does not explicitly 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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context beyond annotations: the content scope, the 'newest first' ordering, and the guidance that 'mention' and 'reply' are the actionable types. This is meaningful additional context and does not contradict any annotation.

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

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

Two compact sentences with no filler. The first sentence front-loads the core purpose and content scope, while the second delivers practical filtering advice. Every sentence earns its place.

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

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 no output schema, the description together with the schema covers most essentials: content types, ordering, filtering, and pagination (via the 'limit' parameter description). It does not mention the 'account' parameter or when to use get_unread_count instead, but those are relatively minor omissions given the schema and annotation coverage.

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

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

Schema coverage is 80%, with the cursor parameter lacking a description. The main description adds semantic value by explaining the 'reasons' filter and singling out 'mention' and 'reply' as the ones requiring attention. This goes beyond the raw enum list, though the undocumented cursor remains a gap.

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

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

The description states a specific verb ('get') and resource ('notifications'), enumerates the exact content types (likes, reposts, follows, mentions, replies, quotes), and specifies ordering ('newest first'). It clearly distinguishes itself from siblings like mark_notifications_seen by describing a read operation and from get_unread_count by listing actual notification items rather than counts.

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

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

The description gives clear usage context: it returns all notification types and explains how to narrow to actionable ones via the 'reasons' filter, specifically identifying 'mention' and 'reply' as needing responses. However, it does not explicitly contrast with get_unread_count or mark_notifications_seen, so the agent must infer when those alternatives are more appropriate.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds useful context about ordering and that the output contains URIs consumable by other tools, but it does not go beyond that. This meets the baseline without adding significant behavioral depth.

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

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

The description is two sentences with no filler. It front-loads the core behavior and immediately provides actionable follow-up usage. Every sentence earns its place.

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

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 one optional parameter and no output schema, the description explains what is returned (pinned feeds and lists, in order) and how the results should be used. It does not describe the exact response shape, but the absence of an output schema is partially mitigated by the clear behavioral description.

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

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

Schema coverage is 100%, so the account parameter is fully documented in the schema, including its default behavior and relation to list_accounts. The description does not add extra parameter-level detail, which is acceptable given the high schema coverage.

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

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

The description states a specific verb and resource: it lists the feeds and lists pinned to a connected account's home screen, in order. This clearly distinguishes it from related siblings like get_feed and get_list_posts by focusing on enumeration rather than post retrieval.

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

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

The description clearly conveys when this tool is useful: to see pinned feeds/lists for an account. It also gives practical follow-up guidance by telling the agent to pass returned URIs to get_feed or get_list_posts. It does not explicitly state when not to use alternatives, 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.

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

Annotations already declare the operation as read-only, idempotent, and non-destructive, so the description need not restate that. It adds useful behavioral context with 'newest first' ordering, but it does not mention pagination behavior or describe the response shape beyond 'accounts.'

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

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

The description is a single, front-loaded sentence that conveys the core result and ordering with no filler or redundant information. Every word earns its place.

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

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

For a simple read-only lookup, the description combined with the fully documented schema and safety annotations covers the essential calling context. It could explicitly state that results are paginated via limit/cursor, but the schema already provides those details, so the remaining gap is minor.

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

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

The input schema has 100% coverage and clearly documents uri, limit, cursor, and account. The description adds no parameter-specific semantics beyond what the schema already provides, 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.

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

The description clearly identifies the resource and result: accounts that liked a specific post, ordered newest first. It is distinguishable from related tools like get_reposted_by or get_liked_posts by subject matter, though it does not explicitly name a sibling to differentiate itself from.

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

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

The intended use is implied by the description: call this when you need the accounts that liked a post. However, there is no explicit guidance about when to use this tool versus alternatives such as get_reposted_by or get_quotes, leaving some routing ambiguity among sibling tools.

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

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

Annotations already cover the safety profile (read-only, idempotent, non-destructive), and the description adds useful thread-walking behavior and accepted input forms. However, the claim of 'everything above it and the replies below' overstates the default/maximum limits encoded in the depth and parent_height parameters, and no pagination or output-shape behavior is disclosed.

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

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

The description is two concise sentences with no filler. The core behavior is front-loaded, and the use-case instruction earns its place without redundancy.

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

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

The schema thoroughly documents all four parameters and the annotations cover the read-only safety profile, so the description does not need to re-explain those. It clearly states what the tool does and when to call it. However, with no output schema and no mention of reply-depth limits or pagination, an agent is left slightly underspecified about what will actually be returned.

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

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

Schema description coverage is 100%, and each parameter already has a clear description, including the at:// or bsky.app URI form, depth, account selection, and parent_height. The tool description adds no parameter-specific meaning beyond what the schema already 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.

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

The description clearly identifies the action ('Read') and the resource ('a post together with the conversation around it'), and specifies the scope as 'everything above it and the replies below.' This distinguishes it from feed, timeline, and single-resource read tools among the siblings. The mention of accepting an at:// URI or bsky.app link further clarifies the exact target.

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

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

The description gives an explicit trigger: 'Use this before replying, so the reply lands with context.' This is a concrete and useful usage guideline. However, it does not name alternative tools or state when not to use this tool, so it stops short of a full 5.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond that: it works without credentials, supports batched accounts, and conditionally includes mutual-follow data only when a connected account is available.

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

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

A single, well-structured sentence carries all essential information: the resource, the included fields, the multi-account capability, and the credential requirement. Nothing is wasted and the most important information is front-loaded.

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

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 only two fully documented parameters, the description is complete. It explains the return content, the optional connected-account behavior, and authentication needs, and the annotations cover safety and idempotency traits.

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

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 reinforces the 'one or more accounts' nature of actors and hints at the account parameter, but it does not add substantial syntax or formatting detail beyond the schema.

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

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

The description names a specific verb and resource ('get profile'), states the exact contents (bio, follower counts, labels, follow status), and clarifies it can operate on one or more accounts. This distinguishes it from siblings like get_author_feed, search_actors, and get_relationships even without naming them.

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

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

The description gives clear context: use this when you need a full profile for one or more accounts, and it notes that credentials are not required. It does not explicitly name alternatives or exclusion conditions, so it stops short of a 5, but the usage context is unmistakable.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds useful conceptual context about quote posts versus reposts, but it does not disclose other behavioral traits such as pagination, result shape, or ordering. The description is consistent with 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.

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

The description is two sentences with no filler. The core result is stated first, and the second sentence adds a valuable distinction that helps the agent decide when to use the tool. Every phrase earns its place.

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

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 fully documented parameters and clear annotations, the description is largely sufficient. It explains the conceptual value and what is included (quotes) versus excluded (reposts). It does not describe the output structure, but the operation is simple enough that the absence of an output schema is not a major gap.

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

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 schema. The description adds no additional parameter-level detail beyond the general notion of 'a specific post,' which maps to the required uri parameter. Thus it meets the baseline without significantly enhancing parameter understanding.

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

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

The description clearly identifies the tool's purpose: returning posts that quote a specific post. It also distinguishes quotes from reposts, which directly separates it from the sibling get_reposted_by. The title reinforces the resource and action, making the tool unambiguous.

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

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

The description gives strong contextual guidance by saying 'This is where the argument about a post usually lives' and noting that quotes carry commentary whereas reposts do not. It implies when to use this tool over a repost-listing alternative, though it does not explicitly name the alternative or state exact when-not-to-use conditions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond annotations by explaining the return semantics (follow and follow-back status per account) and the one-call batch behavior, with no output schema available.

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

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

Three short sentences deliver behavior, batching, and usage guidance with no filler. The core behavior 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.

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

For a simple two-parameter, read-only tool with strong annotations and complete schema descriptions, the description covers what the agent needs: what is checked, that it handles a whole list, and when to use it. The lack of an output schema is mitigated because the description states the semantic result.

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

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

Schema description coverage is 100%, and the schema already documents both parameters well, including account defaults and the list_accounts pointer. The description only reinforces the batching idea behind actors, so it adds little semantic value beyond the schema.

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

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

The first sentence states the exact operation: for each named account, report whether a connected account follows them and whether they follow back. It also distinguishes this from per-profile lookups and sibling list tools by emphasizing a single batch call.

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

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

It explicitly says to use this 'before a bulk follow or unfollow rather than reading a profile each time,' giving both a concrete use case and an alternative pattern. The agent can decide when this tool is preferable without further inference.

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

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

Annotations already declare the tool read-only, idempotent, open-world, and non-destructive, so the safety profile is covered. The description adds that the result is a list of accounts rather than repost objects, but does not disclose pagination details or response envelope, which is acceptable given the schema documents cursor/limit.

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

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

The description is a single concise sentence with no filler or redundancy. While it is a noun phrase rather than a full verb phrase, the title supplies the action and the description stays tightly scoped.

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

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

There is no output schema, so the description should ideally clarify what the response contains; 'The accounts that reposted a specific post' does this at a high level. It does not mention that results are paginated or that account selection can affect the view, but the schema already documents the account and pagination parameters.

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

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

The input schema covers all four parameters with descriptions (uri, limit, cursor, account), so the schema carries the parameter documentation burden. The description only reinforces that uri points to a 'specific post', adding no new parameter-level meaning.

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

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

The description clearly identifies the resource (accounts) and the relationship (reposted) for a single post, and the title adds the verb 'See'. It is distinct in intent from sibling tools like get_post_likes and get_quotes, though it does not explicitly contrast them.

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

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

Usage is implied: call this when you need the accounts that reposted a specific post, given a URI. There is no explicit guidance about when to prefer it over alternatives or when not to use it, but the sibling names and the 'specific post' phrasing provide reasonable context.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to repeat safety guarantees. It adds behavioral nuance beyond the schema by describing the two modes of suggestions and the niche-discovery use case, which helps the agent predict output semantics.

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

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

Two sentences carry all essential information with no filler. The actor distinction is front-loaded, and the 'better way to find a niche' phrase earns its place by guiding usage without adding bulk.

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

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

For a simple read-only suggestions tool with zero required parameters and heavily documented schema, the description plus annotations are sufficient for correct invocation. It does not describe the response shape, but no output schema exists and the tool is simple enough that this is a minor gap rather than a blocker.

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

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

The input schema covers all three parameters with detailed descriptions, including the actor call pattern, limit bounds and default, and account selection fallback. With 100% schema coverage, the description adds little parameter-level meaning beyond what is already structured, 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.

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

The description clearly states the tool returns follow suggestions from Bluesky and distinguishes the actor-based mode from the default mode. It is specific about the resource ('accounts') and the action, though the first sentence is phrased as a noun phrase rather than an explicit 'returns' statement.

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

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

The description gives actionable guidance: omit actor for personal suggestions, include actor to find similar accounts, and even calls the actor mode 'the better way to find a niche.' It does not explicitly name alternatives like search_actors, but the usage context is clear enough for an agent to decide between default and actor-based calls.

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

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

The description adds meaningful behavioral context beyond the annotations: it discloses ordering ('newest first'), scope ('your following feed'), authentication needs ('Requires a connected account'), and the time-window behavior of since_hours. The annotations already cover read-only, idempotent, and non-destructive traits, so the description supplements rather than repeats them.

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

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

The description is two sentences, front-loads the core purpose, and includes only high-value usage guidance. There is no redundancy or filler.

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

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

For a read-only timeline tool, the description covers the essential context: what feed is accessed, ordering, authentication, and the main parameter behavior. There is no output schema, but the expected return type ('posts') is implicitly clear from the description and parameter schema, so the absence of explicit return-value details is not a major gap.

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

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 all four parameters thoroughly. The description adds some conceptual meaning for since_hours ('time window rather than a fixed number of posts'), but it does not meaningfully expand on limit, cursor, or account beyond their schema descriptions.

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

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

The description clearly states the tool reads 'Your following feed, newest first,' which identifies the resource and behavior. It is distinguishable from related tools like get_author_feed or get_feed by the phrase 'following feed,' but it does not explicitly name or contrast siblings.

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

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

The description provides clear context: it requires a connected account, and since_hours is presented as an alternative to a fixed post count for reading a time window. It does not explicitly state when not to use this tool versus alternatives, but the usage hints are concrete and useful.

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

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

Annotations already cover the read-only, open-world, idempotent, and non-destructive profile. The description adds useful context about needing no credentials and returning a feed link with each topic, but it does not address response shape, pagination, or the apparent tension between 'works without credentials' and the account parameter referencing connected accounts. It adds some value beyond annotations but not rich behavioral detail.

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

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

The description is a single sentence that front-loads the core purpose, then adds two valuable details: the feed link and credential-free operation. There is no fluff or redundancy, making it easy to parse and remember.

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

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

With no output schema, the description partially compensates by mentioning feed links per topic, but it does not describe the full response structure. The 'works without credentials' statement also conflicts with the account parameter's default-to-connected-account semantics, leaving ambiguity. Overall, the description captures the essentials but is not fully complete for unassisted invocation.

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

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

Schema description coverage is 100%, with each of the three parameters (limit, account, include_suggested) having a meaningful description. The tool description itself does not add any parameter-level meaning beyond the schema, so it does not improve parameter understanding. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: it returns current trending topics on Bluesky, which is distinct from sibling tools like get_feed or search_posts. It also clarifies that each topic includes the feed link to the underlying posts, making the tool's purpose and output content immediately clear.

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

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

The description implies it is for viewing public trending data and notes that it works without credentials, which signals a low-barrier read tool. However, it does not explicitly state when to prefer this tool over alternatives like search_posts or get_feed, and it offers no exclusion criteria. Usage context is clear but not fully specified.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds that this is 'one cheap call,' disclosing a performance characteristic, and defines the semantics of unread as 'since you last marked them seen.' This gives useful context that the structured annotations do not provide.

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

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

Two short sentences with zero fluff. The purpose is front-loaded and the usage rationale follows in the second sentence. Every word earns its place.

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

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

For a simple, side-effect-free read tool with one optional parameter and no output schema, the description covers everything needed: what it counts, how unread is defined, and how to use it efficiently. The agent can safely invoke it without further clarification.

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

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

The input schema fully documents the single optional account parameter with a thorough description, and schema coverage is 100%. The tool description adds no parameter-level information, but it doesn't need to because the schema already carries the full burden. Baseline 3 is appropriate.

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

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

The description clearly states a specific verb and resource: count how many notifications have arrived since they were last marked seen. It distinguishes itself from get_notifications (the full list) by focusing on the count, so an agent can tell them apart without reading schemas.

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

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

The description explicitly advises making this call 'before you pull the full list,' which establishes when to use it relative to get_notifications. It does not name the alternative tool directly or give explicit when-not-to-use conditions, but the context is clear enough for an agent to follow.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds contextual behavior beyond annotations: the tool is a fallback for create_post timeouts and the job id comes from that specific failure message. It does not fully describe response statuses, but with strong annotations the added context is valuable.

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

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

Three short sentences with zero filler. The key fact (check by id) is front-loaded, followed by the exact when-to-use condition and a useful reassurance. Each sentence earns its place.

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

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

For a simple read-only status lookup with no output schema, the description gives enough context to call it correctly: the scenario, the id source, and the likely self-resolution of the job. It could be slightly more explicit about what to do if the status still reports processing, but the current guidance implies waiting rather than retrying.

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

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

Schema description coverage is 100%: job_id and account are fully described in the input schema. The description adds a small note that the id is in the create_post timeout message, but that essentially restates the schema's 'reported by a timed-out create_post.' Baseline 3 is appropriate because the schema carries the semantic weight.

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

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

States a specific verb ('Check') and resource ('a Bluesky video transcoding job by id'), which is unambiguous and distinct from all sibling tools. The wording clearly conveys an operation on a video upload job, not a generic status endpoint.

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

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

Explicitly says when this tool is needed: only when create_post reported that a video was still processing after giving up waiting. Also notes the job usually finishes on its own, which tells the agent not to overuse polling and gives real decision context.

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

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

Annotations already mark the tool as idempotent, but the description adds concrete behavioral detail: liking twice returns the existing like rather than creating a second one. This goes beyond the annotations and clarifies the actual outcome.

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

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

The description is two tight sentences with no filler. The core action is first, followed immediately by the key behavioral caveat.

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

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 relevant annotations, the description provides enough information to call the tool correctly. The absence of an output schema is not a gap here because the description already states the duplicate-like return behavior.

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

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

Schema description coverage is 100%, so the schema already explains both uri and account. The description repeats the uri format but adds no meaning beyond the schema, meriting the baseline score.

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

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

The description clearly states the operation: liking a post. It names the resource type and the accepted URI forms, and the idempotence note implicitly distinguishes it from unlike_post and other social actions.

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

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

The description makes the use case obvious and adds practical guidance about at:// URIs and bsky.app links. It does not explicitly contrast with unlike_post or other siblings, but the tool's purpose is self-evident and no exclusion is needed.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable behavioral context by explaining that the returned handles serve as the 'account' argument for other tools, effectively positioning this tool as a prerequisite step.

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

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

Three sentences, each earning its place: purpose, usage of the result, and when to call. Front-loaded with the primary action, no redundant wording.

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

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

For a zero-parameter read-only list tool with annotations covering safety and no output schema, the description fully equips an agent: it defines what is listed, how to use the result, and when to invoke it. Nothing essential is missing.

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

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

The tool has no parameters and the schema is an empty object (100% coverage), so there is nothing to document. Baseline 4 applies; the description appropriately mentions the output handle's role without needing to describe parameters.

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

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

The description states a specific verb and resource: 'List every Bluesky account this server can act as.' It clearly differentiates from sibling tools by establishing that it returns account handles for use elsewhere, which no other sibling does.

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

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

Explicit guidance is provided: 'Call this first when the user has more than one account and has not said which one they mean.' This tells the agent exactly when to invoke this tool and implies when it may be unnecessary, without ambiguity.

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

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

The description adds meaningful behavioral context beyond the annotations: it clarifies that the action affects only the user's own view and that others cannot tell, which is not stated in the structured annotations. It aligns with readOnlyHint=false, destructiveHint=false, and idempotentHint=true without contradiction.

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

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

The description is two concise sentences, front-loading the core action and effect before adding the important privacy note. Every sentence earns its place, and there is no redundant or filler content.

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

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

For a simple two-optional-parameter mutation with no output schema, the description is complete: it states the action, effect, scope, and privacy implications. The schema covers parameter details, and the annotations cover safety and idempotency, so nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, with both parameters already documented: account and seen_at. The description does not add meaning beyond the schema, but it is consistent with the parameters by saying 'up to now', matching the seen_at default of now. This meets the baseline for schema-covered parameters.

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

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

The description uses a specific verb and resource: 'Mark every notification up to now as seen', and clearly states the effect of resetting the unread count. It is immediately distinguishable from sibling read-only tools like get_notifications and get_unread_count because it describes an action that changes state.

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

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

The description provides clear context for when to use the tool: to mark notifications as seen and reset the unread count. It does not explicitly name alternatives or exclusions, but for this simple mutation the implied usage is clear and no competing sibling tool exists.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds behavioral context: the action is private, reversible, and doesn't notify the target, and the target retains the ability to see and reply. This goes beyond the structured annotations 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.

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

Two sentences, front-loaded with the primary effect, then the key distinguishing details. No filler or repetition.

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

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 idempotent, non-destructive annotations and no output schema, the description and schema provide everything an agent needs to invoke it correctly. The lifecycle is covered by the sibling unmute_account.

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

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 both actor and account parameters. The description adds no additional 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.

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

The description uses a specific verb and resource ('Hide an account's posts from your feeds') and directly distinguishes the behavior from block ('Unlike a block, they can still see and reply to you'), making it easy to tell apart from sibling tools like block_account.

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

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

The description implies when to choose mute over block by contrasting visibility and interaction, but it doesn't explicitly state 'use this when...' or name the alternative by tool name. It gives clear context without formal exclusions.

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

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

The description adds 'Reposting twice is harmless', which aligns with the idempotentHint annotation and offers reassurance. The annotations already cover readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the description contributes only a modest amount beyond them; it does not mention side effects, rate limits, or undo behavior.

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

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

The description is two sentences, front-loads the core operation, and includes only useful extras: idempotency reassurance and an alternative-tool pointer. No filler or redundancy.

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

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

This is a low-complexity mutation tool with full schema parameter coverage and no output schema. The description provides the essential intent, idempotency, and a sibling alternative, which is largely sufficient; a minor gap is not describing what the tool returns on success.

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

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

Schema description coverage is 100%, with both uri and account already documented in the input schema. The description adds no parameter-level detail beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the action: 'Repost a post to your followers' — a specific verb and resource. It also distinguishes this tool from the sibling create_post by adding 'To add your own comment instead, use create_post with `quote`', so an agent can tell them apart.

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

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

The description explicitly routes the agent to create_post when the intent is to add a comment, which is a clear alternative. It does not, however, mention when to choose repost over unrepost or like, so the 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.

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

Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond that: the tool works without credentials and returns each account's bio and follower counts, which helps the agent understand the output and the intended verification use case.

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

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

The description is three sentences long and every sentence carries weight. The core action is front-loaded, followed by the credential requirement and the key output fields, with no filler or repetition of schema details.

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

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

Given the read-only annotations and a well-covered schema, the description is largely complete for invocation. It compensates for the missing output schema by summarizing the returned fields, though it does not mention pagination behavior or result ordering, which would make it fully complete.

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

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

Schema coverage is 75%, with q, limit, and account already described in the schema. The description enhances q by clarifying that bio text is searchable, but it adds no semantic detail for limit, cursor, or account. Cursor remains undocumented, so this is adequate but not exceptional.

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

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

The description starts with a specific action and resource: 'Find Bluesky accounts by name, handle or bio text.' This clearly differentiates the tool from sibling search tools like search_posts and search_feeds by targeting accounts and by naming the searchable fields.

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

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

The description gives useful context for when to use the tool, including the search criteria and the fact that it works without credentials. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to select it over the sibling search tools.

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

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds scope ('custom feeds only, algorithmic feeds anyone can publish') and an access trait ('Works without credentials') that go beyond the annotations. 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.

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

Three short sentences with no filler: the first states the purpose, the second provides a useful onward path, and the third gives a key access detail. It 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.

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

For a simple search tool with full schema coverage and safety annotations, the description covers the domain, the next step, and credential requirements. The lack of a note on result format is a minor gap given there is no output schema, but it is not critical for invoking the tool correctly.

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

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

Schema description coverage is 100% with detailed parameter descriptions for q, limit, and account. The description adds little beyond the schema beyond defining the search object and credential requirement, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Find') and resource ('custom feeds'), and clarifies the resource type as 'algorithmic feeds anyone on Bluesky can publish.' It also differentiates from get_feed by pointing there for reading a feed, making the purpose unmistakable.

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

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

The description gives clear usage context: this tool discovers custom feeds, and it explicitly routes follow-up reading to get_feed. It also notes that it works without credentials, a useful condition. It does not explicitly contrast with search_posts or search_actors, but the resource type makes the intended use clear.

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

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

Annotations already mark the operation read-only, non-destructive, open-world, and idempotent. The description adds meaningful auth-related behavior: it requires a connected account and notes that Bluesky's public API refuses this endpoint, which is a real-world constraint an agent needs before calling.

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

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

Two dense, front-loaded sentences: the core purpose comes first, followed by a compact operator list and auth caveat. 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.

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 8 parameters, the schema plus description covers the required query, optional filters, account selection, pagination ('Pages automatically'), and the auth caveat. Even without an output schema, the return value is self-evident from 'search across public posts'.

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

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

Schema coverage is high (88%), so the baseline is 3. The description adds value by enumerating the accepted query operators (from:, to:, mentions:, domain:, since:, until:, lang:, quoted phrases), which the schema only gestures at with 'Operators like from:alice.bsky.social work inside it'.

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

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

The opening phrase 'Full-text search across public posts' names a specific verb (search) and resource (public posts), and the operator list distinguishes it from sibling tools like search_actors and search_feeds. It unambiguously identifies what the tool returns: matching posts.

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

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

The description implies use for keyword/operator search on public Bluesky posts and warns that a connected account is required, but it does not explicitly say when to prefer this over sibling search tools or when not to use it. The prerequisite is clear, yet alternative-selection guidance is left to inference.

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

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

Annotations already indicate this is mutating (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds useful behavioral context beyond annotations by stating that 'existing replies stay unless you hide them,' which clarifies a potentially surprising side effect.

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

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

The description is short, front-loaded with the primary action, and every sentence contributes something: the action, the secondary capability, and the situational use case. No filler or redundant restatement of the schema.

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

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

For a four-parameter mutation tool with rich schema descriptions and no output schema, the description plus schema covers the needed invocation context well. It could optionally mention what the call returns or confirm the effect, but nothing essential is missing for calling it correctly.

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

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

Input schema coverage is 100%, and each parameter already has a clear description. The tool description adds no extra parameter-level meaning beyond what the schema provides, so it stays at the baseline.

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

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

The description uses a specific verb ('Change who is allowed to reply') with a clear resource ('one of your existing posts, after it is already published'), and adds a secondary capability (hiding specific replies). This clearly distinguishes it from sibling tools like create_post or delete_post.

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

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

The description gives clear context: it is for posts that already exist and are published, and it is described as 'the main tool for a post that is going badly.' It does not explicitly name alternatives or exclusion conditions, but the timing boundary is reasonably clear.

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

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

Beyond the annotations, the description discloses a non-obvious side effect: follows severed by the original block do not automatically return, and both users must follow again. This is valuable behavioral context that an agent would not infer from the schema or 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.

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

The description is three short sentences, front-loaded with the core action and followed by the key behavioral caveat. There is no filler or repeated information.

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

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 no output schema, the description sufficiently explains what happens and the important consequence about follows. It is not missing critical information for an agent to invoke the tool correctly.

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

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

Schema description coverage is 100%, so actor and account are already well documented in the input schema. The description adds nothing about parameters, which is acceptable given that the schema carries the full meaning.

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

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

The description states a clear action, 'Remove a block,' which maps directly to the tool's name and title. It is unambiguous about the operation, though it does not explicitly differentiate itself from sibling tools like block_account or unmute_account.

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

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

There is no guidance on when to use this tool versus alternatives such as unmute_account or block_account. The description implies the obvious use case of reversing a block, but it does not explain when this tool is appropriate or how it differs from other relationship-modifying tools.

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

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

Annotations already convey idempotency and non-destructiveness. The description adds meaningful behavioral context by explaining that the tool derives the follow record from viewer state, so the caller does not need to supply a follow record ID or look one up beforehand.

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

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

Two short sentences with no filler. The core action is front-loaded, and the second sentence earns its place by clarifying a non-obvious implementation detail. Nothing is redundant.

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

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

For a simple mutation with a single required parameter, the description plus schema covers what the agent needs. It doesn't describe the response, but no output schema exists and unfollow outcomes are standard. Minor gap: no mention of what happens if the account isn't currently followed, though idempotentHint partially covers this.

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

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 'actor' and 'account'. The description's phrase 'so you only need the handle' reinforces but does not add meaning beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description uses a specific verb and resource ('Stop following an account') and goes beyond the title by revealing the mechanism (finds your own follow record from viewer state). This clearly distinguishes the tool from the sibling 'follow' and related actions.

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

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

The intended use is immediately clear from 'Stop following an account' and the context of sibling tools. It does not explicitly contrast with mute or block, but the action is unambiguous and the note about needing only the handle provides practical guidance.

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

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

Beyond the annotations (idempotentHint, destructiveHint), the description reveals a non-obvious behavioral detail: the tool discovers the like record from the post's viewer state rather than requiring a like ID. This helps the agent understand why the like parameter is unnecessary and that it operates on the caller's own like.

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

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

Two sentences with no fluff. The action verb is front-loaded, and the second sentence delivers valuable implementation context that justifies why fewer parameters are needed. Both sentences earn their place.

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

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

For a simple idempotent mutation with no output schema, the description fully explains the operation and input requirements. The account parameter is documented in the schema, and the return behavior is not critical for correct invocation. A minor gap is the lack of explicit mention of what happens when no like exists, but the idempotent annotation covers this.

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

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

The schema covers 100% of the parameters with clear descriptions, so the baseline is 3. The description adds a small reinforcement that only the post is needed, but this does not meaningfully extend the parameter documentation already present in the schema.

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

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

The description states a specific verb ('Remove') and resource ('your like from a post'), clearly identifying the tool's action. The added detail about finding the like record from the post's viewer state distinguishes it from like_post and other sibling actions, leaving no ambiguity about scope.

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

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

The description clearly conveys when to use this tool—when removing your own like from a post—and explains that only the post URI is needed. It does not explicitly name alternatives or exclusions, but the action is so straightforward that the context is sufficient for correct selection.

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

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

Annotations already convey readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the description need not restate them. It adds some context by specifying that unmuting affects post visibility ('hiding'), but it does not describe side effects, idempotency behavior for already-unmuted accounts, or result details. Description 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.

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

The description is one short sentence that communicates the core behavior with no filler. It is front-loaded and easy to parse.

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

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

For a simple, idempotent unmute operation, the description plus the rich schema and annotations are largely complete. It could be slightly stronger by explicitly connecting to mute_account, but nothing essential is missing for invoking the tool.

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

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

The schema covers both parameters (actor, account) with descriptions, including the actor handle/DID format and the optional acting-account behavior. Since schema description coverage is 100%, the description does not need to add parameter details, and the baseline of 3 applies.

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

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 action (unmute) and the affected resource (an account's posts). It is specific enough to distinguish from most siblings, but it does not explicitly name or contrast with mute_account, so it falls short of full sibling differentiation.

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

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

The wording implies this tool should be used to reverse a previous mute, but the description gives no explicit when-to-use guidance or alternative selection (e.g., not for unblocking). Usage context is inferred rather than stated.

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

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

Annotations already convey the core behavioral profile: readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds useful scoping via 'your' to show only the acting account's repost is affected, but it does not go into additional edge-case behavior such as what happens when no repost exists.

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

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

The description is a single, immediately scannable sentence with no filler. It front-loads the verb and the object, which is exactly what an agent needs to understand and invoke the tool.

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

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

For a simple mutation with two well-documented parameters, strong annotations, and no nested objects, the description is complete. The agent can determine when to call it, what it does, and which parameters to provide from the schema.

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

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

The schema already documents both parameters fully (uri and account), so the description does not need to add parameter detail. The description provides no extra meaning beyond what the schema already covers.

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

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

The description states a specific action ('Remove') on a specific resource ('your repost of a post'), making the tool's purpose immediately clear. It also distinguishes itself naturally from the sibling tool 'repost' by being the inverse operation.

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

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

The intended usage is clear from context: call this when you want to undo a repost. It does not explicitly discuss alternatives or exclusions, but the inverse relationship with 'repost' makes misrouting unlikely.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds value beyond that by revealing it performs an authentication check ('confirm credentials work') and returns a 'live profile' with follower counts, giving behavioral context about freshness and failure modes.

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

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

The description is two sentences with no filler. The primary function is front-loaded, followed immediately by concrete usage triggers. Every clause earns its place.

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

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

For a read-only tool with one optional parameter, no output schema, and strong annotations, the description covers the essentials: what it does, what it returns (profile, follower counts, handle, DID), and when to invoke it. Nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, and the schema's parameter description is rich: it explains how to specify the account, the default behavior, and directs the agent to list_accounts. The tool description itself adds no additional parameter semantics, 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.

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

The description states a specific verb-resource pair: 'Authenticate and return the live profile for a connected account, including follower counts.' It also provides concrete use cases ('confirm credentials work' and resolving 'me'/'my'), which clearly differentiates it from siblings like get_profile or list_accounts.

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

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

The description explicitly says when to use this tool: 'Use this to confirm credentials work, or when the user says "me" or "my" and you need their handle and DID.' It also references list_accounts in the parameter description, guiding the agent on how to handle the account parameter.

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