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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states only the action without mentioning side effects, idempotency, authentication requirements, or potential errors such as duplicate bookmarks or invalid tweet IDs.

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

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

The description is a single, direct sentence with no superfluous words. It is front-loaded and efficiently conveys 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 mutation tool with no annotations, no output schema, and only a single parameter, the description is too minimal. It omits behavioral details like idempotency, error conditions, and what the response or side effect will be, leaving significant gaps for an agent to infer.

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 has one parameter (tweet_id) with 0% schema description coverage, so the description must compensate. The phrase 'by id' only repeats the parameter name without adding meaning about format, constraints, or how to obtain the ID. Minimal semantic value is added.

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

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

The description uses the specific verb 'Save' and identifies the resource 'tweet' and destination 'bookmarks', making the action unmistakably clear. It distinguishes itself from sibling tools like like_tweet or retweet by naming the unique bookmarking operation.

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

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

The action is self-evident, but the description provides no explicit when-to-use guidance or alternatives. It does not mention that unbookmark is the inverse operation, nor does it clarify prerequisites or context for when bookmarking is 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. The word 'Delete' implies destructive and likely irreversible action, but the description does not explicitly state permanence, side effects on retweets/likes, or authentication requirements. This is minimally transparent but lacks explicit warnings common for deletion tools.

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 superfluous words. It front-loads the action ('Delete') and includes the necessary qualifier ('owned by the authenticated account') and parameter reference ('by tweet id'). 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?

Given the simplicity of the operation (one parameter, no output schema), the description is mostly complete: it states what is deleted and under what ownership condition. However, it omits return value information and potential side effects (e.g., irreversible removal), which a thorough description could include, especially without an output schema.

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

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

The schema already provides 100% coverage for the single parameter 'tweet_id' with a clear description. The tool description only references 'by tweet id,' which aligns with the schema but adds no additional semantic value. Baseline 3 is appropriate given 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 uses a specific verb 'Delete' with a clear resource 'a tweet owned by the authenticated account, by tweet id.' It unambiguously distinguishes from siblings like 'unlike_tweet' or 'unretweet', which modify engagement rather than removing the tweet itself. The scope ('owned by the authenticated account') adds precise context.

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

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

The description provides clear context for when to use the tool: to delete a tweet you own. It implicitly excludes deleting others' tweets by specifying 'owned by the authenticated account.' However, it does not explicitly mention alternatives (e.g., 'unlike_tweet' or 'unretweet' for non-destructive actions) or when not to use it, so it falls short of full 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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It merely says 'Follow a user' without mentioning required authentication, side effects, result/return behavior, or how duplicate/already-followed IDs are handled. This is behaviorally thin for a write action.

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 states the action and then provides the essential resolution hint in parentheses. Every word earns its place and there is no filler or redundancy.

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

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

For a simple one-parameter tool with no output schema and no annotations, the description covers the core action and input resolution adequately. It could benefit from mentioning auth or side effects, but given the low complexity, the provided text plus schema is enough to guide 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?

The input schema already fully documents user_id as a numeric rest_id, giving a high schema coverage baseline of 3. The description adds value by instructing the agent to resolve @handles via get_user first, clarifying how to obtain the expected parameter value. It does not introduce additional param details, but the prerequisite insight is meaningful.

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 ('Follow') and the resource ('a user'), and specifies the required ID format (numeric id). This distinguishes it from related siblings like unfollow_user and other user-related 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?

The parenthetical '(resolve a @handle with get_user first)' provides a clear prerequisite and practical guidance for obtaining the numeric user_id. It does not explicitly mention when not to use the tool or name reverse-action alternatives, but it gives enough contextual direction for correct 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?

With no annotations provided, the description carries the full burden. It discloses that the tool returns conversations and their most recent messages, which is useful. However, it omits behavioral details such as authentication requirements, rate limits, pagination, or sorting order. Since it is a read operation implied by 'fetch', it partially covers transparency but not deeply.

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 sentence, front-loaded with the action, and contains no filler. Every word is meaningful.

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

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

