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

With no annotations, the description carries the full burden of behavioral transparency. It only states the action and the exclusivity constraint, but does not disclose side effects, required permissions, idempotency, or error behavior (e.g., if the user is already a member). This is a significant gap for a mutating tool.

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

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

The description is concise and front-loaded, with the action in the first sentence, followed by a critical usage constraint, and then a clear, structured 'Args' list. Every sentence adds value with no 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 3-parameter tool, the description covers the purpose, the necessary constraint, and each parameter's meaning. Since an output schema exists, return value documentation is not required. Minor missing context includes when to use alternative list-member tools, but overall the description is adequately complete for 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 has no descriptions (0% coverage), so the description's parameter explanations are vital. It clearly specifies that 'list_id' is required, 'screen_name' is a Twitter username without '@', and 'user_id' is numeric. It also conveys the critical rule that exactly one of screen_name/user_id must be provided, which is not obvious from 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 'Add a user to a Twitter List' with a specific verb and resource. It distinguishes itself from sibling tools like remove_list_member and get_list_members by indicating a write/add 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 description provides an important usage constraint: 'Caller must provide exactly one of screen_name / user_id.' However, it does not explicitly mention when to use this tool versus alternatives (e.g., remove_list_member for removal or get_list_members for viewing). The usage is implied rather than stated.

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

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

Discloses that X aggressively rate-limits and risk-scans block and mute actions, warning of account restriction for bulk usage. This is useful beyond the input schema, though more details on the effects of blocking could be included.

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?

Concise and well-structured: a clear purpose sentence, a warning note, and parameter description. 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?

Given the tool's simplicity and presence of an output schema, the description covers essential aspects. However, it could mention that blocking is reversible via unblock_user, which is a relevant contextual 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?

Adds crucial format instruction for the screen_name parameter: 'Twitter username (without @)', which is missing from the schema (0% coverage). This fully compensates for the schema 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 clearly states 'Block a user by screen name', specifying the verb 'block', resource 'user', and method. This distinguishes it from sibling tools like mute_user and unblock_user.

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

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

Provides a note about rate-limiting and avoiding bulk usage, which serves as when-not-to-use guidance. However, it does not explicitly compare to alternatives like mute_user.

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, placing the full burden on the description. It only states the basic action and does not disclose idempotency, error cases, authentication needs, or consequences of bookmarking (e.g., if the tweet is later deleted).

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 extremely concise, front-loaded with the action, and includes an arg list that is easy to scan. Every sentence earns its place with no fluff.

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 an output schema, the description covers the core operation but omits edge-case behavior such as invalid tweet IDs or folder requirements. It is minimally viable but has clear gaps.

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

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

Schema description coverage is 0%, and the description's Args section only repeats parameter names with minimal clarifications. It adds little beyond the schema titles and does not explain value formats or behavioral implications (e.g., whether folder_id must exist).

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

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

The description clearly states the action ('Bookmark a tweet') and the optional folder feature. It uniquely identifies this tool among siblings like like_tweet and delete_bookmark.

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 when-to-use or alternative guidance is provided. The purpose implies the use case, but the description does not contrast with similar actions like liking or deleting bookmarks.

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

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

No annotations are provided, so the description must fully cover behavioral traits. It explains parameter constraints (name required, defaults) but does not disclose authentication needs, rate limits, or what happens on failure or success. The output schema is not referenced.

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 concise docstring with a clear purpose statement and a structured Args section. Every sentence adds value without redundancy.

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

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

The description adequately covers parameters and purpose. Given an output schema exists, it does not need to detail return values, but mentioning that the created list is returned would improve completeness.

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

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

The description adds significant meaning beyond the input schema: it specifies that name must not be empty, and gives default values for description and is_private. This compensates for the 0% 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 starts with 'Create a new Twitter List,' which clearly states the action and resource. This distinguishes it from sibling tools like edit_list, get_lists, and remove_list_member.

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?

While it clearly says when to use the tool (to create a list), it does not explicitly mention when not to use it or provide alternatives. However, the sibling context implies creation is distinct from editing or deleting lists.

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 that the tool creates a poll (mutation) and returns a card_uri. It specifies constraints (2-4 choices, duration >0) and the integration with send_tweet. No annotations are provided, so the description carries full responsibility; it is sufficiently 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?

The description is concise with three clear sections: summary, constraints and usage, and parameter details. Every sentence adds value, and the most important information appears first.

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 covers the creation behavior, constraints, and integration with send_tweet. It mentions the return value (card_uri). While an output schema exists but isn't shown, the description handles it adequately. Missing details like error handling are minor for this simple tool.

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

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

