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

The description aligns with the annotations (readOnlyHint=false, destructiveHint=true) and adds specific value by naming the destructive effect: 'clear stored session'. It clarifies that the operation mutates local session state, though it does not detail whether a server-side token is revoked.

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 sentence conveys the action, the target, and the side effect without wasted words. The phrasing 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 zero-parameter logout tool, the description plus annotations provides all necessary context: it is destructive, read-write, and affects the stored Bluesky session. No return value documentation is required because there is no output schema and the operation's result is straightforward.

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 is empty, so there are no parameters to document; the baseline of 4 applies. The description adds no parameter details, but none are needed.

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 action ('Log out') and the target resource ('Bluesky'), and adds the concrete side effect 'clear stored session'. It is immediately distinguishable from sibling ariel_auth_status, which checks session state rather than ending it.

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 context—when an agent needs to end the current Bluesky session—is clear from the description. There are no explicit alternative comparisons or when-not-to-use clauses, but with no parameters and a unique purpose among the auth siblings there is little 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate the safety profile. It adds a little context about what data is returned (handle, DID, profile info, rate limits), but does not describe error behavior, response format, or whether authentication is required. With annotations covering the main safety aspects, a score of 3 is appropriate.

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 wasted words. Every phrase adds information about the tool's scope, and it is immediately readable.

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 status check with annotations already declaring safety, the description covers the core purpose and the kinds of data returned. The main gap is that "profile info" is vague and the return payload is not described, but the simplicity of the tool makes this a minor omission.

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, and schema coverage is trivially 100%, so the baseline is 4. The description enriches the context by naming the specific data points returned, which is useful even though there is nothing to explain about 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 clear verb ("Check") and resource (Bluesky authentication state) plus specific data points like handle, DID, profile info, and rate limits. It is easy to understand what the tool does, though "profile info" is slightly ambiguous about whose profile is meant. It does not explicitly differentiate from siblings like ariel_get_profile, but the auth-state focus is distinct enough.

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 ariel_auth_logout or ariel_get_profile. There is no mention of prerequisites, typical scenarios, or situations where another tool would be more appropriate, so the agent must infer usage purely from the verb.

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 merely restates the action and adds no behavioral context beyond the annotations. It does not explain what blocking does on Bluesky, such as preventing the user from interacting, hiding content, or whether it is reversible. Annotations already indicate a non-read, non-destructive operation, so the description adds no additional 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 clear, front-loaded sentence with no wasted words. It efficiently communicates the core action.

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 one-parameter mutation, the description is minimally viable, but it lacks context about the effects of blocking and how it differs from muting. No output schema exists, so some additional behavioral context would have made the description more 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%, with the single 'actor' parameter already documented as 'Handle or DID of the user to block'. The description itself adds no parameter-level detail, but it doesn't need to because the schema fully covers 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 states a clear, specific action ('Block') and resource ('a user on Bluesky'), which is immediately understandable. It does not explicitly differentiate from sibling tools like ariel_mute or ariel_unblock, but the action is distinct enough on its face.

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 about when to use this tool versus alternatives such as ariel_mute, ariel_unblock, or ariel_follow. The usage context is only implied by the verb 'Block' and the sibling 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?

Annotations already establish readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds the auto-detection behavior, which is useful context, though it largely repeats what the schema's text property already states and does not disclose success/error behavior or authentication needs. 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?

A single sentence with no filler, front-loaded with the verb and resource, and the distinguishing feature included compactly. 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 mutation tool with no output schema, the description does not indicate what the caller gets back (e.g., post URI) or when to prefer very close siblings. Schema and annotations cover parameters and safety well, but the missing return-value and routing information leaves an agent guessing on selection and post-invocation expectations.

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% — both parameters (text, langs) are documented in the schema itself — so the baseline of 3 applies. The description's auto-detection phrase mirrors the text property description and adds no parameter-level information 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 states a specific verb-resource pair ('Create a new post on Bluesky') and adds a distinguishing behavioral feature (automatic mention/link/hashtag detection). It is clear and actionable, but it does not explicitly distinguish itself from close siblings like ariel_create_post_with_link_card or ariel_create_post_with_images, stopping just 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?

No when-to-use guidance, exclusions, or alternatives are mentioned. The sibling set contains several near-equivalents (ariel_create_post_with_link_card, ariel_create_post_with_images, ariel_create_thread, ariel_reply), and the description gives the agent no basis for choosing among them; the auto-detection phrase describes behavior, not usage direction.

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 only mark the tool as not read-only and not destructive; the description matches this by saying 'Create'. It adds the file-size and count limits (1MB, 4 images), which are beyond annotations, but does not cover auth requirements, rate limits, or post-creation behavior. With minimal annotations, the description carries partial but not full behavioral burden.

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?

One sentence with the action front-loaded and constraints in a parenthetical. There is no filler or redundant content; every element 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 create tool with a fully described schema and no output schema, the description plus schema cover the essential inputs and limits. It lacks explicit sibling differentiation and auth context, but those are minor given the tool's simplicity and the schema richness.

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 baseline is 3. The description adds a meaningful 1MB-per-image constraint not present in the schema, and reiterates the 4-image maximum, giving operational semantics beyond parameter names. It does not detail text or alt, but the schema already documents those adequately.

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 ('Create'), names the resource ('a post with attached images'), and adds hard constraints (max 4 images, 1MB each). This clearly distinguishes it from siblings like ariel_create_post (no images) and ariel_create_post_with_link_card (link card) without needing to inspect the schema.

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 the tool is for posts that require image attachments, but it never explicitly states when to prefer it over ariel_create_post or when not to use it. There are no exclusions or alternative routing, so an agent must infer usage from the name and sibling context. This is implied usage, not 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?

