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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not mention edge cases (e.g., invalid URLs), whether only post URLs are supported (schema says 'post URL' but description says 'web URL'), or the exact shape of the returned value (plain string vs. object). This leaves significant unknowns for an agent.

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

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

The description is a single, front-loaded sentence that immediately conveys the action and output. Every word serves a purpose, and it avoids extraneous detail.

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

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

Given no output schema, the description should clarify the return value format (e.g., 'returns a string') and any input constraints (e.g., only post URLs). It does not, nor does it mention error handling or supported URL types, leaving the agent to guess about behavior that is not inferable from structured data.

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

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

The schema covers the only parameter with a description and example, so schema_description_coverage is 100%. The tool description adds no additional parameter details beyond what the schema provides, which meets the baseline but does not elevate it.

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

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

The description clearly states a specific verb ('Convert') and resource ('Bluesky web URL') with a distinct output ('AT URI format'). This distinguishes it from sibling tools, which are all CRUD/search operations, making the tool's purpose unambiguous.

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

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

The description implies usage context: when you have a Bluesky web URL and need an AT URI for other tools. It does not explicitly state when not to use it or name alternative tools, but the conversion-focused purpose naturally separates it from siblings in the list.

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

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

With no annotations, the description carries full responsibility for disclosing behavioral traits. It only states the action without mentioning that the post becomes publicly visible, requires authentication, or has any side effects. There is no information about rate limits, error behavior, or the fact that it is a write operation.

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

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

The description is a single, clear sentence with no filler or redundancy. It is appropriately sized for the tool's simplicity and front-loads the core purpose.

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

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

The tool is a write operation with no output schema and no annotations. The description is minimal and fails to include important context such as how to construct a reply (via replyTo), expected response, or any prerequisites. Given the availability of sibling tools like 'convert-url-to-uri' and 'get-post-thread', this description leaves gaps for an agent to correctly invoke the tool in all scenarios.

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

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

The input schema has 100% coverage with descriptions for both parameters ('text' and 'replyTo'). The description adds no additional meaning beyond the schema, but schema ambiguity is minimal. Baseline 3 is appropriate given full schema coverage.

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

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

The description clearly states the tool's function with a specific verb ('Create') and resource ('a new post on Bluesky'). This distinguishes it from sibling tools like 'repost' or 'like-post', which have different actions.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention that it should be used for original posts, or that to reply to an existing post, the replyTo parameter should be populated with a URI. There is no explicit context or exclusion.

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

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

No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only states the action ('Follow a user on Bluesky') and does not mention idempotency, effects on existing relationships, return values, or failure modes. This is a significant gap for a mutation tool.

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

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

The description is a single, concise sentence that is front-loaded with the action and resource. No unnecessary words or details, earning a top score for efficiency.

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

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

The tool is simple with one parameter and no output schema, so the description is minimally adequate. However, without any annotation or output information, a truly complete description would mention what happens after following (e.g., returns nothing, or returns the follow record). It meets the minimum viability bar.

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

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

Schema coverage for the parameter is 100%: the 'handle' property is clearly described as 'The handle of the user to follow'. The description adds no extra semantic value beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Follow') and resource ('a user on Bluesky'), making the tool's purpose immediately clear. It also distinguishes from the sibling 'unfollow-user' tool by naming the action directly.

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

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

The description implies usage (call this to follow a user), and the sibling 'unfollow-user' provides a natural contrast, but there is no explicit statement about when to use vs. alternatives or any prerequisites. It is adequate for such a simple tool but lacks explicit guidance.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'fetch posts' and omits details such as pagination, sorting, rate limits, or return format. The read-only nature is implied but not explicitly stated.

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

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

The description is a single, clear, front-loaded sentence with no wasted words. It is appropriately sized for the simple operation.

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

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

Although the schema fully documents parameters, the lack of an output schema means the description should clarify what the tool returns. The description is too terse and does not mention response structure, which could leave an agent uncertain about expected output.

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

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