The input schema has 0% description coverage, but the description fully compensates by specifying that 'choices' must be a non-empty array of 2-4 strings and 'duration_minutes' must be >0. This adds complete semantic 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 clearly states the action ('Create an X poll') and the return value ('return its card URI'), making the tool's purpose unambiguous. It also explains the relationship with send_tweet, differentiating it from other tweet-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 description provides a clear workflow: create the poll, then pass the card_uri to send_tweet. However, it does not explicitly state when not to use this tool or mention alternatives, though no direct alternative exists for poll creation.

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 rate-limit behavior ('follow X's standard rate limits') and notes 'no special caveats needed,' which is useful. However, with no annotations, it carries the full burden and does not address potential side effects, permission requirements, or error behavior beyond the input constraints.

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

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

The description is tightly written: a clear purpose sentence, a useful rate-limit note, and a well-organized Args list. Every sentence earns its place, 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 3-parameter tool with an output schema, the description covers the essential purpose, all parameter semantics, and a key behavioral trait. Minor gaps like error conditions and lifecycle management (retrieval/deletion) are not explicitly mentioned, but the output schema and sibling tools help fill those gaps, so it is nearly 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 0%, so the description fully compensates by explaining all three parameters. It defines scheduled_at as Unix epoch seconds and requires future values, clarifies the dependency that at least one of text or media_ids must be provided, and describes media_ids as a list of attachment IDs.

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 verb ('Schedule') and resource ('a tweet') with a clear temporal scope ('future Unix timestamp'). This distinguishes it from immediate-posting siblings like send_tweet, and 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 first sentence provides clear context for when to use this tool: to schedule a tweet for a future time. It doesn't explicitly name alternatives or exclusions, but the 'future' constraint inherently signals that this is not for immediate posting, giving clear context without needing to mention send_tweet.

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 clearly states the destructive action ('remove'), but does not disclose side effects, idempotency, permissions, or error behavior. It is not misleading, and given the simplicity of the tool, the core behavior is adequately conveyed, but significant behavioral context is missing.

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 extremely concise: a single sentence plus a parameter explanation. Every word earns its place, and the purpose is front-loaded. There is no fluff or repetition, making it easy for an agent to parse quickly.

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

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

The tool is simple (one required parameter) and an output schema exists, so the description does not need to explain return values. The description sufficiently covers the core purpose and parameter semantics for an agent to select and invoke the tool correctly in most cases. It lacks usage guidance and behavioral edge cases, but those are addressed in other dimensions, and for the tool's simplicity, this is nearly 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 description adds minimal value beyond the input schema. The schema already names the parameter 'tweet_id' and describes it as 'Tweet Id.' The description says 'The tweet ID to un-bookmark,' which essentially restates the parameter's name and the tool's purpose. It does not clarify the allowed integer/string ambiguity, format expectations, or how to obtain the ID, leaving the agent with the same information as the schema alone.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Remove a tweet from bookmarks.' This distinguishes it from sibling tools like bookmark_tweet (add) and get_bookmarks (list), and there is no ambiguity about its scope.

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

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

The usage is implied by the purpose and the unambiguous name, but there is no explicit guidance about when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. It simply says 'Remove a tweet from bookmarks,' which inherently communicates when to use it, but does not proactively clarify edge cases or compare with related tools.

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

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

With no annotations, the description carries the full burden. It discloses that the tool targets private messages and highlights the anti-spam and suspension risk, which adds important behavioral context beyond a generic 'delete' 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 brief and front-loaded: a single action sentence, a critical safety note, and a minimal args list. Every sentence earns its place without redundancy.

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

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

For a simple delete tool with one parameter and an output schema present, the description adequately covers the action, the primary risk, and the parameter. It could optionally reference get_dm_history for locating message IDs, but that is not essential for the tool's core function.

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

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

The schema description coverage is 0%, and the description's Args section only says 'message_id: The message ID to delete.' This is essentially a restatement of the schema's 'Message Id' label and fails to explain how to obtain the ID or any format/type nuances, relying on the schema's type information.

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 'Delete a direct message by ID' with a specific verb (delete), a clear resource (direct message), and the method (by ID). This distinguishes it from sibling tools like delete_tweet and delete_retweet.

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 a practical warning: 'Deletes a PRIVATE message. Do not bulk-call. X has aggressive anti-spam on DMs and may suspend the account.' This tells the agent when to exercise caution and the risk of misuse, though it does not explicitly mention 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, so the description must carry the burden of behavioral transparency. It only states the action without disclosing side effects, error conditions, permissions, or rate limits. For a mutation tool, this is insufficient.

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 extremely concise: a single sentence plus an Args block. It front-loads the core purpose and keeps every word useful, with no filler or irrelevant 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 one-parameter tool, the description covers the basic operation and parameter semantics. However, it lacks context about potential failure modes (e.g., what happens if the tweet hasn't been retweeted), authentication requirements, or return value. Since no output schema or annotations are provided, the description leaves some gaps, but the tool is simple enough that this is barely 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?

The input schema provides no parameter descriptions (0% coverage), and the description adds a one-line explanation: 'tweet_id: The tweet ID to un-retweet.' This clarifies the purpose of the parameter beyond its title 'Tweet Id', but it does not provide additional details like format constraints or context. This is a modest improvement over 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 action: 'Un-retweet a tweet by ID.' This uses a specific verb and resource, and the sibling tool 'retweet' confirms this is the inverse operation, distinguishing it from related tools like 'delete_tweet'.

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 does not explicitly state when to use this tool or when to avoid it. The purpose is obvious from the name and description, but there is no guidance on alternatives or conditions (e.g., only for tweets the user has retweeted). Usage is implied but not explicitly framed.

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 behavioral burden. It adds a useful note about rate limits and the ID source, but doesn't describe the consequences of deletion (e.g., irreversibility) or any permissions required. For a simple delete operation, this is acceptable but not deeply 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?

The description is concise and well-structured: a clear one-sentence purpose, a brief rate-limit note, and a neatly formatted Args section. No redundant information, every sentence earns its place.

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

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

Given it's a single-parameter delete tool with an output schema, the description covers the essential usage: what it does, the ID sourcing, and rate limits. It lacks explicit ownership/precondition statements, but those are likely implicit in the broader API context. Overall, it's sufficiently complete 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?

Schema description coverage is 0%, so the description fully compensates by explaining the parameter's source (from create_scheduled_tweet or get_scheduled_tweets) and explicitly warning against confusing it with a regular tweet ID. This adds significant meaning beyond the raw 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 'Delete a scheduled tweet by its scheduled tweet ID' with a specific verb and resource. It distinguishes from sibling tools like delete_tweet by emphasizing the scheduled tweet ID and explicitly noting 'This is NOT a regular tweet 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 clarifies that the ID comes from create_scheduled_tweet or get_scheduled_tweets, giving context for when to use the tool. It doesn't explicitly name delete_tweet as an alternative for regular tweets, but the 'NOT a regular tweet ID' warning implies this exclusion, providing adequate 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 disclose behavioral traits. It only states the delete action without mentioning permanence, permissions, rate limits, or side effects. For a destructive operation, this is a significant gap.

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

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

The description is short, front-loaded, and free of fluff. The main purpose is in the first sentence, and the parameter is listed cleanly. It could be considered under-specified, but for what it contains, it is efficiently structured.

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 delete tool, the description is minimally adequate. However, it omits behavioral details (e.g., irreversible deletion, required ownership) that would make it fully contextually complete. With an output schema present, return value omission is acceptable, but usage conditions are not fully addressed.

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%, but the 'Args' section merely restates 'tweet_id: The tweet ID to delete', which adds little beyond the schema property name. It does not clarify the integer/string ambiguity or provide format expectations, so the description fails to compensate for the coverage gap.

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

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

The description states 'Delete a tweet by ID' which uses a specific verb ('Delete') and resource ('tweet by ID'). It clearly distinguishes from sibling tools like delete_retweet or delete_bookmark by specifying the target is a tweet.

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 used when you need to delete a tweet, but provides no explicit guidance on when to use it versus alternatives (e.g., delete_retweet) or any prerequisites/exclusions. The context is straightforward but not fully elaborated.

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?

Since no annotations are provided, the description carries the full transparency burden. It discloses dependency requirements (yt-dlp, ffmpeg), default output directory, format selection behavior (with ffmpeg requirement for 'bestvideo+bestaudio'), and failure modes (raises ToolError if yt-dlp/ffmpeg missing, no video, or download fails). This is comprehensive behavioral disclosure 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 structured into a one-sentence summary, a parameter list, and a returns/errors section. It is moderately sized but every sentence provides useful information—no filler. The clear formatting (Args/Returns) makes it easy to scan and understand.

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 moderate complexity (external dependencies, multiple parameters, formatting options, error conditions). The description covers the purpose, all parameters with defaults, return JSON fields, and error scenarios. It also notes when ffmpeg is required. This is complete for the tool's complexity, and the output schema further supplements the return type 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?

The input schema provides only titles and types with zero descriptions. The description compensates fully by explaining each parameter: tweet_id accepts numeric ID or URL, output_dir has a default from environment variable or fallback path, and format defaults to 'best[ext=mp4]' with explanation of when to use 'bestvideo+bestaudio'. This adds substantial meaning beyond the bare schema, which is especially critical given 0% schema description 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 opens with 'Download video(s) attached to a tweet via yt-dlp', which clearly identifies the action (download), the resource (videos attached to a tweet), and the method (yt-dlp). This is a specific verb+resource statement that distinguishes this tool from all sibling tools, none of which handle video downloads.

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 states the exact use case—downloading videos from a tweet—which is clear context for when to use the tool. It does not explicitly mention alternatives or when not to use it, but given the tool's unique functionality among siblings, the implied usage is sufficient. No exclusions or contradictory guidance are present.

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

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

No annotations are provided, so the description carries the full burden. It clearly indicates this is a mutation ('Edit') and additionally discloses the empty-string-clears-description behavior. However, it omits potential side effects, permission requirements, or error scenarios, leaving some 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 succinct and well-structured: one sentence for purpose, one for constraints, one for special behavior, then a clean parameter list. No redundant filler; every sentence contributes actionable information.

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

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

For a simple edit tool with an output schema, the description covers the essential inputs and constraints. The lack of mention of return values is mitigated by the existence of an output schema. It could add permission context or error handling, but overall it's largely complete for 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 0%, so the description must compensate. It explains each parameter: list_id is required, name is the new name, description can be cleared with an empty string, and is_private sets privacy. The empty-string behavior and the at-least-one-field constraint add meaning beyond the raw 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 'Edit a Twitter List's metadata' and lists the editable fields (name, description, is_private). This distinguishes it from sibling tools like create_list (create), get_list (retrieve), and add_list_member (add member), 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?

Provides explicit usage prerequisites: 'At least one of name, description, or is_private must be provided' and explains how to clear the description. While it doesn't explicitly compare to alternatives, the context of editing an existing list is clear from the purpose and the parameter details.

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 X aggressively rate-limits follow/unfollow and that bulk usage may lead to temporary restrictions. This is valuable behavioral context beyond the tool's basic 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 extremely concise: two sentences for the purpose and warning, followed by an Args line. Every word serves a purpose, and the critical information is front-loaded.

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

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

For a single-parameter action tool with no annotations, the description covers purpose, usage guidelines, and parameter format. It does not describe the return value, but the tool is simple and the context 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?

The schema has 0% description coverage, so the description compensates. It clarifies that screen_name expects a Twitter username without the '@' symbol, adding meaning beyond the schema's type and title.

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 'Follow a user by screen name' clearly states the action (follow) and the target (user) and the method (by screen name). It distinguishes itself from siblings like 'unfollow_user' and 'mute_user', making the tool's purpose unambiguous.

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

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

The description explicitly warns about aggressive rate limiting and advises against bulk usage, which provides important usage context. However, it does not specify when not to use or list alternatives, though for this simple action, the guidance is adequate.

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 the two-hop reader flow, output sizes and fields for each format (e.g., 'preview' ~1 KB, 'full' ~150 KB+), and the response body location. It lacks explicit statements about failure modes or side effects, but as a read operation, the coverage is strong.

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 well-structured with a clear first sentence, a detailed but relevant flow explanation, and a bulleted args list. The two-hop flow might seem technical, but it's directly useful for understanding behavior and debugging. No redundant sentences.

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 moderate complexity (2 params, 3 output formats) and the presence of an output schema, the description is highly complete. It covers the full request/response landscape: what is fetched, how it works, parameter options, output sizes, and required auth. There are no obvious gaps 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?

Schema coverage is 0%, so the description must fully explain both parameters. It does so excellently: article_id is defined as 'Article rest_id (numeric string) or full /i/article/<id> URL,' and format lists each option with size, included fields, and a recommendation for when to use it. This fully compensates for the schema 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 opens with a specific verb and resource: 'Fetch an X Article (long-form post) by rest_id or URL.' This clearly states what the tool does and distinguishes it from tweet-focused siblings. The mention of 'long-form post' differentiates it from standard tweets, and the parameter detail ('by rest_id or URL') adds scope.

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

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

The description provides clear context for when to use the tool ('Fetch an X Article'), plus format selection guidance ('Use only when you need it') for the 'full' format. It also notes authentication requirements ('Requires authentication via cookies'). However, it does not explicitly compare with the sibling tool get_article_preview, leaving some ambiguity about when to choose one over the other.

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 discloses that no authentication is required and that it relies on a public endpoint. It does not discuss rate limits or error behavior, but the key behavioral trait of auth-free access is clearly 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 three sentences plus an Args line, front-loaded with the purpose, and every sentence adds 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 single-parameter read-only tool with an output schema, the description provides enough context on what to pass and what to expect. The lack of auth and the specific endpoint type give sufficient operational 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 schema only says 'Tweet Id' with anyOf integer/string, but the description explains tweet_id can be a numeric string or full URL and must be for a tweet linking to an article, adding crucial information.

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

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

The description starts with a specific verb 'Get' and resource 'title/preview/cover of an X Article', and clarifies the scope is 'embedded in a tweet', distinguishing it from the sibling tool get_article.

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 states 'Uses X's public syndication endpoint — no authentication required,' providing clear context for when this tool is appropriate. However, it does not explicitly mention when not to use it or alternative tools like get_article.

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 provided, so description must carry behavioral disclosure. It states paginated retrieval, implying read-only, but does not mention authentication, rate limits, error cases, or what happens with no bookmarks. Lacks safety and error 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?

Extremely concise: one-line purpose then two arg descriptions. No extraneous text. Front-loaded with main action. Every sentence provides 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 simple paginated get tool with output schema present, basics are covered. However, lacks authentication context and differentiation among many 'get_' siblings. Could be more complete for an agent new to the domain.

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%, so description compensates by explaining count (default 20, max 100) and cursor (pagination from next_cursor). Adds meaning beyond schema titles and defaults, though could include format/type details.

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 bookmarked tweets' with the verb 'get' and resource 'bookmarked tweets'. It mentions pagination, distinguishing it from creation/deletion siblings like bookmark_tweet and delete_bookmark. However, it does not explicitly differentiate from other get tools like get_timeline or get_tweet, though the resource specificity helps.

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?

Minimal guidance: only describes pagination and default/max for count. Does not mention when to use this tool vs alternatives, authentication requirements, or prerequisites. No exclusions or why one might choose this over similar get 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?

Discloses pagination behavior and that it only returns tweets from joined communities. Lacks details on rate limits, error handling, or empty results. No annotations provided to supplement.

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-line description with clear purpose followed by parameter details. No wasted words.

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

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

Output schema exists to describe return values. Description covers tool purpose and parameter semantics adequately. Missing authentication details but implied by 'authenticated user'.

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?

Adds meaning beyond schema: default count 20, max 100, cursor is from previous next_cursor. Schema only has defaults and type. 0% schema coverage compensated well.

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?

Clearly states it gets tweets from all communities the authenticated user has joined, with pagination. Differentiates from siblings like get_community_tweets (specific community) and get_timeline (general).

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?

Indicates pagination and authentication context but does not specify when not to use or provide alternatives. Implicit usage through sibling 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?

No annotations are provided, so the description carries the full burden. It only says 'Get a Twitter Community by ID' and offers no insight into authentication, return behavior, error handling, or whether the community must be public. The read-only nature is implied but not elaborated.

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 extremely concise: two short lines that state the purpose and parameter meaning. No fluff or redundancy. This is an appropriate size for a simple get-by-ID 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 is a simple getter with one parameter and has an output schema, so the description does not need to explain return values. The description sufficiently identifies the tool's function for selection and invocation. However, it lacks any context about edge cases or community visibility, which could matter, but given the simplicity, it is mostly 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 0%, so the description must compensate. It says 'community_id: The community ID,' which adds minimal meaning beyond the parameter name itself. It does not clarify expected format, difference between string/integer, or any constraints. The description is essentially redundant with 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?

Description clearly states the tool retrieves a Twitter Community by ID, using the specific verb 'Get' and resource 'Twitter Community by ID.' This distinguishes it from sibling tools like search_community and get_community_members, which have different purposes.

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: you use this when you have a community ID and need community details. However, there is no explicit guidance on when to prefer this over search_community or get_community_tweets, nor any mention of alternatives or exclusions. The context is minimal.

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 responsibility of disclosing behavior. It mentions pagination, default/max count, and the cursor source, which are valuable behavioral details. It does not cover error handling or auth requirements, but the core behavior is disclosed.

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

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

The description is a single line plus a tidy parameter list. No redundant or fluff content, and all information is front-loaded in the first sentence.

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

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

Given the output schema exists, the description doesn't need to explain return types. It covers the pagination mechanism, all parameters, and is complete for a list-fetch operation. The string 'paginated' and cursor guidance ensure the tool can be used correctly.

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

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

Schema description coverage is 0%, so the description is the sole source of parameter meaning. It explains community_id, count (with default and max), and cursor (as pagination cursor from a previous next_cursor), adding substantial value beyond the raw 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's action: 'Get members of a Twitter Community (paginated).' This is a specific verb+resource that distinguishes it from sibling tools like get_community (community info) and get_community_moderators (moderators).

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 use (fetching community members) but does not explicitly mention exclusions or alternatives. The pagination details imply a straightforward read operation, but no 'when not to use' is 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 must carry the behavioral transparency burden. It discloses that results are paginated and explains the cursor/count mechanics, which is useful. However, it does not mention authorization requirements, error behavior, or rate limits, which could be important for a production API call. The transparency is moderately sufficient for a simple read 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 succinct, starting with the core purpose in one line, then an args list with no filler. Every sentence/line adds value, adhering to front-loaded and concise formatting.

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 and the description explains the purpose, all parameters, and pagination. It doesn't cover error conditions or response format, but an output schema exists to handle return values. Overall it offers a complete picture for basic usage, though not exhaustive.

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%, but the description compensates by listing each parameter and providing semantics: community_id is the target community, count has a default of 20 and max of 100, and cursor references the previous response's next_cursor. This adds significant meaning beyond the raw schema, especially for count and cursor.

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

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

The description clearly states the operation: 'Get moderators of a Twitter Community (paginated).' This distinguishes it from sibling tools like get_community_members or get_community_tweets, making its specific purpose immediately obvious. The pagination note adds useful scope.

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

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

The description provides clear context for when to use this tool—to retrieve community moderators—and explains pagination usage with cursor and count, but it does not explicitly mention alternatives or exclude other tools. There is no comparison to sibling tools such as get_community_members, so guidance on selection is only implied by the 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?

With no annotations, the description carries the burden. It discloses pagination behavior via cursor and next_cursor, and count limits. However, it does not explicitly state that it is read-only, nor does it mention authentication or rate limits. This is functional 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 one-line summary plus a concise args list is efficient. Every sentence adds value, and the formatting is clean.

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 largely complete for a simple read tool: clear purpose, good parameter documentation, and pagination details. The output schema exists so return values are covered. The missing piece is usage differentiation from similar community tools, which keeps it from being a 5.

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?

Despite 0% schema description coverage, the description documents all four parameters with meanings, valid values for tweet_type, and default/max for count. This fully compensates for the schema's bare titles.

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

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

The description opens with a clear verb-object statement, 'Get tweets from a Twitter Community', and specifies pagination. This distinguishes it from sibling tools like 'get_community' or 'get_community_members' which focus on different resources.

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

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

The description gives parameter-level guidance (e.g., count limits, cursor usage) but does not explicitly state when to choose this over overlapping tools like 'search_community_tweet' or 'get_communities_timeline'. Usage is implied from the name but not contrasted with 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?

With no annotations, the description carries full behavioral disclosure. It details the return JSON structure (messages, next_cursor, timeline_events, warnings), pagination behavior (pass next_cursor to max_id), and edge-case caveats such as incomplete history for encrypted/X Chat conversations. This is unusually transparent about response format and limitations.

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 well-structured with a purpose sentence, a critical usage warning, a return-format explanation, and an Args list. Every section earns its place; the anti-spam warning and legacy-DM caveat are important risk/scope details. It is somewhat longer than minimal but appropriate for the tool's complexity.

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 2-parameter tool with no annotation context, the description covers purpose, usage warnings, return values, pagination, and limitations. Even though an output schema is signaled, the explicit return description is especially valuable. It leaves little ambiguity for an AI agent deciding to call this tool.

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

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

The input schema provides zero parameter descriptions (0% coverage). The description compensates fully by explaining screen_name as 'Twitter username (without @)' and max_id as 'retrieves messages older than this ID' with explicit pagination instructions. This is exactly the semantic information an agent needs to invoke the tool correctly.

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 DM conversation history with a user' – a specific verb (Get) and resource (DM conversation history). The note about retrieving PRIVATE messages further clarifies the service's scope, distinguishing it from sibling tools like send_dm or xchat_get_history by focusing on a user's direct message history.

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 context that DMs are private and warns against bulk-calling due to X's aggressive anti-spam and suspension risk. It explains pagination usage via max_id and next_cursor, but does not explicitly name alternative tools like xchat_get_history for X Chat conversations, so it lacks a direct when-not-to-use comparison.

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

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

With no annotations, the description carries the full burden. It discloses that the operation is paginated and explains the cursor mechanism, which is essential behavioral context. It clearly implies a read-only operation by using 'get', so no destructive behavior needs warning.

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 concise and front-loaded with the core purpose in the first sentence. The args section is well-structured and each line provides necessary information without redundancy.

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

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

For a simple read-only paginated endpoint with an output schema, the description covers the essential aspects: purpose, parameters, and pagination behavior. It could include error handling or rate-limit notes, but these are less critical given the tool's simplicity and the presence of 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?

Schema description coverage is 0%, but the description compensates well. It explains count's default and maximum, and describes cursor as a pagination token from a previous response's next_cursor. This adds real semantic value beyond the schema's bare definitions.

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

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

The description uses a specific verb and resource: 'Get users who liked a tweet' clearly defines the action and target. It also mentions pagination, which adds scope. This distinguishes it from sibling tools like get_retweeters or get_user_followers by the object of the action.

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 clear: use when you need the list of users who liked a specific tweet. There is no explicit alternative or exclusion, but the purpose is unambiguous and the tool's scope is evident from the 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 provided, the description carries the full burden of behavioral disclosure. It only says 'Get' which implies a read operation, but it does not disclose return format, authentication needs, rate limits, or any potential side effects. The description adds no behavioral context 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 short and front-loaded, with no wasted words. It has a clear structure with the main action and an Args list. While it is minimal, it is appropriately concise for a simple one-parameter getter.

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

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

Although an output schema exists and this is a simple tool, the description lacks usage guidelines and meaningful parameter semantics. It does not convey important context such as when to choose this tool over get_lists or what kind of ID is expected. The description is minimally viable but leaves clear gaps.

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

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

The schema has 0% description coverage, so the description must compensate for explaining the list_id parameter. However, the description only repeats 'The list ID' which is identical to the schema's title 'List Id'. It adds no new meaning about format, type, or usage examples, failing to meet the burden.

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 action: 'Get a Twitter List by ID.' This is a specific verb+resource combination and distinguishes it from sibling tools like get_lists (which lists all lists) or get_list_tweets (which gets tweets in a 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 description provides no guidance on when to use this tool versus alternatives. It does not mention that get_lists should be used to retrieve all lists, or that this tool is for a specific list by ID. No exclusions or alternative tools are cited.

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

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

No annotations are provided, so the description carries the burden of disclosing behavior. It explains pagination, count limits (default 20, max 100), and cursor usage from a previous response. It does not mention auth, rate limits, or error conditions, but covers the core pagination behavior well.

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

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

The description is compact and well-structured, with a one-sentence purpose followed by a clear Args list. Every line provides useful information without unnecessary fluff.

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 paginated read operation, the description covers the essential parameters and pagination behavior. An output schema exists, so return values do not need explanation. However, it could add a brief note about when to use this tool vs list_subscribers, but that is minor for completeness.

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

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

The description adds significant meaning beyond the input schema: it specifies max count=100, default count=20, and explains that the cursor is a pagination cursor from a previous response's next_cursor. The schema only lists types and defaults, so these details are valuable.

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

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

The description starts with 'Get members of a Twitter List,' which uses a specific verb and resource, and clearly distinguishes this tool from sibling tools like get_list_subscribers and get_list_tweets. The inclusion of 'paginated' also hints at the tool's scope and 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 implies usage when you need a list's members, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or related list tools. There is no explicit guidance on when not to use it.

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

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

No annotations; description discloses pagination but lacks details on rate limits, auth requirements, or empty list behavior.

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

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

Two concise lines: one for purpose, one listing args with defaults. No wasted words.

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

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

Adequate for a simple list retrieval tool with output schema present. Could mention error cases but not critical.

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?

Adds meaning beyond schema: count default/max, cursor usage explanation. Schema coverage 0% so description provides necessary context.

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?

Clear verb 'Get' + resource 'Twitter Lists' + scope 'authenticated user's' and pagination. Distinct from sibling tools like get_list, get_list_members, etc.

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?

Implies use for fetching user's lists, but no explicit when-to-use vs alternatives like get_list or get_list_tweets.

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 takes responsibility for behavioral disclosure. It reveals that the operation is paginated, defines the count parameter (default 20, max 100), and explains that the cursor comes from a previous response's next_cursor. This adds practical context beyond what the schema alone offers, though it doesn't discuss auth or error behavior.

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

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

The description is highly concise and well-structured. The first sentence gives the purpose, followed by a compact Args block listing each parameter with its semantics. Every sentence earns its place, and there is no fluff.

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 paginated list getter, the description covers the essential aspects: purpose, pagination, and parameter details. An output schema exists, so return values need no explanation. It lacks potential usage advice or auth caveats, but given the tool's simplicity and shared context with siblings, it is reasonably 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 property descriptions (0% coverage), but the description compensates by explaining each argument: list_id as 'The list ID', count with a default and max, and cursor with its origin. This adds meaningful semantics, especially for count and cursor, though list_id remains somewhat tautological.

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 subscribers of a Twitter List (paginated)' with a specific verb and resource. It distinguishes itself from sibling tools like get_list_members by using the term 'subscribers' rather than 'members', making its 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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of scenarios where this should be preferred over get_list_members or other list-related tools, leaving the decision entirely to the agent's inference.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It does mention pagination via cursor, adding useful behavioral context, but it does not explicitly state side-effect safety, authentication requirements, or rate limits. For a read-only getter, this is acceptable 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?

The description is compact and well-structured, front-loading the main purpose in a single sentence followed by a clear Args list. Every line adds value with no redundant 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?

The tool is simple and the description covers all parameters and the key pagination behavior. The presence of an output schema means return values need not be described. However, it lacks explicit guidance on when to use this instead of other tweet-fetching tools, so it is 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 0% description coverage, so the description provides all parameter meaning. It explains list_id as the list ID, count with default (20) and max (100), and cursor as a pagination token from a previous response's `next_cursor`. This goes well beyond the bare schema definitions.

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

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

The description clearly states the verb 'Get' and the resource 'tweets from a Twitter List', which precisely defines the tool's purpose. This distinguishes it from sibling tools like get_list or get_list_members, which operate on list metadata or members, not tweets.

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 through its straightforward verb-noun structure, but it does not explicitly provide alternative tools or when-not-to-use scenarios. Sibling tools like get_timeline or get_user_tweets are not mentioned, leaving the agent to infer when list tweets are preferable.

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 disclosing behavior. It explains pagination via cursor but does not mention rate limits, authentication needs, or whether the operation is safe/read-only. For a read tool, this is acceptable 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?

The description is short and front-loaded with the core purpose. Every sentence is informative, and the parameter details are presented in a clear, structured list without 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?

An output schema exists, so the description does not need to explain return values. It covers pagination and parameter inputs well. However, it could briefly mention the structure or sort order of notification items to improve completeness.

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

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

Schema description coverage is 0%, so the description fully compensates. It explains each parameter with default values, constraints, and how cursor relates to previous responses. This adds significant value beyond the schema's type and default information.

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 that the tool fetches notifications with pagination support. While it does not explicitly differentiate from sibling tools, the tool name and description are sufficient for an agent to understand its purpose, and no other sibling tool deals with notifications directly.

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

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

The description provides detailed parameter instructions, including allowed values for notification_type, default and max count, and cursor usage. It does not explicitly state when to use this tool versus alternatives, but the context from sibling names suggests it's the only notification-fetching tool, making the guidance adequate.

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 burden. It discloses pagination behavior ('paginated') and explains the cursor parameter as coming from `next_cursor`, which is useful operational context. However, it does not mention rate limits, auth requirements, or behavior for invalid tweet IDs, though these are not critical for a simple read 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 extremely concise: a one-line purpose statement followed by a terse bullet list of parameters. No filler or repetition. The structure is front-loaded and every sentence adds 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 simple list tool with an output schema, the description covers the essential behavior and parameters. It explains pagination fully. Minor gaps (e.g., response order, error handling) are not necessary given the simplicity and the presence of 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?

Schema description coverage is 0%, so the description must compensate. It does so thoroughly: tweet_id is described as 'The tweet ID', count gets its default and max ('default 40, max 100'), and cursor is explained as 'Pagination cursor from a previous response's `next_cursor`'. This adds full meaning beyond types/defaults.

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 verb+resource: 'Get users who retweeted a tweet'. This clearly differentiates from sibling tools like get_favoriters (users who favorited) and get_tweet (tweet content). The parenthetical '(paginated)' adds operational scope.

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

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

The description immediately establishes when to use it: when you need the list of users who retweeted a specific tweet, given by tweet_id. It does not name alternatives or explicitly state when not to use it, but the context is unmistakable due to the distinct resource and the required parameter.

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 discloses pagination behavior, rate limits, and the implicit read-only nature, but could mention error handling or authentication details.

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

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

Three short, informative sentences with no redundancy; purpose is front-loaded and each sentence adds 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 parameterless, read-only tool with an output schema, the description covers purpose, pagination, and rate limits 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?

No parameters exist, so the baseline is 4. The description adds no parameter-specific info, which is acceptable given full schema coverage.

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

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

The description clearly states the tool returns all scheduled tweets for the authenticated user, which is specific and distinct from sibling tools like create_scheduled_tweet or get_tweet.

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 explains that the full list is returned in one call and why that's acceptable due to X's cap, but does not explicitly state when to use versus 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?

With no annotations, the description must disclose behavioral traits. It only mentions the count parameter, omitting authentication, rate limits, or that it's a read operation. Minimal 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?

Two concise sentences: first states purpose, second documents the parameter. No fluff, but could be more structured with clear sections.

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, output schema exists), the description is adequate but lacks usage guidelines and behavioral constraints. Could be more complete for an AI agent.

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

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

The description explains the single parameter 'count' as 'Number of tweets to fetch (default 20)', adding meaning beyond the schema's type and default. Schema coverage is 0%, so this is valuable.

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

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

The description 'Fetch home timeline tweets' uses a specific verb ('Fetch') and resource ('home timeline tweets'), clearly distinguishing it from siblings like 'get_user_tweets' or 'search_tweets'.

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

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

No guidance is provided on when to use this tool versus alternatives such as 'get_community_tweets' or 'search_tweets'. The description lacks 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?

No annotations are provided, so the description carries full burden. It only states the function and parameters, omitting behavioral traits such as rate limits, pagination, error handling, or confirmation of read-only nature.

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 concise and front-loaded, with a clear one-line summary followed by parameter details in a structured list. Every sentence is informative with no redundancy.

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

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

Given the tool's simplicity (two optional parameters) and the presence of an output schema, the description is largely complete. However, it could mention that the operation is read-only and does not require authentication beyond the session.

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 descriptions are missing (0% coverage), so the description adds value by specifying allowed category values and default values for both parameters. However, it does not explain the meaning or constraints beyond these.

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

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

The description clearly states the tool fetches trending topics by category, with specific categories listed. This is a distinct resource from sibling tools like get_timeline or search_tweets.

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 for trending topics but provides no explicit guidance on when to use this tool versus alternatives (e.g., search_tweets) or when not to use it. No contextual hints for exclusion.

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

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

No annotations are provided, so the description carries the full burden. It only says 'Fetch a tweet by ID,' which implies a read-only operation but does not explicitly confirm read-only behavior, rate limits, authentication requirements, or how errors are handled. This is a significant gap for a tool with no annotation support.

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

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

The description is extremely concise: one purpose sentence plus a single parameter explanation. No fluff or repetition, and the most important information is front-loaded. Every sentence earns its place.

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

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

For a simple single-parameter fetch operation with an output schema present, the description covers the core semantics well. However, it lacks usage guidance and explicit behavioral assurances, so it's not fully complete on its own. But given the tool's low complexity, it is nearly 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?

Even though the schema allows anyOf integer/string, the description adds essential semantics by specifying that tweet_id can be a numeric string or a full URL. This goes beyond the schema's bare type information and helps the agent correctly construct inputs. The schema coverage is 0%, making this parameter clarification valuable.

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 action and resource: 'Fetch a tweet by ID.' This verb+resource pair is unambiguous and differentiates it from siblings like get_user_info, get_user_tweets, and search_tweets, which have different scopes or purposes.

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 when to prefer get_tweet over search_tweets or get_timeline, nor does it state any exclusions or prerequisites beyond providing a tweet ID. The only usage hint is the parameter description, which is not enough.

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

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

With no annotations provided, the description carries the full transparency burden. It discloses the underlying GraphQL endpoint, pagination behavior, one-page-per-call semantics, and return fields. It goes beyond simple 'fetches replies' to explain how results are structured and how to page through them, giving the agent actionable behavioral expectations.

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 well-structured with a clear summary, implementation detail, Args section, and Returns section. Every sentence contributes to understanding or usage. The 'issue #94' reference is minor noise but not enough to detract from the overall efficiency.

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

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

The tool involves pagination and two parameters, and the description covers pagination flow, parameter semantics, and return format. An output schema exists, so the description doesn't over-explain return values, but it provides enough context for the agent to use the tool correctly without ambiguity.

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%, so the description fully compensates. It explains tweet_id accepts a numeric string or full URL, and cursor is the pagination token from a previous next_cursor, with explicit 'omit for the first page' guidance. This adds meaning far beyond the raw schema types.

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 'Fetch replies (comments) to a tweet' – a specific verb, resource, and scope that clearly distinguishes it from siblings like get_tweet or get_timeline. The explicit reference to paginated replies and the tweet ID input further cements its unique purpose.

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

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

The description clearly states the tool fetches replies and one page per call, with a cursor to fetch more. However, it does not explicitly contrast with alternatives such as get_tweet or search_tweets, nor does it state when not to use this tool. The use case is implied strongly but not compared against sibling tools.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, and it does well: it discloses rate-limit behavior, pagination requirement, and the identifier constraint. It also mentions next_cursor from a previous response, adding context 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 compact, with a clear structure: a warning note, a requirement line, and a parameter list. Every sentence earns its place, and the front-loaded warning is critical.

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 straightforward, and the description covers identification, pagination, and rate-limit constraints. The output schema handles return values, so no further detail is needed.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. The Args section explains all four parameters: screen_name and user_id with formatting (without @), count with default and max, and cursor with source from previous response. This adds significant value over the bare 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 'Get a user's followers list' with a specific verb and resource. It distinguishes from sibling get_user_following by explicitly mentioning followers, and the note about exactly one identifier clarifies scope.

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

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

The description provides explicit usage guidance: warns of aggressive rate limiting, advises pagination via cursor, and specifies the caller must provide exactly one of screen_name/user_id. It does not explicitly name alternative tools, but the sibling context makes the distinction 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?

No annotations are provided, so the description carries the full burden. It discloses that Twitter aggressively rate-limits follower/following requests, advises pagination via cursor, and warns against looping without backoff. This is meaningful behavioral context beyond the schema, though it stops short of covering potential auth requirements or visibility constraints.

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

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

The description is compact and front-loaded: the critical rate-limit warning appears first, followed by the arg requirement and a labeled Args block. Every sentence serves a purpose, and the structure makes the parameter details easy to scan.

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 has four parameters, no schema descriptions, and no annotations, the description covers all necessary ground: purpose, parameter usage, rate-limit caution, and pagination. The output schema exists, so return values are already documented elsewhere; no additional explanation is needed.

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

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

With 0% schema description coverage, the description fully compensates by explaining each parameter: screen_name (without @), user_id (numeric Twitter ID), count (default 20, max 100), and cursor (from previous response's next_cursor). It also clarifies the exactly-one-of constraint, adding meaning that the schema alone does not provide.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Get accounts that a user follows.' It distinguishes itself from the sibling 'get_user_followers' by explicitly naming the following list, so there is no ambiguity about which direction of the social graph it retrieves.

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 usage context: the caller must provide exactly one of screen_name or user_id, and it warns to use the tool sparingly due to rate limits. It does not explicitly mention alternatives like get_user_followers, but the purpose statement makes the distinction obvious, and the constraint+rate-limit guidance is solid.

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 adds the constraint that exactly one identifier must be provided, but it does not disclose what happens when both are provided, nor any error behavior, rate limits, or read-only guarantees. The description is not misleading, but it provides limited behavioral insight beyond the basic lookup semantics.

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

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

The description is concise and front-loaded: the first sentence states the core purpose, followed by a clear usage constraint and two short parameter descriptions. Every sentence earns its place with 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 lookup tool with an output schema present, the description covers the essential input semantics and invocation constraint. It does not mention edge cases or error handling, but given the simplicity of the operation and that the output schema exists, it is sufficiently complete. Slightly more detail on return behavior would warrant a 5, but the current level is adequate.

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%, so the description must compensate. It does so effectively: 'screen_name: Twitter username (without @)' clarifies the format (no @) and 'user_id: Twitter numeric user ID' specifies the numeric nature. It also explains the mutual exclusivity requirement, which is essential for correct invocation. This adds significant meaning beyond the raw 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?