The description discloses the external behavior of fetching Open Graph metadata, which is meaningful beyond the readOnlyHint/destructiveHint annotations. It doesn't cover failure handling when the URL has no OG metadata, but annotations already cover the basic safety profile, so the added behavioral detail 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?

The description is a single front-loaded sentence with no redundant filler. It conveys the action, the specific format, and the key behavioral detail in minimal 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?

For a simple create action with two required parameters and complete schema descriptions, the definition gives the essential context. It does not describe the return payload or error behavior, and there is no output schema, but invocation-relevant information is sufficient.

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 text, url, and langs adequately. The description hints that url is used to generate the card, but it does not add significant meaning 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 uses a specific verb ('Create') and a specific resource ('post with a link card'), and the parenthetical 'fetches Open Graph metadata for preview' adds a distinguishing behavior. This clearly separates it from sibling tools like ariel_create_post and ariel_create_post_with_images.

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 tool when creating a post that should include a link card with a preview. It does not explicitly name alternatives or state when not to use it, but the context is specific enough for an agent to infer the appropriate use case.

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 (readOnlyHint=false, destructiveHint=false) align with the 'Create' verb, so there's no contradiction. The description adds the useful behavioral trait that posts are chained as replies to one another, but for a compound write creating N posts it discloses nothing about partial failure, atomicity, or auth requirements.

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 zero filler; the main action is front-loaded and the second sentence earns its place by explaining the chaining mechanism. Appropriately sized for a tool with a single parameter.

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?

Input-side coverage is complete (description + schema fully specify the posts array and constraints), and annotations cover the read/write safety profile. However, with no output schema, the description doesn't communicate what the tool returns (e.g., created thread/post IDs), and for a multi-resource write there's no information about failure behavior if one post in the chain fails.

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 the posts array, min 2 items, text, and langs. The description adds meaning beyond the schema by explaining the relationship between array elements — that each post becomes a reply to the previous one — which reinforces that order is semantically significant, not just a structural constraint.

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 (create) and resource (a thread of multiple posts), and the chaining detail ('each post is chained as a reply to the previous one') differentiates it from single-post siblings like ariel_create_post and ariel_reply. It stops short of naming those alternatives explicitly, so it's clear but not maximally explicit.

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 context is implied rather than stated: the 'multiple posts' and reply-chaining semantics signal this is for threaded multi-post sequences rather than single posts. However, there is no explicit when-to-use guidance, no named alternatives, and no exclusions for cases that should route to ariel_reply or ariel_create_post_with_images.

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 state destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds the useful ownership scope ('your posts') but does not disclose permanence, side effects on replies or reposts, or failure behavior. It does not contradict the annotations.

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

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

The description is a single concise sentence with no filler, and the core action is front-loaded. It is appropriately sized for a one-parameter destructive 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 low-complexity tool with one well-documented parameter and destructive annotations, the description provides the essential ownership constraint. It does not describe outputs or edge cases, but those are not required given no output schema and straightforward semantics.

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 the single parameter 'uri' fully as the AT URI of the post to delete, and schema description coverage is 100%. The description adds no parameter-level detail, 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 uses a specific verb ('delete') with a named resource ('one of your posts') and clearly restricts the operation to the caller's own posts. Among the sibling tools, no other tool performs post deletion, so the purpose is 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?

No guidance is given about when to use this tool versus alternatives, nor are prerequisites mentioned such as authentication or that only the author may delete the post. The ownership restriction is implied by 'your posts' but not expanded into actionable 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 indicate this is a non-read-only, non-destructive action, but the description adds no behavioral detail beyond that. It does not mention idempotency, authentication needs, or side effects like creating a follow relationship.

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 filler. It states the action and platform clearly while remaining as concise as possible.

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 one-parameter tool with full schema coverage, the description is nearly sufficient, but it omits usage guidance and behavioral context such as authentication requirements and expected outcomes. An agent could call it, but may not know when to prefer it or what to expect in edge cases.

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 parameter description already fully documents the actor field as a 'Handle or DID of the user to follow.' The tool description adds nothing beyond the schema, so 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 names a specific verb and resource: 'Follow a user on Bluesky.' It clearly identifies the action, though it does not explicitly contrast itself with sibling tools like ariel_unfollow, ariel_mute, or ariel_block.

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 about when to use this tool versus alternatives such as ariel_unfollow, ariel_mute, or ariel_block. No prerequisites like authentication are mentioned either.

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 annotations already establish readOnlyHint=true and destructiveHint=false. The description adds the scoping fact that this targets a specific user's feed rather than a global or timeline feed, but it provides no further behavioral detail such as pagination behavior, authentication needs, or result format.

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 focused sentence with no filler. It front-loads the core operation and leaves parameter details to the schema, earning its place without unnecessary elaboration.

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 fully documented parameters, the description is mostly adequate for invoking the tool. However, with no output schema and several feed-like siblings, an agent would benefit from knowing what a returned feed contains and when to choose this over ariel_get_feed or ariel_get_timeline.

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 all five parameters are already documented in the input schema. The description itself adds no parameter-level detail, which matches the baseline for high-coverage schemas.

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 clear verb-resource pair: 'Get posts' from 'a specific user's feed'. It scopes the operation to a single user's feed, which distinguishes it from generic feed or timeline tools, though it does not explicitly name sibling 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?