The input schema provides descriptions for all three parameters (feed, type, count) with full coverage. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool fetches posts from a specified feed, using a specific verb and resource. It distinguishes from sibling tools like get-user-posts or get-liked-posts by identifying the feed as the source.

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

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

No guidance is provided on when to use this tool versus alternatives such as get-timeline-posts or get-list-posts. The description only states the basic function without any context or exclusions.

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

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

There are no annotations, so the description must carry the full burden of behavioral disclosure. It implies a read operation ('Get') but does not mention pagination behavior (e.g., limit cap of 500), return format, sorting, rate limits, or authentication needs. This lack of context leaves important operational details undisclosed.

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

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

The description is a single, direct sentence with no filler words. It front-loads the verb and resource, making it immediately scannable. It is appropriately concise for a simple tool, though minimal in content.

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

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

Given the tool's simplicity (2 params, no output schema, no annotations), the description covers the core purpose but omits useful contextual details like pagination handling (limit caps at 500), the structure of returned user objects, and guidance on when to use this tool over get-follows. It is a minimum viable descriptor with clear gaps.

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

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

The input schema already provides complete descriptions for both parameters (user and limit) with 100% coverage. The tool description adds no parameter-specific semantics beyond what the schema offers, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb 'Get' and clearly identifies the resource as 'list of users that follow a person,' which unambiguously distinguishes it from the sibling tool get-follows (which would list who a person follows). This is a clear, specific statement of purpose.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention that get-follows is the counterpart for 'following' lists, nor any exclusions or preferred contexts. The description states only the action, leaving the agent to infer usage from the name alone.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic purpose and does not mention pagination, the default/maximum limit of 500, authentication requirements, rate limits, or the structure of the returned user objects. While it is a read-only operation, the description lacks depth expected for a complete behavioral picture.

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

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

The description is a single, concise sentence that immediately states the tool's purpose. It avoids unnecessary words or repetition, and every word contributes to clarity. This is an example of efficient, front-loaded writing.

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

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

The tool is simple with only two parameters and no output schema, but the description is minimal. It lacks any mention of return value details (e.g., what fields are included in each user object), how pagination works, or the distinction from 'get-followers'. While the core purpose is clear, the lack of behavioral context and sibling differentiation leaves gaps.

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

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

The input schema already provides full descriptions for both parameters: 'user' (handle or DID) and 'limit' (1-500 with default 500). Schema description coverage is 100%, so the description does not need to add parameter details. The description adds no extra meaning beyond the schema, but the baseline of 3 is appropriate since the schema is comprehensive.

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

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

The description clearly states the tool's function: 'Get a list of users that a person follows.' It uses a specific verb ('Get') and resource ('list of users'), and the phrase 'that a person follows' distinguishes it from the sibling tool 'get-followers' (which would return users who follow a person). This is a precise and unambiguous purpose statement.

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

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

The description provides no guidance on when to use this tool versus alternatives, and notably fails to differentiate it from 'get-followers'. There is no mention of context, prerequisites, or exclusions. The only implicit signal is the word 'follows' in the description, which a user might infer as directionality, but there is no explicit guidance.

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

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

No annotations are provided, so the description must fully disclose behavior. It only states that it gets liked posts but does not mention authentication requirements, ordering, pagination behavior beyond the limit parameter, error handling, or the response structure. This is minimal disclosure for a tool with no annotation support.

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

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

The description is a single, concise sentence that is front-loaded with the key verb and resource. It contains no unnecessary words or repetition and is easy to parse quickly.

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

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

Given the tool's simplicity (one parameter, no output schema), the description is adequate but minimal. It lacks any mention of response format, empty-list behavior, or authentication side effects, which would be useful for agents to fully understand the tool's output and potential failure modes.

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

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

The input schema fully describes the single 'limit' parameter (type, default, minimum, maximum). The description adds no extra meaning to this parameter, so the baseline of 3 applies given 100% schema coverage.

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

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

The description uses a specific verb ('Get') and clearly identifies the resource ('list of posts that the authenticated user has liked'), distinguishing it from sibling tools like get-post-likes (which lists users who liked a post) and get-user-posts (which lists posts created by a user).

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

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