For a zero-parameter read tool with no output schema, the description is mostly complete: it states what it does and what it returns. It could add details like ordering or limits, but for the tool's simplicity, the description suffices.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific information, but none is needed. The empty schema is fully documented, and the description clarifies the return content.

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

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

The description clearly states the operation ('Fetch the direct-message inbox') and the resource, distinguishing it from sibling tools like send_dm. It is specific and not a tautology.

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

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

The description implies usage context (retrieving DMs) but does not explicitly state when to use this tool versus alternatives or mention any exclusions. For a unique operation like fetching the DM inbox, this is adequate but lacks explicit guidance.

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

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. It clearly states that the tool lists followers and adds useful return-field information ('id, username, name, counts'), implicitly indicating a read-only operation. However, it does not mention pagination, rate limits, or how the 'count' parameter affects results, which are relevant for a list operation.

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

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

The description is a single, compact sentence that states the action, resource, parameter prerequisite, and return fields. Every word earns its place with 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 relatively simple read-only list tool, the description provides core information: purpose, required parameter type, and return fields. However, it omits any explanation of the 'count' parameter (its meaning, default, or effect on results) and does not mention pagination or response shape. Since there is no output schema, these gaps leave some ambiguity for an agent invoking the tool for the first time.

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 only 50% (user_id is described, count is not). The description adds no new information about the 'count' parameter, and it only restates that user_id is numeric, which the schema already says. It fails to clarify how 'count' operates (e.g., page size or total limit), leaving the agent to rely on schema defaults and constraints.

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

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