There is no guidance on when to use this tool versus siblings like ariel_get_timeline, ariel_get_feed, or ariel_get_posts. No exclusions, prerequisites, or alternatives are mentioned, 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to repeat safety information. The description adds the 'custom feed / feed generator' scoping, which clarifies the data source, but it does not disclose additional behavioral details such as auth requirements, rate limits, or pagination behavior beyond the 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 a single, front-loaded sentence with no filler or redundancy. Every word contributes to identifying the tool's 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 description is sufficient for a basic retrieval tool with fully documented parameters and read-only annotations, but it does not mention the response shape or explicitly differentiate from similar feed/list tools. There is no output schema to compensate for this, so some gap remains.

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 all four parameters are already documented in the input schema. The description does not add additional parameter-level meaning beyond what the schema provides, making the baseline 3 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 ('Get posts') and the resource type ('custom feed (feed generator)'). It distinguishes itself from sibling tools like ariel_get_timeline and ariel_get_author_feed by implication, but it does not explicitly differentiate 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 provides no guidance on when to use this tool versus alternatives such as ariel_get_timeline, ariel_get_author_feed, or ariel_get_list_feed. There is no mention of exclusions, prerequisites, or conditions that would route an agent to a sibling tool.

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 the safety profile is covered. However, the description adds no additional behavioral context such as pagination behavior, authentication needs, or what data is returned; it merely restates the tool's function.

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 short sentence with no wasted words and is appropriately front-loaded with the action. It is concise, though it could have used the available space to add distinguishing or usage context.

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 tool, the schema fully documents the parameters and the annotations cover the safety profile. The main gap is the lack of guidance around pagination and the relationship to the similar ariel_get_follows sibling, leaving the description minimally adequate but not 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 description coverage is 100%, so parameters are already well-documented in the schema. The description contributes little beyond identifying that the target is a user, which is baseline value when the schema already explains the 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 ('Get') and names a clear resource ('a user's followers'), so the basic purpose is unambiguous. It does not explicitly differentiate itself from the similar sibling ariel_get_follows, which appears to cover the accounts a user follows rather than their followers.

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 given about when to use this tool versus alternatives such as ariel_get_follows. The description simply states the action with no context, exclusions, or mention of related tools, leaving the agent to infer the appropriate use case.

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 declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds no further behavioral context such as pagination behavior, response ordering, or rate-limit implications. It does not contradict the annotations, but it also does not enrich 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?

A single, front-loaded sentence with zero waste. It states the operation in the most direct way possible.

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 description conveys the core output concept but no output schema exists to clarify the response shape. It does not describe how limit and cursor affect the results or what fields each returned user contains. Adequate for a simple getter, but missing enough detail to fully guide 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 schema already documents actor, limit, and cursor. The description implicitly ties 'a user' to the actor parameter but adds nothing beyond what the schema provides.

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 is a specific verb+resource statement: 'Get users that a user follows.' It clearly identifies the operation and distinguishes it from the sibling tool ariel_get_followers, which would return the reverse relationship.

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 explicit guidance about when to choose this tool over alternatives. It does not mention the closely related ariel_get_followers or any criteria for selecting between them. The user must infer usage from the tool name and description 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'Get' aligns with that safety profile. It adds that the response includes metadata and members, but does not disclose pagination behavior, authentication requirements, or error behavior. Given the annotation coverage, this is acceptable but not rich.

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

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

A single sentence that front-loads the operation and object with no filler or redundancy. It is appropriately sized for a simple read-only list metadata 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?

The description is minimally sufficient for a low-complexity read operation: it names the return contents (metadata and members) and the schema covers parameters. However, there is no output schema, so it could be more explicit about response shape and pagination, and it does not mention the closely related list-feed 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?

Schema description coverage is 100%, so the schema fully documents list, limit, and cursor. The description adds no parameter-level semantics beyond naming the high-level purpose, 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?

States a specific verb ('Get') and resource ('a list's metadata and members'), which clearly differentiates it from the sibling ariel_get_list_feed (which returns a feed of posts). The description leaves no doubt about the object being retrieved.

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 when an agent needs list metadata or membership, but it does not state when to choose this over ariel_get_list_feed or other related list tools. No exclusions or alternative routing 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, safely covering the mutability profile. The description adds the resource scope ('from a list feed') but does not disclose any additional behavioral traits such as pagination behavior, format effects, or auth requirements beyond what the schema and annotations already 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?

The description is a single, short sentence with no filler, which is concise. However, it is so terse that it does not provide the context needed to confidently select among several similar feed-related sibling tools, so it earns only a mid-range score.

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 and annotations cover parameters and safety, but the description omits usage guidance, sibling differentiation, and any clarification of what 'list feed' means versus other feed types. Given the large sibling set and no output schema, the description is minimally viable but leaves important selection context to the 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 parameters like list, limit, cursor, and format are already documented. The tool description adds no parameter-level meaning, but with full schema coverage 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 uses a specific verb ('Get') and resource ('posts from a list feed'), clearly identifying this as a read operation for list-based content. It is distinguishable from related siblings like ariel_get_list (list metadata) and ariel_get_author_feed, though it does not explicitly differentiate itself from ariel_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 no guidance on when to use this tool versus alternatives such as ariel_get_feed, ariel_get_timeline, or ariel_get_author_feed. There is no mention of prerequisites, exclusions, or the fact that it requires a list AT URI, leaving the agent to infer usage 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=true and destructiveHint=false, so the safety profile is established. The description adds context about what kinds of notifications are returned, but it does not mention ordering, pagination behavior, or whether fetching might affect read state. This is acceptable given 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, front-loaded sentence that names the resource and its relevant categories with no filler. Every word contributes to understanding the tool's 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?

For a simple read-only getter with three optional, fully described parameters and clear annotations, this description is mostly complete. Minor gaps remain: there is no output schema and no explicit statement about default limit or pagination behavior, but the schema already explains the cursor and limit constraints.

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 limit, cursor, and format are already documented at the schema level. The tool description adds no parameter-specific meaning beyond the notification-type scope, so the baseline 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 states a specific action and resource—'Get recent notifications'—and enumerates the content categories (likes, reposts, follows, mentions, replies). This makes the tool's purpose clear and distinguishable from sibling getters like ariel_get_timeline or ariel_get_unread_count.

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

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

The phrase 'recent notifications' implies this tool is for reading notification activity, but the description provides no explicit guidance about when to choose it over related siblings such as ariel_get_unread_count or ariel_mark_notifications_read. No alternatives or exclusions are named.

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 the safety profile is clear. The description adds the batch-retrieval behavior and max-25 limit, but does not discuss error handling, ordering, or response details; with annotation coverage, this is adequate but not rich.

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

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

The description is one concise, front-loaded sentence with no filler. Every part adds information: action, resource, lookup key, and batch limit.

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 batch fetch with two well-documented parameters and safety annotations, the definition is largely complete. It could mention response shape or ordering, but the schema and annotations cover the essential invocation details.

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 explains both `uris` and `format` including the enum and defaults. The description adds no additional parameter meaning beyond what the schema provides, 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 states a specific verb ('Get'), a specific resource ('posts'), and the lookup mechanism ('by their AT URIs'), with the batch limit included. This clearly distinguishes it from sibling 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 implies the correct usage context: when you already have AT URIs and need to fetch multiple posts at once. It does not explicitly mention alternatives or when-not-to-use, but the context is clear enough for selecting this tool.

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 the safety profile is covered. The description adds a small behavioral detail by specifying that the response includes parents and replies, but it does not disclose anything about depth limits, URL handling, or output behavior beyond what the schema already states.

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

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

A single sentence with no filler. The core resource and scope are front-loaded, and every word earns its place.

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

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

For a simple read-only retrieval tool, the description plus fully documented parameters is enough for an agent to invoke it correctly. There is no output schema, but the description communicates the essential return concept (post plus parents and replies) adequately.

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 all four parameters (uri, depth, format, parentHeight) are already documented in the input schema. The description adds no additional meaning about how parameters interact or affect the returned thread.

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 ('Get') and the resource ('a post and its thread'), with a parenthetical clarifying that the thread includes both parents and replies. It is easy to distinguish from sibling tools like get_posts or get_timeline, though it does not explicitly name any alternative.

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 the tool is for fetching a single post along with its conversation context, which is enough to infer a typical use case. However, it gives no explicit guidance on when to prefer this over related tools such as ariel_get_posts or ariel_get_timeline.

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?

readOnlyHint and destructiveHint already cover the safety profile, and the description does not contradict them. It does not add behavioral details such as authentication requirements, rate limits, or how the digest output differs from JSON, so credit is limited. The profile framing is consistent, making this a 3 rather than a 1 or 2.

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 filler, which is appropriate for a simple tool. It could include brief usage guidance, but it is easily parsable and wastes no tokens.

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 a sense of what 'profile information' includes would be valuable; the description does not provide it. It also doesn't disambiguate from overlapping sibling tools. Still, with two well-described parameters and read-only annotations, the description is minimally viable.

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 descriptions for both actor and format and an enum for format. The tool description itself adds no parameter-level guidance, but the schema already carries that burden, so the baseline 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 names a clear verb ('Get') and resource ('a user's profile information'), so the agent knows what the tool returns. It doesn't explicitly contrast with siblings like ariel_get_author_feed or ariel_get_followers, so it doesn't earn a 5.

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 statement about when to use this tool instead of ariel_get_author_feed, ariel_get_followers, ariel_get_follows, or other profile-adjacent tools. With 37 siblings, leaving this entirely to inference is a meaningful gap.

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, covering the safety profile. The description adds the scoping detail that it operates on the authenticated user's own feeds (implying auth is required), but doesn't disclose whether saved and pinned feeds are returned together or separately, ordering, or pagination behavior. 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?

A single sentence with zero filler. Verb, scope, and resource are all front-loaded, and every word earns its place for a tool this simple. There is no redundant repetition of the tool name or 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 simple list-fetch tool with one optional fully-documented parameter and read-only annotations, the description covers the essentials. The 'authenticated user's' framing signals the auth requirement, and the format parameter handles the output shape. Minor gap: it doesn't describe what a single feed entry looks like, but that is a light gap for a tool this trivial.

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% — the format parameter is fully documented with enum values, the default ('json'), and its purpose ('compact text for LLM consumption'). The description adds nothing about parameters beyond what the schema already states, 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?

States a clear verb ('Get') and resource ('saved and pinned feeds') scoped to the authenticated user. It is immediately understandable. However, it doesn't explicitly differentiate from siblings like ariel_get_feed and ariel_get_author_feed, leaving the agent to infer the distinction from the word 'saved'.

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?

Provides no guidance on when to use this tool versus alternatives. It never mentions ariel_get_feed, ariel_get_timeline, or ariel_get_list_feed, nor any condition that would select this tool over them. The usage context must be inferred entirely from the tool name.

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 the safety profile is covered. The description adds that hours mode fetches all posts within a time window, and the schema adds 'max 500' and that cursor is ignored in hours mode. The description itself doesn't add much behavioral context beyond the schema, but annotations cover the main safety traits, so a 3 is appropriate.

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?

One clean sentence front-loads the main purpose and then gives the most important usage tip. There is no filler. It loses a point because it could also explicitly point to siblings or output considerations, but structurally it is efficient.

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 read-only timeline tool with fully documented parameters and annotations covering safety, the description is mostly complete. Gaps remain: no mention of what the response looks like (no output schema) and no explicit note that count is the default mode. These are minor, so a 3 is fair.

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 all four parameters. The description reinforces hours mode behavior but adds no new semantics beyond what the schema already says. Baseline 3 is appropriate when the schema does 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?

States a specific verb and resource: 'Get the authenticated user's home timeline.' It is clear that this returns a home timeline for the authenticated user, which is distinct from the sibling get_feed, get_author_feed, and get_posts. However, it doesn't explicitly name a sibling or distinguish itself in the way the highest-scoring examples do, so it falls just short of 5.

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 one usage hint: 'Use mode hours to fetch all posts within a time window.' This implies when to switch from the default count mode, but it doesn't say when to prefer this over siblings like get_feed or get_author_feed. It provides no exclusions or alternatives, so it is adequate but 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds genuinely useful context beyond the annotations: it discloses reliance on an unspecced endpoint that may change, flagging potential instability. It does not go into rate limits or response shape, but with annotations present the bar is lower.

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 sentence plus a high-value parenthetical. The purpose is front-loaded and the stability warning earns its place; there is zero wasted 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 read-only tool with two optional parameters and full schema coverage, this is adequate. The main gap is that with no output schema present, the description does not describe the return shape or what the 'digest' format produces beyond the enum label. An agent can still call it correctly, but a bit more return-value context would round it out.

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 limit and format are already fully documented in the input schema. The description adds no parameter-level detail, so the baseline 3 applies — the schema does 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?

States a specific verb (Get) and resource (trending topics on Bluesky). No sibling tool covers trending topics, so it is immediately distinguishable from ariel_get_timeline, ariel_get_feed, and the search tools.

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 by the purpose statement — an agent wanting trending topics would select this — but there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives. The endpoint-stability warning is about reliability, not usage routing.

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 and non-destructive, so the safety profile is covered. The description adds little behavioral context beyond the scoped count, which is acceptable for such a simple read operation, but it does not mention behavior such as whether the count reflects only the current session or includes all 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?

A single, front-loaded sentence perfectly captures the whole tool with no wasted words. It is minimal but exactly as concise as the tool's simplicity allows.

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 parameterless, read-only tool, the description provides the essential information: what is being counted and that the result is a number. It is slightly thin on alternative guidance, but nothing critical is missing for an agent to invoke it correctly.

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

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

The tool has zero parameters, so there is no parameter ambiguity to clarify. The baseline for a no-parameter tool is 4, and the description appropriately focuses entirely on the output 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 exactly states a specific verb ('get'), resource ('unread notifications'), and returns a number, making the tool's purpose unmistakable. It distinguishes itself from the sibling get_notifications by focusing on the unread count rather than the notification list.

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 count of unread notifications. However, it does not explicitly contrast with related tools like ariel_get_notifications or note when a full list would be 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?

The description adds no behavioral context beyond what the annotations already convey: readOnlyHint=false implies a write operation and destructiveHint=false implies it is not destructive. It does not disclose idempotency, what happens if the post is already liked, or any side effects such as notification or feed changes. This does not contradict the annotations, but it also contributes nothing beyond 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 three words and contains no filler. For a simple single-parameter mutation tool, this is appropriately sized and the core action 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 the tool's low complexity, the complete schema, and the annotations covering the read/write/destructive profile, the description is largely sufficient for an agent to understand the operation. Some context is missing around prerequisites and alternates, but nothing that prevents a correct 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 the uri parameter fully documented as 'AT URI or bsky.app URL of the post to like'. The description 'Like a post' adds no parameter meaning 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 'Like a post' uses a specific verb and resource, and is clearly distinguishable from sibling tools like ariel_unlike, ariel_repost, ariel_reply, and ariel_quote_post. It lacks extra detail about the action's effect, but the core purpose is 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?

There is no guidance on when to use this tool versus alternatives, no mention of authentication requirements, and no explanation of how it relates to ariel_unlike or other engagement tools. The intended context must be inferred entirely from the tool name and one-line description.

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 a non-read-only, non-destructive mutation. The description adds the important scope detail that all notifications are affected, not just one. It does not contradict the annotations, but it adds limited behavioral context beyond the schema and annotation signals.

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, front-loaded sentence conveys the complete action with no filler. Every word contributes meaning: 'Mark', 'all', 'notifications', and 'as read' together fully specify the 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 zero-parameter, non-destructive mutation with no output schema, the description is fully adequate. The annotations cover the read-only/destructive safety profile, and the description covers the effect and scope. Nothing essential is missing for an agent 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?

The tool has zero parameters, and schema coverage is effectively 100% because there is nothing to document. The description correctly communicates the action without needing parameter details, so the baseline 4 for zero-parameter tools 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 ('mark'), a clear resource ('notifications'), and the exact state change ('as read'). It is unambiguous and easily distinguished from sibling tools like ariel_get_notifications and ariel_get_unread_count, which retrieve rather than modify.

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 action itself: call this when the user wants all notifications marked read. However, the description does not explicitly state when to prefer this over related notification tools, provide context like 'after viewing notifications', or mention that no alternative sibling performs this action.

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 indicate readOnlyHint=false and destructiveHint=false, but the description adds no behavioral context beyond the verb 'Mute.' It does not mention authentication requirements, side effects, reversibility, or what muting actually changes for the user. There is no contradiction with the annotations, but no additional transparency is provided.

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, front-loaded sentence with no filler. It communicates the core action immediately and 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 single-parameter mutation tool with no output schema, the description plus schema allow basic invocation. However, it lacks any usage context, behavioral explanation, or notes about response or side effects, so it is only minimally 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 description coverage is 100%, and the single parameter 'actor' is already described as 'Handle or DID of the user to mute.' The description adds no 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 uses a specific verb and resource: 'Mute a user on Bluesky.' It clearly states what the tool does. It does not explicitly differentiate from siblings like ariel_unmute or ariel_block, but the action is unambiguous enough for an agent.

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 such as ariel_block or ariel_unfollow. There is no mention of prerequisites, situation, or exclusions, leaving the agent to infer appropriate usage.

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 readOnlyHint=false and destructiveHint=false, so the mutation/safety profile is covered. The description adds the quote-specific behavior beyond those annotations, but says nothing about auth requirements, failure modes, or how the quoted content is rendered. It is minimally transparent.

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?

One tight, front-loaded sentence with zero filler. Every word contributes meaning, and the size matches the low complexity of 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?

Combined with 100% schema coverage and annotations, the definition is adequate to understand what the tool does and what parameters are needed. However, there is no output schema and no mention of return behavior or auth prerequisites, so the context is functional but not complete for an agent needing richer operational detail.

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 text, langs, and quotedUri. The description only reinforces the quotedUri concept and adds no additional meaning about formats, interactions, or constraints 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?

States clear verb ('Create') + specific resource ('a post that quotes another post'), which distinguishes it from ordinary create_post or reply. The quote behavior is the core distinguishing feature and it is explicit.

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 the user wants to quote an existing post, but it gives no explicit guidance about when not to use it or which sibling alternative (reply, repost, create_post) to choose instead. Usage is inferable but not spelled out.

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 (readOnlyHint=false, destructiveHint=false) already establish this as a non-destructive write, lowering the bar. The description adds one genuinely useful behavioral trait beyond annotations: automatic thread-root resolution, which affects where the reply lands in the conversation tree. However, it does not disclose authentication requirements (relevant given the ariel_auth_status sibling) or failure/error behavior, and there is no output schema describing the response.

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 filler. The primary purpose is front-loaded in the first sentence, and the single most valuable behavioral detail (thread-root resolution) occupies the second. 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 write operation, the description plus annotations cover purpose, safety profile, and the key threading behavior, and the schema fully documents parameters. The notable gap is the return value: there is no output schema and the description never states what the agent should expect back (e.g., the created reply's AT URI, which it would need for follow-up actions like like or delete). Authentication context is also absent.

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% — text, langs, and parentUri each carry descriptions in the schema, so the baseline is 3. The description adds only marginal value by connecting parentUri to the thread-root resolution behavior, but provides no parameter syntax or format detail beyond what the schema already states.

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 action ('Reply') and resource ('a post') in the opening sentence, making the core purpose unambiguous. The second sentence adds a distinguishing behavioral detail (automatic thread-root resolution). However, it never explicitly contrasts with sibling tools like ariel_create_post, ariel_quote_post, or ariel_create_thread, so differentiation rests entirely on the verb 'Reply' rather than named comparison.

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 context is implied by the verb: use this when the intent is to reply to an existing post. The thread-root resolution note implicitly argues for using this over manually constructing a reply, but the description gives no explicit when-to-use/when-not-to-use guidance and names no alternative tools, despite a large sibling set of overlapping post-creation actions.

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 annotations indicate a non-read-only, non-destructive action, and the description adds no behavioral detail beyond that. It doesn't explain that a repost record is created, whether a URI is returned, or that the action can be reversed via ariel_unrepost.

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, direct sentence with no wasted words. However, it is so minimal that it mostly restates what the tool name already implies, providing little extra informational value.

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 mutating action with no output schema, this is too thin. An agent isn't told what a successful repost returns, how it differs from quote-posting or liking, or that it can be undone, all of which matter for correct tool selection and expected 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 schema already covers the single parameter at 100% and gives a useful type description: 'AT URI or bsky.app URL of the post to repost'. The description above adds no further parameter meaning, so the baseline of 3 applies.

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

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

States a specific verb and resource: repost a post. The action is clear and unmistakable, but it does not differentiate from sibling tools such as ariel_quote_post or ariel_like beyond the function name.

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 on when to use this tool versus alternatives. It doesn't mention preconditions, use cases, or how to choose between reposting and posting a quote, liking, or un-reposting.

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 the safety profile is covered. The description adds the 'with metadata' output hint but does not disclose any other behavioral details such as auth requirements, rate limits, or what the metadata contains.

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 with no filler. It front-loads the action and resource, and every word contributes to the purpose.

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

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

For a one-parameter, read-only, non-destructive tool, the definition is largely complete. The only notable gap is that 'with metadata' is vague and the absence of an output schema means an agent must infer what metadata is returned, but this is minor relative to the tool's simplicity.

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 fully documents the single parameter with a description identical in substance to the tool description. The tool description adds no extra detail such as URL format examples, accepted protocols, or normalization behavior, so it meets but does not exceed the baseline for 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 clearly states a specific verb ('Convert') and resource ('a bsky.app URL to an AT URI'). This distinguishes the tool's purpose from the many fetch, create, and action siblings, even though no sibling performs an identical conversion.

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 usage context is implied by the description: use this when you have a bsky.app URL and need an AT URI. However, there is no explicit when-to-use guidance, no exclusion criteria, and no mention of alternatives or prerequisites such as authentication.

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 the safety profile is covered, but the description adds zero behavioral context beyond those annotations: no mention of pagination behavior, search-index delay, the dual json/digest output modes, or rate limits. The four-word description is essentially a restatement of the tool name and contributes nothing the schema and annotations do not already 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?

The description is maximally brief with no wasted words, which is structurally clean. However, for a tool with 9 parameters, a digest output mode, and a large sibling family, a single four-word sentence is under-sized rather than appropriately sized; the brevity is achieved by omitting, not compressing, useful 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?

Given 9 parameters, no output schema, and many sibling tools, the description is incomplete: it does not explain the json/digest format distinction, pagination, filter semantics, or how search results differ from feed/timeline/list retrieval. An agent relying solely on this description plus schema would still be uncertain about return shape and tool selection.

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 all 9 parameters (query, lang, sort, limit, since, until, author, cursor, format) with types, enums, and ranges. Per the baseline rule, the description need not repeat parameter info, and it does not add any meaning beyond the schema—no departure from 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?

States a specific verb and resource: 'Search for posts on Bluesky.' The verb 'search' conveys query-based lookup, which visually distinguishes it from sibling get/fetch tools (ariel_get_timeline, ariel_get_feed, ariel_get_author_feed). However, it does not explicitly name or contrast the sibling search alternative (ariel_search_users) or other post-retrieval tools, leaving some differentiation to inference.

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. With 37 siblings—including ariel_search_users, ariel_get_posts, ariel_get_feed, and ariel_get_timeline—an agent is given no decision criteria (e.g., query-based keyword search vs. fetching a feed vs. retrieving known posts). No when-to-use, when-not-to-use, or alternative-selection context is offered.

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 the read-only nature is known. The description adds only 'on Bluesky' and does not disclose output shape, pagination behavior, auth requirements, or any other behavioral nuance beyond what annotations already convey.

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

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

The description is a single short sentence with no redundant words, making it concise. However, it is so terse that it does not include any useful structural context such as what results look like or how this relates to sibling tools.

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 a search tool that clearly needs to convey matching behavior and result format, the description is too thin. An agent does not know whether results are profiles, how they are ranked, whether pagination is cursor-based, or what the 'digest' format returns beyond the schema enum.

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 clear descriptions for query, limit, cursor, and format. The tool description itself adds no parameter-specific meaning, 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 'Search for users on Bluesky' clearly identifies the verb (search), resource (users), and platform, which distinguishes it from sibling search_posts. It is concise and clear, though it does not specify whether the search matches handles, display names, or both.

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 about when to use this tool versus alternatives such as ariel_search_posts or ariel_get_profile. The intended use can be inferred from the name, but no explicit context, exclusions, or alternative suggestions 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?

Annotations already declare destructiveHint=true, so the safety profile is known. The description adds that the block record is automatically resolved from viewer state, which is useful but not elaborated. It does not describe side effects, irreversibility, or failure modes beyond what the annotation implies. This is a reasonable but not rich behavioral 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?

Two sentences with zero waste. The primary action is front-loaded, and the clarifying detail about auto-resolution is placed second. Every word serves a purpose, and the description is appropriately sized for a simple 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 one-parameter destructive action with annotations and full schema coverage, the description is mostly sufficient. However, it does not explain what 'viewer state' means, nor does it mention what happens if the user is not currently blocked or if the actor is invalid. These gaps are minor but could confuse an agent. The output schema is absent, so return behavior is also unaddressed.

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 for its single parameter, which is described as 'Handle or DID of the user to unblock'. The tool description adds nothing about the parameter beyond the schema, but the schema fully documents it. Per the baseline, a 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 clear verb and resource: 'Unblock a user'. It adds a detail about auto-resolving the block record, which distinguishes it from sibling tools like ariel_block. However, it doesn't explicitly differentiate from the inverse operation or mention specific conditions, so it's clear but not exemplary.

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, no prerequisites, and no conditions or exclusions. The auto-resolution note hints at usage but does not explain when it's appropriate or how it differs from, say, unfollow or unmute. There is no explicit 'when not to use' or mention of alternative 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 carry the safety profile (destructiveHint=true, readOnlyHint=false), and the description is consistent with them. It adds one useful behavioral detail — the follow record is resolved automatically from viewer state — which tells the agent the operation targets the viewer's own follow graph and needs no prior lookup. It does not disclose idempotency, error behavior when the actor is not followed, or reversibility. 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 tight sentences with zero filler: the action comes first, the mechanism second, and each clause carries information an agent needs. 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 single-parameter mutation whose annotations cover the destructive profile and whose schema fully documents the parameter, this is nearly complete. The mechanism clause resolves the main ambiguity an agent would have — whether it must supply a follow-record ID. Minor gaps are the absent output schema, leaving return behavior unspecified, and no statement about idempotency or errors on a non-existent follow; both are low-stakes for such a simple operation.

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%: the actor property is already documented as 'Handle or DID of the user to unfollow'. The description adds no param-specific syntax, format, or validation detail beyond what the schema provides, so on this dimension it contributes little. With full schema coverage, 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 action verb 'Unfollow' plus the resource 'a user' is specific and unambiguous, and it is naturally distinct from sibling tools like ariel_follow, ariel_unmute, and ariel_unblock. The second sentence adds mechanism detail about resolving the follow record from viewer state, which sharpens the picture. However, no sibling is named explicitly, so the agent must infer the distinction from the action verb alone.

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 context is implied: use this when the agent wants to end a follow relationship, and the 'Automatically resolves' clause signals that no follow-record ID needs to be looked up first. But there is no explicit when-to-use/when-not guidance, no statement of prerequisites such as whether the actor must currently be followed, and no routing to the inverse ariel_follow or to the similar ariel_unblock/ariel_unmute for contrast.

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 destructiveHint=true, so the destructive nature is known. The description adds useful behavioral detail beyond annotations: it will auto-resolve a post URI to the like record rather than requiring the caller to fetch it first. This is valuable operational context.

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 the action, followed by the input clarification. Every word earns its place; no filler or redundant schema 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 single-parameter destructive action with full schema coverage and annotations covering the destructive profile, the description provides all needed invocation details: what action, what input, and the two accepted URI forms. No output schema exists, but for this simple mutation the absence is not a critical 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?

The schema already documents the uri parameter at 100% coverage, so baseline is 3. The description adds the auto-resolution behavior of post URIs, which is a meaningful semantic detail not present in the schema property 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?

States the exact action ('Unlike a post') and differentiates from sibling tools like ariel_like and ariel_unrepost by the negative verb and explicit resource. The second sentence further clarifies the accepted input object, so an agent cannot confuse it with 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 operation is stated directly, so the intended use (removing a like on a post or via like record) is clear. It doesn't explicitly name the alternative ariel_like or state 'use when you want to remove an existing like,' but the context and sibling list make the selection obvious.

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=true, so the safety profile is covered. The description adds no behavioral context beyond the operation itself, such as idempotency or behavior when the actor is not currently muted.

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, direct sentence with no filler. The verb and target are front-loaded, making it maximally concise for a simple 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?

The tool has one required parameter, no enums, no output schema, and annotations that establish its side-effect profile. The description is sufficient for a simple state-changing operation, though it could note idempotency or error behavior for non-muted actors.

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 already documents 'actor' as a handle or DID. The description only repeats the word 'user' and adds no additional parameter 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 states a specific verb ('Unmute') and a specific resource ('a user on Bluesky'). It clearly identifies the inverse of ariel_mute and is distinguishable from related sibling tools like ariel_unblock.

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 siblings such as ariel_mute or ariel_unblock. There is no mention of prerequisites, expected state, or exclusion criteria.

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 annotations already flag destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutation; 'Remove' is consistent with that. The description adds one genuine behavioral trait — auto-resolving a post URI to the repost record — which goes beyond the schema's mere enumeration of accepted input forms. It does not disclose failure modes or what happens when no repost exists, so the added context is useful but modest.

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?

One sentence, roughly 16 words, with the core action 'Remove a repost' front-loaded and no filler. The behavioral nuance is appended compactly in a parenthetical rather than in a padded second paragraph. 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 one-parameter, low-complexity, destructive tool without an output schema, the essentials are covered: what it does, what input to pass, and how the input is resolved. A documented edge case (e.g., behavior when no repost exists) would justify a 5, but 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%, so the param's dual input forms ('AT URI of the post to unrepost, or the repost record URI') are already documented — baseline 3. The description restates that and adds only a small operational nuance ('auto-resolves repost record,' 'directly'). This does not rise meaningfully above 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 opens with a specific action-resource pair, 'Remove a repost,' which identifies exactly what the tool does. This clearly separates it from ariel_repost (its inverse) and ariel_delete_post (which deletes a user-authored post rather than a repost record), even without naming siblings. The input detail further pins the scope: post URI or repost record URI.

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 use case is implied — undoing a prior repost — but there is no explicit when-to-use or when-not-to-use guidance against alternatives such as ariel_delete_post or ariel_repost. The note that a post URI auto-resolves the repost record is operationally useful for invocation, but the agent must infer the selection criteria from the tool name and sibling context rather than from stated 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 show this is not read-only and not destructive, and the description clarifies it uploads data and returns a reference rather than directly creating a post. However, it does not mention authentication requirements, upload size limits, or other side effects beyond what the annotations already imply.

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?

One sentence communicates the action, the target system, the return value, and the downstream purpose. Every word is functional and 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 simple three-parameter upload utility with full schema documentation, the description is nearly complete: it states the action and the return value. It falls slightly short by not clarifying how the returned blob reference should be consumed by post-creation tools, but it is still adequate for a helper of this complexity.

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 three parameters. The description adds no additional parameter-level meaning beyond calling the input an 'image blob,' which only loosely maps to imageData.

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?

Description uses a specific verb ('Upload') with a clear resource ('an image blob to Bluesky') and states the returned artifact ('a blob reference for use in post creation'). This distinguishes it from sibling tools like ariel_create_post_with_images, which likely upload and attach in one step.

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 'for use in post creation' implies this is a pre-step for posting, but it does not explicitly state when to use this tool versus alternatives like ariel_create_post_with_images. Usage context is implied, not spelled out.

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