The description clearly states the tool's purpose, implying it should be used when the authenticated user's liked posts are needed. However, it does not explicitly mention when not to use it or reference any alternative tools, though none of the siblings directly duplicate this functionality.

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

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

No annotations are provided, so the description carries the full burden. It only states 'Fetch posts' with no additional behavioral details such as authentication requirements, rate limits, sorting, or pagination. This is a minimal disclosure.

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

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

The description is a single, clear sentence with no wasted words. It is concise and front-loaded with the action and resource.

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

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

The tool is relatively simple with no output schema, but the description could provide more context about the 'type' parameter (posts vs hours) or what constitutes a 'list'. As is, it is minimally complete but leaves some ambiguity about behavior and return value.

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

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

All three parameters have schema descriptions (100% coverage), so the description does not need to explain them. The description itself adds no extra semantic value beyond what the schema already provides. Baseline score of 3 applies.

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

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

The description clearly states the action (fetch posts) and the specific resource (users in a specified list). This distinguishes it from sibling tools like get-user-posts or get-timeline-posts, which fetch from different sources.

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

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

The description implies that this tool is for fetching posts from a list of users, but it does not explicitly state when to use it over alternatives or any exclusions. The context is implied, not explicit.

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

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

With no annotations, the description carries the transparency burden and does disclose the key behavioral trait: it returns the authenticated user's identifiers and implies session/auth requirements. It does not discuss error behavior without a session, but for a simple read-only getter this is sufficient.

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

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

Two short sentences front-load the action and output. There is no filler, repetition, or unnecessary detail.

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

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

For a zero-parameter read-only tool, the description adequately states what is returned, for which user, and when it should be used. The absence of an output schema is compensated by explicitly naming the returned fields (handle and did).

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

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

There are zero parameters, so schema coverage is trivially complete and no parameter documentation is needed. The description adds no parameter semantics, but none are required for this tool.

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

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

The description uses a specific verb ('Return'), names the exact resources (handle and did), and scopes them to the currently authenticated user's session. This clearly distinguishes it from sibling tools that operate on other users or arbitrary profiles.

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

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

It explicitly gives a trigger condition: when someone asks about themselves using 'me' or 'my' on Bluesky. It does not mention alternatives or when not to use it, but the context is clear enough for selection.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only operation but doesn't explicitly state safety, authentication requirements beyond 'authenticated user', rate limits, or side effects. Minimal context beyond the action itself.

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

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

The description is a single concise sentence with no wasted words. It is front-loaded and efficiently communicates the core action and resource.

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

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

For a zero-parameter read tool, the description is adequate but incomplete. There is no output schema, so the description should explain what the response contains, but it only says 'pinned feeds and lists' without defining their structure or scope. An agent would need to infer the return shape.

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

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

The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameter behavior because none exist, and the schema confirms no inputs are required.

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

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