The description uses the specific verb 'List' with a clear resource ('a user's followers') and explicitly mentions the numeric user id requirement. This distinguishes it from sibling tools like get_following and get_user, making the purpose unmistakable.

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

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

The description clearly implies the use case: when you need to retrieve a user's followers. It does not explicitly name alternatives or exclusions, but given sibling tools like get_following and get_user, the context is sufficient for correct selection. No misleading guidance exists.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic function and the numeric user id requirement. It does not disclose pagination or count limitations, ordering, return format, or any other behavioral traits relevant to a list operation. This is insufficient for a tool with no annotation safety net.

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, efficient sentence that is front-loaded with the core purpose. It is concise with no wasted words. However, it omits important operational details like count bounds or pagination, which could be included without excessive verbosity, so it loses one point for being overly sparse.

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 list tool with no output schema and no annotations, the description should explain what it returns and how to control result size. It only states the basic action and user id requirement, leaving count, pagination, and return format unexplained. This is incomplete for a tool that has a count parameter with bounds defined in the schema.

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

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

Schema description coverage is only 50%, covering user_id but not count. The description adds no additional meaning beyond what the schema already provides, and it completely ignores the count parameter. With half the parameters undocumented in both schema and description, parameter semantics are weak and incomplete.

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

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

The description uses a specific verb ('List') with a clear resource ('accounts a user follows'), and specifies the key input ('numeric user id'). This clearly distinguishes it from sibling tools like get_followers, which lists the inverse 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 intended use case is implied by the description: call when you need the list of accounts a user follows. However, there is no explicit guidance on when NOT to use it or mention of alternatives such as get_followers or get_user. The context is clear but lacks exclusionary or comparative guidance.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states a read operation without mentioning pagination via the count parameter, potential empty results, or any response format. It fails to disclose any behavioral traits beyond the basic action.

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

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

The description is a single sentence that conveys the core purpose efficiently. Every word contributes to meaning, with no filler or redundancy. It 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?

Given no annotations and no output schema, the description is too sparse to be complete. It does not explain the effect of the count parameter (e.g., pagination limits), nor the return structure. For an AI agent, the description alone is insufficient to invoke the tool confidently beyond the most basic call.

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

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

Schema coverage is 50% because only user_id has a description in the schema. The tool description repeats 'numeric user id' without adding new meaning, and it offers no explanation of the count parameter (default, max, min are in schema but no semantic purpose). The description does not compensate for the undocumented count parameter.

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

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

The description clearly states the tool retrieves tweets liked by a user, with the specific qualifier 'by their numeric user id.' This verb+resource+scope construction distinguishes it from siblings like get_user_tweets (which gets authored tweets) and like_tweet (which performs a like). 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, or reference sibling tools like get_user_tweets or search_tweets for alternative ways to retrieve likes. No 'use this when' context is provided.

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

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

With no annotations, the description carries the full behavioral burden. It states the core read behavior and scope (tweets mentioning the authenticated account), but does not disclose ordering, pagination, count semantics, or whether replies/quote tweets are included. The 'Get' verb implies non-destructive behavior, but richer context is absent.

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 8-word sentence that front-loads the verb and resource. There is no redundancy, fluff, or unnecessary detail, making it appropriately sized for a one-parameter 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?

Given the low complexity (one optional parameter, simple read) and no output schema, the description conveys the essential purpose and return type (tweets). However, gaps remain: the parameter's function is unexplained, result ordering and limits are unspecified, and the return structure is unknown. It is minimally viable but not thorough.

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 single parameter 'count' has 0% schema description coverage, and the tool description never mentions it. The agent must guess from the parameter name and schema constraints (min=1, max=100, default=20) that it limits the number of returned tweets. The description fails to compensate for the schema's missing documentation.

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 identifies a precise resource ('tweets that mention the authenticated account'). This clearly distinguishes the tool from siblings such as search_tweets (general search), home_timeline (followed users' tweets), and get_notifications (broader notification 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 its use case—retrieving mentions of the authenticated user—but provides no explicit guidance on when to choose this tool over alternatives like search_tweets or get_notifications. No exclusions, prerequisites, or alternative tool names are mentioned.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It implies a read operation but does not mention side effects (e.g., marking notifications as read), auth requirements, rate limits, or return format. 'Get' is suggestive but insufficient for full transparency.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose, making it highly concise.

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

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

Given there is no output schema or annotations, the description should explain return values and caveats, but it does not. It also omits any mention of the count parameter or how notifications are ordered/filtered. The tool is simple, but the description leaves notable gaps.

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

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

Schema coverage is 0% for the single parameter 'count', and the description does not mention it at all. While the parameter name is somewhat self-explanatory, the description adds no meaning beyond the schema's structural constraints (min/max/default), failing to compensate for the missing schema description.

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

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

The description clearly states the tool's function: 'Get recent notifications' for the account, listing specific types (likes, follows, mentions, replies). This distinguishes it from siblings like get_mentions or get_dm_inbox, making the resource and scope unambiguous.

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

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

The description gives no guidance on when to use this tool versus alternatives such as get_mentions or home_timeline. It simply states what it does without any exclusions, prerequisites, or context for selection.

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

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

Without annotations, the description carries the burden of transparency. It discloses the exact return shape (root and replies structure), which is valuable behavioral information. It doesn't address edge cases like missing tweets or truncated replies, but the details provided are sufficient for a read-only operation.

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

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

The description is two sentences, front-loaded with the purpose and output shape, followed by practical use cases. No unnecessary 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 simple get tool with one parameter and no output schema, the description provides the full output structure and use cases. It doesn't mention pagination or limitations, but these are not critical for basic usage.

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

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

The schema has no description for tweet_id, and the tool description only implies it's the tweet identifier. It doesn't specify the format or how to obtain the ID. With 0% schema coverage, the description should compensate more explicitly.

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

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

The description clearly states the tool retrieves a tweet's engagement and replies, with a specific verb and resource. It distinguishes from siblings like get_tweet by focusing on engagement metrics and reply content.

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

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

It provides explicit use cases: 'Use this to check likes on a tweet or read the replies people left.' This gives clear context, though it doesn't mention exclusions or 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?

With no annotations, the description carries full responsibility for disclosing behavior. It only mentions 'raw TweetDetail response', which hints at the return format but does not mention authentication needs, error behavior, rate limits, or side effects. The read-only nature is implied but not explicitly disclosed.

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

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

The description is a single, concise sentence that front-loads the core action ('Fetch a single tweet with its reply thread') and includes only essential qualifiers ('by tweet id', 'raw TweetDetail response'). 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 tool with one parameter and no output schema, the description gives a reasonable overview but misses key contextual facts such as authentication requirements, error handling, or what constitutes the 'reply thread'. Since the complexity is low, this is minimally adequate but not fully complete.

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

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

The schema has no description for the tweet_id parameter (0% coverage), so the description's phrase 'by tweet id' provides minimal added semantic value. It clarifies the purpose of the sole parameter but does not elaborate on format, constraints, or special cases, leaving the baseline at 3 due to the simple one-parameter 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 clearly states the action ('Fetch a single tweet with its reply thread') and the resource identifier ('by tweet id'), using a specific verb and resource. It distinguishes from most siblings like post_tweet or delete_tweet, but does not explicitly differentiate from get_thread, though mentioning 'raw TweetDetail response' adds some scoping.

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. Siblings like get_thread, get_user_tweets, and search_tweets may serve overlapping purposes, but the description does not mention any conditions or exclusions, leaving the agent to guess.

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

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

With no annotations, the description must carry the burden of disclosing behavior. It does mention the return type ('raw user object') and specific fields, which is useful, but it doesn't disclose potential side effects, authentication needs, or error behavior. The read-only nature is implied by 'look up,' but not explicitly stated.

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

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

The description is two sentences, front-loaded with the action, and contains no filler. Every word adds value, effectively showing what the tool does and what it returns.

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

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

This is a simple tool with one parameter and no output schema. The description adequately explains the return format ('raw user object') and the lookup method. It could mention rate limits or error cases, but for a straightforward profile lookup, it is sufficiently 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?

The schema already covers the single parameter fully with a description ('Handle without the @.'). The tool description adds 'by @username,' which is redundant. Thus the description adds no meaningful parameter semantics beyond what the schema provides, 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 clearly states the action ('Look up a user profile') and the specific resource ('by @username'). It distinguishes itself from sibling tools like get_user_tweets or get_followers by focusing on the profile object itself, making the purpose unambiguous.

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

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

The description gives clear context for when to use the tool (to retrieve a user profile by username) but does not explicitly mention alternatives or when not to use it. For instance, it doesn't say 'to get a user's tweets, use get_user_tweets.' This is a minor 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it only restates the core function and does not disclose return format, pagination behavior, or whether retweets and replies are included. This is a significant gap for a read tool with no structured metadata.

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

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

The description is two concise sentences with no fluff. The primary action is front-loaded, and the second sentence adds a directly relevant usage hint. 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?

There is no output schema, so the description should ideally explain the return value, but it does not. It also fails to mention how count affects results or any constraints like maximum tweets returned. The tool is straightforward, but the description leaves important gaps for an agent to use 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 description adds meaning to user_id by explaining that a numeric ID is expected and that get_user can resolve a username, which goes beyond the schema's type note. However, it says nothing about the count parameter, which lacks a schema description, leaving half the parameters without semantic elucidation.

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 'Get recent tweets from a user,' specifying the action (get), resource (tweets), and scope (from a specific user). This distinguishes it from sibling tools like get_tweet (single tweet), search_tweets (keyword-based), and home_timeline (own 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 explicit guidance on how to supply the user_id: either a numeric ID directly, or first using get_user to resolve a @username. It gives clear context for the main input scenario, though it does not mention when to prefer this tool over alternatives like search_tweets or get_likes.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It only implies authentication via 'authenticated account' but does not explicitly state the operation is read-only, whether pagination is supported, or what the response contains. This leaves significant behavioral gaps.

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 words. It is concise and directly names the action and resource. However, it is overly minimal, lacking any additional context that could be provided without bloating, so it earns a high but not perfect 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 tool has no output schema, no annotations, and only one parameter. The description does not explain the return format, authentication requirements in detail, rate limits, or how the timeline is sorted. For a simple read tool, this is partially adequate but still leaves key gaps, making it incomplete.

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 0%, and the description does not mention the 'count' parameter at all. The schema only provides numeric constraints (min 1, max 100, default 20) but no semantic meaning. The description fails to compensate by explaining how 'count' affects results, leaving the agent to guess.

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

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

The description clearly states the action ('Get') and the resource ('the authenticated account's For You home timeline'), which is specific and distinguishes it from sibling tools like get_user_tweets or get_tweet. The phrase 'For You' clarifies it's the algorithmic timeline, not a generic home 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. It doesn't mention scenarios like retrieving one's own feed versus a specific user's tweets, nor does it reference any sibling tools. No exclusions or prerequisites are stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action itself without explaining idempotency (e.g., what happens if the tweet is already liked), error behaviors, or authentication 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?

The description is a single, direct sentence with no extraneous words. It is front-loaded and every word contributes to the meaning.

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 like action with a single parameter, the description is adequate but leaves gaps: it does not specify whether the tool returns a value, how errors are handled, or any side effects beyond the like being recorded. However, given the simplicity of the operation, the minimal description is largely acceptable.

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?

With 0% schema description coverage, the description only reiterates that tweet_id is an identifier ('by id'), offering no additional detail on format, constraints, or interpretation beyond the schema's type definition.

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 ('like') and the resource ('tweet'), with the parameter referenced as 'by id'. It distinguishes the tool from sibling actions like 'unlike_tweet' or 'retweet' through its specific verb and resource.

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

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

There is no guidance on when to use this tool versus alternatives such as 'bookmark' or 'retweet'. It does not mention prerequisites like authentication or conditions under which liking is 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?

No annotations are provided, so the description carries the burden. It discloses that the action is a publish (a write operation) and that it returns the URL of the created tweet, which is valuable. However, it omits any mention of rate limits, irreversibility, or authentication requirements beyond the implied 'authenticated account', leaving behavioral gaps.

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 exactly two sentences, front-loaded with the core action and return value, and the second sentence provides a useful parameter hint. There is no redundant or filler content.

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

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

For a simple two-parameter tool with full schema coverage and no output schema, the description covers the essential purpose and return behavior. It falls slightly short in not addressing potential confusion with quote_tweet or providing any context about when to use this tool versus alternatives, but overall it is adequately 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% for both parameters, with clear descriptions for text (including the 280-char/note-tweet distinction) and reply_to. The description's mention of 'Use reply_to to reply to an existing tweet id' adds little beyond the schema's 'Optional tweet id to reply to', so the baseline of 3 is appropriate.

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

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

The description clearly states the action ('Publish a new tweet') and the resource scope ('from the authenticated account'). It distinguishes this from mutating tools like delete_tweet or like_tweet, and the phrase 'new tweet' sets it apart from retweet/quote actions, even though quote_tweet is a sibling.

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 a direct usage hint for the reply_to parameter ('Use reply_to to reply to an existing tweet id'), which implies a common use case. However, it does not explicitly compare this tool to alternatives like quote_tweet or retweet, nor does it provide any exclusions or when-not-to-use guidance.

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

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

No annotations are provided, so the description must carry the burden. It discloses the core behavior (publication), the required input (quoted tweet), and the return (new tweet URL). However, it does not discuss side effects (notification to the quoted user), authentication requirements, or failure modes. It is minimally transparent but not comprehensive.

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, no redundancy, front-loaded with the tool's name and core function. Efficient and clear.

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

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

For a simple two-parameter tool with no output schema, the description covers the function, input requirements, and output. It lacks details about authorization and side effects, but overall it is sufficient for 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 covers both parameters with descriptions (text: 'Your commentary'; quoted: 'URL or id of the tweet to quote'). The description adds nuance by specifying 'bare id' and framing the action as 'publish text quoting another tweet', which clarifies the relationship between parameters. It also mentions the return URL, which is not in the schema. This adds meaning beyond the schema, though the schema already provided high coverage.

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

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

The description clearly states the action: 'publish `text` quoting another tweet' – a specific verb (publish) and resource (a quote tweet). It distinguishes from siblings like post_tweet and retweet by specifying the quote behavior and the need for a quoted tweet's URL or id.

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

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

The description implies when to use: when you want to post a quote tweet with your commentary. It also specifies the input requirement (the quoted tweet's id or URL). However, it doesn't explicitly compare to sibling tools like retweet or post_tweet, so the guidance is clear but not exhaustive.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. However, it only states the action without any consequences, permissions, or side effects (e.g., creates a public retweet, may fail if already retweeted). This fails to inform the agent about important behavioral traits.

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

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

The description is a single, direct sentence with no wasted words. It is well-structured and front-loaded. However, it is so brief that it omits essential information, so it does not earn a perfect 5.

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

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

For a simple tool with one parameter and no output schema, the description is still thin. It does not mention return behavior, error cases, or any preconditions like authentication. Thus, it lacks the richness needed for a tool in a broader API context.

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 one parameter, tweet_id, with no description. The description's 'by id' adds no significant meaning beyond the parameter name; it does not specify the ID format, source, or any constraints. With schema description coverage at 0%, the description does not compensate for this gap.

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

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

The description uses the specific verb 'Retweet' and identifies the resource 'a tweet' with the input 'by id'. This clearly distinguishes it from sibling tools like quote_tweet, unlike_tweet, and unretweet. No ambiguity exists about the tool's function.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, scenarios, or exclusions. Given the sibling tools, the agent must infer usage solely from the name and minimal 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?

With no annotations, the description carries the burden of behavioral disclosure. It adds useful context about product tabs and return fields, but does not mention rate limits, authentication, or confirm that this is a read-only operation. For a search tool, this is acceptable but not exhaustive.

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 concise sentences, front-loaded with the core purpose, then product details and return fields. Every sentence adds value with 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 search tool with no output schema, the description adequately covers purpose, product variants, and return format. Minor gaps include no mention of pagination or count behavior, but these are implicit in the schema. Overall, it is reasonably complete for straightforward search use.

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

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

The description compensates for low schema coverage (33%) by explaining 'product' (which picks the tab) and the return fields, but does not clarify 'count' semantics or add detail beyond the schema for 'query'. It adds partial value but not full parameter guidance.

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 defines a clear verb+resource ('Search X for tweets') and explicitly differentiates from sibling tools like get_tweet (single tweet) or get_user_tweets (user timeline) by emphasizing query-based search. The 'product' parameter further specifies search tabs, making the scope distinct.

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: use this when you need to search tweets by query. However, it does not explicitly contrast with alternatives or state when not to use it (e.g., 'use get_user_tweets for a single user's posts'). The description lacks direct guidance on tool selection among siblings.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses the numeric id requirement and auto-resolution behavior, but does not mention what happens on failure, rate limits, or whether the message is sent immediately. This is adequate but not fully 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?

Two sentences, front-loaded with the action. Every sentence adds useful information: what the tool does, the recipient format, and an important prerequisite. No unnecessary detail.

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

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

For a simple tool with two required parameters, the description is nearly complete. It explains how to specify the recipient and what to send. Without an output schema, it does not detail the response, but this is a minor gap for a straightforward send action.

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

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

The input schema already documents both parameters at 100% coverage. The description adds semantic value by explaining that recipient_id must be a numeric id and instructing the agent to resolve @handles with get_user first. This goes 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 clearly states the tool sends a direct message to a user, with a specific verb and resource. It distinguishes from siblings like post_tweet and get_dm_inbox by focusing on DMs and includes a key detail about resolving handles.

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 clear context: requires a numeric id and explicitly instructs to use get_user to resolve a @handle. Also notes that the user's own id is auto-resolved. Does not explicitly exclude alternatives, but the guidance is sufficient for the primary 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?

No annotations are provided, so the description must carry the full safety burden. The word 'Remove' indicates a mutation, but the description does not disclose side effects, idempotency, permissions, or behavior when the tweet is not bookmarked. This leaves a significant gap for a write operation.

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

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

The description is a single concise sentence, immediately front-loading the action and resource. No unnecessary 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?

The tool is simple with one parameter, but the description lacks details about return values, error conditions, or prerequisites (e.g., the tweet must be currently bookmarked). With no output schema and no annotations, it is minimally complete but leaves gaps.

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

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

The schema only defines tweet_id as a required string with no description (0% coverage). The description adds 'by id', which confirms tweet_id is the tweet identifier, but does not specify format or constraints. It adds minimal value beyond the parameter name.

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

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

The description uses the specific verb 'Remove' with the resource 'a tweet from bookmarks' and the method 'by id'. This clearly distinguishes it from sibling tools like bookmark (which adds) and delete_tweet (which deletes the tweet itself).

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

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

No explicit alternatives or exclusions are mentioned. The usage is implied: use when you want to unbookmark a tweet, and it requires the tweet_id. However, there is no guidance on when not to use it or comparison to similar tools, so it's at a minimum viable level.

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

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

With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only states the action ('unfollow') but does not mention idempotency, authentication requirements, error behavior, or side effects like whether the user is notified.

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 directly states the action and input. Every word earns its place, with no fluff or repetition.

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

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

Given the tool's simplicity (one parameter, no output schema), the description is minimally acceptable for an agent to invoke it. However, it lacks any mention of return values, error conditions, or expected behavior for edge cases like unfollowing a non-existent user, leaving some gaps.

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

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

Schema coverage is 100% (the schema fully describes user_id as a numeric rest_id). The description adds only the qualifier 'numeric', which is already present in the schema, so it provides no additional semantic value beyond the baseline.

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

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

The description uses a specific verb ('Unfollow') and resource ('a user'), clearly distinguishing it from sibling tools like follow_user. It also specifies the input format ('numeric id'), making the purpose unambiguous.

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

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 follow_user. It simply states the action without context on prerequisites, typical use cases, or exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Remove a like from a tweet by id,' which implies a mutating operation but does not mention potential errors (e.g., if the tweet is not liked), authentication requirements, side effects, or whether the operation is reversible. The minimal wording leaves significant behavioral aspects undisclosed.

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

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

The description is a single, concise sentence that gets straight to the point. It contains no filler or redundant information, and the key verb and object are front-loaded, making it easy for an agent to quickly parse 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 one-parameter mutation tool with no output schema, the description is functional but not fully complete. It lacks details on return behavior (e.g., success/failure responses), error handling, and prerequisites (e.g., authentication). However, given the simplicity, the description provides enough for an agent to invoke the tool correctly in most straightforward cases, though clear gaps remain.

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 has one parameter (tweet_id, string, required) with 0% coverage from the description. The description's phrase 'by id' adds marginal meaning by linking the parameter to a tweet identifier, but it does not compensate for the lack of schema descriptions. The parameter name 'tweet_id' is self-explanatory, so the description offers little beyond what the schema already conveys.

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 ('Remove a like'), the target resource ('a tweet'), and the mechanism ('by id'). It distinguishes itself from sibling tools like 'like_tweet' by explicitly indicating removal, and from other tweet-related actions by focusing solely on unlike behavior.

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 'like_tweet' (which adds a like) or other mutation tools. While the inverse relationship to 'like_tweet' is inferable, the description itself gives no explicit context, exclusions, or alternatives.

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

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

No annotations are provided, and the description only states the action without disclosing side effects, idempotency, authorization requirements, or behavior when the retweet doesn't exist. As a mutation tool, this leaves a significant transparency gap.

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

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

A single, concise sentence fully describes the action with no redundant words. It is perfectly front-loaded and minified.

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 tool, the description covers the core action and parameter. However, it omits behavioral details like error handling, idempotency, and authorization, and there is no output schema. It barely meets the minimum viable standard.

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 only provides 'tweet_id' as a string with no description. The description's 'by tweet id' clarifies which identifier to pass, adding meaning beyond the schema. However, it doesn't specify whether it expects the original tweet ID or the retweet ID, which could cause ambiguity.

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

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

The description uses the specific verb 'Undo' and identifies the resource 'retweet', clearly distinguishing it from sibling tools like retweet and delete_tweet. This makes the tool's purpose unambiguous.

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

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

The description implies the usage (when a retweet needs to be removed) but does not explicitly contrast with alternatives like delete_tweet or provide eligibility criteria. This is adequate given the clear name but lacks explicit guidance.

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