The description clearly states the action ('Get') and resource ('the authenticated user's pinned feeds and lists'), which is specific and unambiguous. However, it doesn't explicitly distinguish this from sibling tools like get-lists or search-feeds, though 'pinned' provides some implicit distinction.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no context about typical use cases, prerequisites, or exclusions, so an agent gets no help in deciding between this and similar feed/list tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the purpose and does not describe what 'information about users' includes, whether authentication is required, error handling, or any other behavioral traits. For a read tool, the absence of these details limits transparency.

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

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

The description is a single, front-loaded sentence with no unnecessary words. It conveys the essential purpose efficiently and is appropriately concise for a simple read operation.

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

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

For a simple tool with two well-documented parameters, the description is minimal but serviceable. However, the lack of an output schema and absence of any detail about the return payload or pagination behavior leaves it somewhat incomplete. Given the complexity, a slightly richer description would improve completeness.

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

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

The input schema has 100% coverage, describing both 'uri' and 'limit' with examples and ranges. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: retrieving information about users who liked a specific post. It uses a specific verb and resource ('get information about users', 'specific post') and distinguishes from sibling tools like 'get-liked-posts' which focus on posts liked by a user, not likes on a post.

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

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

The purpose is clear enough that usage is implied (when you need to see who liked a post). However, there is no explicit guidance on when not to use it or alternatives, such as using 'get-liked-posts' to see a user's liked posts. The description lacks any exclusions or alternative tool references.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It states that the tool returns replies and context, but it does not explicitly say whether the operation is read-only, how nested replies are handled, or whether the original post is included. The phrase 'full conversation thread' hints at completeness but lacks detail about limits or ordering.

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

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

The description is a single sentence that is front-loaded with the primary action ('Get a full conversation thread') and ends with a brief elaboration on the output. It is concise with no wasted words.

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

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

Given the simplicity (one parameter, no output schema, no annotations), the description is reasonably complete but lacks details about return structure, pagination, or any limitations on thread depth. It adequately states what is returned but leaves some operational ambiguity for an agent.

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

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

The schema covers 100% of parameters, including a description for the single 'uri' parameter. The tool description does not add any additional parameter semantics, but with full schema coverage, this is adequate.

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

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

The description uses the specific verb 'Get' with the resource 'full conversation thread' and scopes it to a specific post, clearly distinguishing it from siblings like get-timeline-posts or get-post-likes. The phrase 'showing replies and context' adds clarity about what is returned.

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

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

The description provides clear context for when to use this tool: when a full conversation thread for a specific post is needed. It does not explicitly mention alternatives or exclusions, but the use case is well-defined compared to other post-related tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action ('Get a user's profile') but does not mention return format, authentication needs, rate limits, or error conditions. This is minimal but not misleading.

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

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

The description is a single concise sentence that is front-loaded with the action and resource. It is appropriately sized for a simple tool with one parameter, and every word is useful. There is no wasted or redundant text.

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

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

For a straightforward getter with one parameter and no output schema, the description is minimally viable. It tells the user what the tool does, and the schema documents the parameter. However, it lacks detail about what exactly is included in the profile and when to prefer this over sibling tools, leaving some gaps.

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

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

The schema description for 'handle' is clear and complete, covering 100% of parameters. The description adds no additional parameter meaning, but the baseline for high schema coverage is 3, and the schema already provides sufficient semantics.

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

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

The description clearly states the action ('Get') and the resource ('user's profile') with a specified context ('from Bluesky'). It is unambiguous and distinct from siblings like get-my-handle-and-did or search-people, though it does not explicitly call out those alternatives.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention that it is preferred for fetching a specific profile by handle, nor does it exclude use cases like searching for people. The description offers no selection context.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. 'Fetch' implies a read-only operation, and 'reverse chronological order' explains the ordering behavior. However, it does not mention authentication requirements, pagination, rate limits, or the exact response structure, leaving gaps for an agent assessing side effects and usage constraints.

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

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

The description is a single, well-structured sentence that is immediately informative. It avoids fluff and provides the essential information (resource and content) in a clear, front-loaded manner.

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

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

Given the tool's simplicity and complete schema coverage, the description is nearly sufficient. It explains what the timeline contains and the ordering. However, because there is no output schema, a brief note about the return format (e.g., a list of post objects) would make it fully complete for an agent.

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

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

Schema description coverage is 100%, so the input schema already thoroughly explains both parameters ('count' as number of posts or hours, and 'type' as posts/hours). The description adds no additional parameter semantics, which is acceptable because the schema handles the heavy lifting.

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

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

The description uses a specific verb 'Fetch' and clearly identifies the resource as 'your home timeline from Bluesky'. It further distinguishes this from sibling tools by explaining it contains posts from followed people in reverse chronological order, which separates it from get-user-posts, get-feed-posts, and get-list-posts.

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

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

The description provides clear context about what the tool does (home timeline of followed users), making it easy to infer when to use it. However, it does not explicitly state when not to use it or mention alternatives, but the context is strong enough to guide selection among similar timeline-related tools.

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

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

With no annotations provided, the description must disclose behavioral context. It only says 'Get current trending topics' without noting whether the tool is read-only, whether authentication is required, what the response format looks like, or any rate-limit considerations. This is minimal behavioral disclosure beyond the basic verb.

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

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

The description is a single, concise sentence that conveys the core purpose without waste. However, it is extremely terse, bordering on under-specification for a tool with two parameters and no annotations.

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

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

For a simple query tool, the description plus complete parameter schema provide a basic understanding, but the lack of an output schema and any behavioral notes leaves some gaps. The description does not explain what 'trending topics' includes or how includeSuggested modifies the result.

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

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

The input schema fully describes both parameters (limit, includeSuggested) with ranges and defaults, so the description does not need to add parameter details. However, the description also does not add any extra meaning or context about how these parameters affect results.

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

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

The description clearly states the action ('Get'), the resource ('current trending topics'), and the platform ('Bluesky'). It distinguishes from sibling tools like get-timeline-posts and search-posts by specifying trends specifically.

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

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

The description provides no guidance on when to use this tool or when to prefer an alternative. It does not mention any distinguishing use cases, exclusions, or relationships to sibling tools like search-posts or get-feed-posts.

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

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

No annotations are provided, so the description carries full responsibility. It only says 'fetch posts' without explicitly stating read-only behavior, permission requirements, rate limits, or output format. The verb 'fetch' implies a read, but this is not fully disclosed.

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

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

The description is a single, concise sentence with no unnecessary words. While it is very brief, it is not overly verbose. However, it lacks any structured sections or additional context that might be expected for a tool with three required parameters.

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

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

For a tool with no annotations and no output schema, the description is too sparse. It does not explain the 'type' parameter (posts vs hours), which is critical to understanding count semantics, nor does it clarify output or handle resolution (handle vs DID). This leaves significant gaps for an agent to reason about correct usage.

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

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

Schema coverage is 100%, with each parameter (user, count, type) having a descriptive definition. The tool description adds no additional parameter context beyond the schema, so the baseline of 3 applies.

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

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

The description 'Fetch posts from a specific user' clearly identifies the action (fetch), resource (posts), and scope (specific user). It distinguishes this tool from siblings like get-timeline-posts or get-feed-posts by emphasizing the 'specific user' target.

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

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

There is no guidance on when to use this tool versus alternatives such as get-feed-posts, get-list-posts, or search-posts. No prerequisites, exclusions, or alternative recommendations are provided.

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

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

With no annotations, the description must fully disclose behavioral implications. It states only the action ('Like a post') without mentioning side effects, idempotency, permissions, or return behavior. For a mutation tool, this is a significant gap.

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

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

The description is a single five-word sentence, front-loaded and free of any filler. Every word earns its place, making it maximally concise.

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

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

The tool is simple with one parameter and no output schema, so minimal description is acceptable. However, it does not explain return values, failure modes, or whether the like is reversible, leaving some ambiguity for a complete invocation.

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

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

Schema description coverage is 100% and the sole parameter 'uri' is already described in the schema as 'The URI of the post to like'. The tool description adds no additional meaning or syntax details, so the baseline of 3 applies.

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

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

The description 'Like a post on Bluesky' uses a specific verb and resource, clearly distinguishing this tool from siblings like 'repost' and 'create-post'. It fully conveys the tool's purpose.

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

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

No guidance is provided on when to use this tool versus alternatives like 'repost' or 'create-post'. There is no mention of prerequisites, context, or exclusions, leaving usage entirely to inference.

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

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

With no annotations, the description carries the full burden. It states the scope of listing 'all available' and that descriptions are included, which is useful. However, it does not mention any potential side effects, error conditions, or output format details. For a simple read-only list operation, this is minimally adequate.

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

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

The description is a single sentence that exactly states the purpose. It is concise, front-loaded with the verb, and contains no filler or redundancy.

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

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

Given the tool's low complexity and empty input schema, the description is quite complete. It conveys what the tool returns (list of resources with descriptions) and the scope (all available). The absence of an output schema is compensated by this clear statement. A small gap is the lack of usage guidance, but that is minor for such a straightforward tool.

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

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

The tool has zero parameters, so the schema is empty and there is nothing to describe. Based on the rule, 0 params gets a baseline of 4. The description adds no parameter info because none exist.

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

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

The description uses a specific verb 'List', a specific resource 'MCP resources', and scope 'all available'. It clearly distinguishes from sibling tools which focus on posts, users, feeds, etc., while this tool targets the server's resources.

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

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

The description provides no guidance on when to use this tool vs alternatives. There are no exclusions or alternative mentions. The context is only implicit, but no explicit usage guidance is given.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and target, with no mention of read-only behavior, pagination, rate limits, authentication requirements, or what a 'custom feed' entails. This is a significant gap for a search operation.

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

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

The description is a single concise sentence that directly states the tool's purpose without redundancy. It is front-loaded and contains no filler, earning a high score for efficiency.

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

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

With no output schema, no annotations, and simple parameters, the description should compensate by explaining expected results or limitations. It does not mention return format, feed selection criteria, or any constraints beyond what the schema provides, leaving the tool poorly contextualized.

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

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

Schema description coverage is 100% as both 'query' and 'limit' have descriptions. The tool description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description 'Search for custom feeds on Bluesky' clearly states the action (search) and the target resource (custom feeds), distinguishing it from sibling tools like search-posts and search-people. It lacks extra specificity about feed attributes but is unambiguous enough to identify the tool's core purpose.

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

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

The description implies this tool should be used when searching for feeds specifically, given the resource is 'custom feeds'. However, it provides no explicit when-to-use guidance or alternatives, leaving the agent to infer based on sibling tool names.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states 'Search for users/actors' and does not mention read-only status, return format, pagination, rate limits, or any other behavioral traits. This is a significant gap for a search tool.

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

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

The description is a single sentence that directly states the purpose with no filler or redundancy. It is appropriately sized and front-loaded, making it easy to parse quickly.

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

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

Given the absence of annotations and output schema, the description should provide more context about return values, result structure, or usage notes. The tool is under-specified for a search operation, leaving the agent uncertain about what to expect from the invocation.

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

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

Schema description coverage is 100%, with both 'query' and 'limit' having descriptions in the schema. The tool description adds no new parameter-level information beyond the schema, so the baseline score of 3 applies.

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

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

The description 'Search for users/actors on Bluesky' clearly specifies the action (search), the resource (users/actors), and the platform (Bluesky). This distinguishes it from sibling search tools like search-posts and search-feeds, which target different resource types.

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

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

The description implies usage when looking for people on Bluesky but provides no explicit when-to-use or when-not-to-use guidance, nor does it name alternative tools. The context is clear from the resource type but lacks formal usage boundaries.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the purpose, omitting details about result format, pagination, sorting behavior, or side effects. While 'search' implies a read-only operation, this is not explicitly disclosed, leaving significant behavioral ambiguity.

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

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

The description is a single concise sentence ('Search for posts on Bluesky') that is front-loaded and free of fluff. Every word contributes meaning with no unnecessary additions.

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

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

With no output schema, the description should at least indicate the return value (e.g., a list of posts). It does not, and also omits mention of authentication, rate limits, or result fields. The tool is simple, but this minimal description leaves important contextual gaps for an agent deciding to invoke it.

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

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

The input schema has 100% coverage, with each parameter (query, sort, limit) having a clear description and the sort parameter documented with an enum. The description adds no extra parameter-level detail, so the baseline score of 3 is appropriate given the schema already carries the semantic weight.

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

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

The description clearly states the tool 'Search for posts on Bluesky' with a specific verb ('Search') and resource ('posts on Bluesky'). This distinguishes it from sibling tools like 'search-people' and 'search-feeds' by the target content type.

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

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

The purpose implies when to use it (when searching posts) but provides no explicit guidance on when to choose this over alternatives like search-people or search-feeds. There are no exclusions or alternative names referenced, so it meets the baseline but lacks explicit differentiation.

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