twitter-x-aio

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

No annotations are provided, so the description must carry the full burden. It discloses useful behavioral details such as 'full list' (indicating comprehensive output) and 'Billing per call: 1 Credits' (cost per invocation). However, it does not explicitly state read-only nature, potential response size, rate limits, or authentication requirements. This leaves some behavioral ambiguity.

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

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

The description is highly concise with three short sentences, each providing distinct useful information: the main purpose, the grouping, and the billing cost. There is no fluff or repetition, and the main action is front-loaded.

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

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

For a zero-parameter tool with no output schema, the description is fairly complete: it states what is returned (hashtag, image, and more) and the cost per call. The phrase 'and more' is a bit vague, but given the simplicity of the tool, the description covers essential expectations 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?

This tool has zero parameters, so the schema baseline is 4. The description adds no parameter-specific details since there are none to explain. It correctly avoids inventing parameters, and the schema is fully covered with an empty object, so the baseline score is appropriate.

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

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

The description clearly states the tool's function: 'Receive a full list of all twitter custom emojis with the hashtag, image and more.' This is a specific verb (Receive/Get) targeting a distinct resource (Twitter custom emojis), and the title reinforces the scope. It distinguishes from sibling misc tools like get_misc_locations and get_misc_subtitles.

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: if you need Twitter custom emojis, this is the tool. It also mentions the group 'Utilities/Misc' but does not explicitly state when to use this over alternatives or provide any exclusions. No sibling comparisons are given, so the guidance remains implicit rather than explicit.

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

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

No annotations exist, so the description bears the transparency burden. It implies a read-only list operation and discloses billing cost (1 credit), but it does not describe response shape, pagination, or other behavioral details. For a simple zero-parameter list call, this is acceptable but not rich.

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

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

Two concise sentences: the first delivers the main purpose, and the second packs group and billing metadata. No filler; the structure is appropriate for such a simple tool.

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

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

Given that there is no output schema or annotations, the description would benefit from stating what each returned location contains or how it relates to get_trends_locationId. For a zero-parameter, read-only listing, it is minimally complete but leaves output interpretation to the agent.

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

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

There are zero parameters, so parameter semantics are trivially satisfied and the baseline is 4. The description rightly adds no parameter-level detail.

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 ('gives you a list') and the resource ('all available locations'), distinguishing it from the misc emoji/subtitle utilities. It does not explicitly tie the list to trend location IDs, but the title provides that hint.

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

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

There is no explicit when-to-use guidance, nor any mention of using this list to populate or choose IDs for get_trends_locationId. The 'Group: Utilities/Misc' metadata and billing line convey context but not selection rules.

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 states the tool returns full subtitles and mentions billing per call, but it does not disclose any side effects, authentication requirements, rate limits, or what happens if the video has no subtitles. The billing note is a minor behavioral disclosure, but it 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 very short and front-loaded with the core purpose. The 'Group: ✨ Exclusive endpoints' and billing info are extra but not verbose. It is concise, though the billing info could be considered noise for an agent.

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 no parameters and no output schema, the description is the only source of context. It does not explain how to specify which video, what the output format is, or any limitations. For a tool that presumably requires some input (like a video ID), the lack of context is a significant gap.

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

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

The tool has zero parameters, and the schema coverage is 100% (empty schema). The description does not need to explain parameters because there are none. The baseline for zero parameters is 4, and the description does not add any misleading parameter info.

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 the tool gets the full subtitles of a video, which is a clear verb+resource. However, it does not distinguish this from sibling tools like get_misc_emojis or get_misc_locations, though the resource (video subtitles) is distinct enough. The 'Group: ✨ Exclusive endpoints' and billing info add context but not purpose differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites (e.g., needing a video ID) or exclusions. The billing note implies it is a paid endpoint, but that is not a usage guideline.

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 fails to disclose any behavioral traits such as sink limits, expected input formats, error behavior, or whether resolution is per-URL or as a batch. It only repeats the tool name as the purpose.

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?

While the text is short, this is under-specification rather than effective conciseness. The repetition of 'resolve urls' and billing info occupies space without adding actionable information, failing to earn its place.

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

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

Given the single parameter is completely undocumented (0% coverage), the complete lack of explanation is severely inadequate for a tool with a non-obvious purpose like 'resolve URLs'. It needs to define input format, output, and error handling, especially since there is no output schema to enlighten the agent.

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

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

With 0% schema description coverage and zero required parameters, the description must explain what the 'urls' parameter expects (e.g., a list, comma-separated, JSON array, single URL). It adds no semantics beyond the parameter name. The parameter is marked as a string, but no format is specified.

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

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

The description is essentially a tautology ('resolve urls') with no additional context. It does not specify what 'resolve' means in this context (e.g., URL expansion, redirect resolution, formatting), nor does it distinguish this tool from the 21 sibling tools beyond the name itself.

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

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

The description provides no guidance on when to use this tool versus alternatives. The 'Group: Utilities/Misc' hint gives a category but no practical instruction on use cases, prerequisites, or comparisons with other 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?

Without annotations, the description carries the full burden. It discloses a behavioral trait (GET cursor limit) and cost per call (1 Credit), which is useful. However, it does not explicitly state that the operation is read-only or provide details about authentication, but 'search' implies a safe 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 three sentences, front-loaded with the purpose, and includes a warning and billing info. Every sentence adds value with no fluff, and it is visually structured with an emoji for attention.

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

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

Given no output schema and no annotations, the description is adequate but incomplete. It covers the main functionality and the GET/POST distinction but does not describe the response format, potential errors, or details about filters/category beyond what the schema already states.

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 83%, so parameters are well-documented. The description only adds that a search term is needed, which mirrors the required field. No additional meaning is provided beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool searches all of Twitter with a search term. It distinguishes the GET search from the POST search by mentioning the GET request's cursor limit, which differentiates it from the post_search_searchTerm sibling.

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

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

The description gives explicit guidance on when to use POST instead of GET: when there is a large cursor, the GET request will limit, and POST has no limits. This directly addresses the main alternative and provides a clear usage condition.

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 disclosure burden. It adds billing cost ('Billing per call: 1 Credits') but omits output format, pagination, result limits, or the meaning of locationId values. The read-only behavior is only implied by the verb 'Get'.

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

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

The description is a single focused sentence plus a concise billing note. There is no filler, redundancy, 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?

The tool has a simple schema, but the lack of an output schema and annotations raises the description's burden. The description fails to mention return format, whether trends are returned as a list, or how locationId should be resolved. It is enough for a basic call, but not for robust agent decision-making.

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 for the undocumented locationId parameter. The phrase 'worldwide or a specific region' gives a hint about the parameter's purpose, but it does not specify valid values, the worldwide value, or how to discover region IDs. This is insufficient for a completely undocumented parameter.

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

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

The description states the exact action ('Get twitter trends') and the scope ('worldwide or a specific region'), pairing a specific verb with a clear resource. It is also distinct among the sibling tools, as it is the only trends-specific tool.

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, nor are prerequisites mentioned. The description does not reference get_misc_locations for looking up location IDs, nor does it explain how to specify worldwide versus a specific region.

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

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

No annotations are provided, so the description carries the burden. It discloses the GET request length limitation and billing cost, but lacks details on authentication, response format, or error handling. However, it conveys read-only nature and a specific constraint.

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 a clear purpose in the first sentence and a helpful warning about POST usage. No unnecessary words.

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

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

The description covers the main function and mentions cursor limitations, but does not describe the response structure or pagination details. Given no output schema, the agent may be uncertain about return format. For a simple tool, it's adequate but not complete.

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

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

The description only references 'by tweetId' without explaining the parameter format or constraints. Schema has no description and 0% coverage, so the description fails to compensate for the lack of parameter documentation.

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

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

The description clearly states the tool retrieves all tweet information and comments by tweetId, distinguishing it from sibling tools like favorites/retweets. It also mentions the POST alternative for large cursors, further clarifying 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?

It explicitly advises using the POST request for large cursors due to GET length limits, and mentions billing per call, providing clear guidance on when to use this tool versus the POST variant.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only mentions billing credits and grouping, not what happens with the returned data, rate limits, or pagination behavior beyond the cursor parameter. It doesn't contradict annotations (none exist), but it falls short of disclosing key behaviors.

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 but front-loaded with the primary action. However, it includes extraneous billing/group metadata that is likely available elsewhere, and it omits essential parameter context. It is concise but not optimally structured for agent usefulness.

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

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

With no annotations or output schema, the description should provide more context about expected results, pagination details, and any quirks. It only states the basic action and billing. For a 3-parameter tool, this is insufficient for an agent to fully understand behavior.

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

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

Schema description coverage is 67%, covering 'count' and 'cursor' but not 'tweetId'. The description adds no extra meaning beyond the schema, and the missing tweetId parameter requires inference from the tool name. This is acceptable given moderate coverage, but could improve by explaining tweetId's role.

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

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

The description clearly states the tool retrieves all likes for a tweet, which is a specific verb+resource. It is distinguishable from sibling tools like get_tweet_tweetId_retweets and get_user_userId_likes, though it doesn't explicitly contrast them.

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

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

The description implies usage contexts (tweet-related likes) but provides no explicit guidance on when to use this tool versus alternatives. It lacks exclusions or alternative recommendations, but the purpose is clear enough that an agent can infer basic usage.

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

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

There are no annotations, so the description must disclose behavioral traits. It does not mention pagination, authentication, rate limits, side effects, or the nature of the response (e.g., whether it returns partial results via cursor). The claim of 'all retweets' contradicts the presence of a cursor parameter, suggesting pagination, but this is not clarified. Billing info is present but not behavioral transparency.

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

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

The description is very brief, containing two short sentences. It is front-loaded with the core purpose and then adds metadata (Group and billing). There is no fluff, but it is under-specified. For conciseness it earns a high score, though the brevity sacrifices essential information, which is penalized elsewhere.

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

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

Given the absence of annotations, no output schema, and 0% schema description coverage, the description provides almost no context. It does not explain what the response contains, how pagination works, or the meaning of the parameters. For a tool with 3 parameters and a cursor, this is severely inadequate.

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 explain the parameters. It fails to mention count or cursor at all. The only parameter name that is self-explanatory is tweetId, but count and cursor have no meaning provided, leaving the agent to guess their roles.

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 'Receive all retweets for a tweet' which clearly identifies the verb (receive) and resource (retweets for a specific tweet). It distinguishes from siblings like get_tweet_tweetId (which likely returns the tweet itself) and get_tweet_tweetId_favorites (likes). However, the phrase 'all retweets' is ambiguous about whether it returns the retweeted tweets or a list of retweeters, but the core purpose is evident.

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. The description does not mention prerequisites, typical use cases, or when not to use it. It simply states the operation without any contextualization relative to 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. It states billing cost and group, and 'Receive' implies a read operation, but it does not disclose auth requirements, error behavior, response format, rate limits, or whether any user-specific constraints apply. This is insufficient transparency for a tool with zero annotations.

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

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

The description is short and front-loaded with the key output types, followed by group and billing details. The phrase 'with this endpoint' is minor filler, but the overall structure is efficient and 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?

For a simple one-parameter read endpoint without an output schema or annotations, the description should at least clarify the returned data shape and usage context. It mentions follower counts and images but falls back on 'more user related data' and omits meaningful behavioral or alternative tool guidance, leaving the agent under-informed.

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

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

Schema description coverage is 0%, and the description does not explain the format, encoding, or expectations for the required 'username' parameter. The title and endpoint name hint that the parameter is a username, but no actual parameter semantics are provided.

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

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

The description clearly identifies the tool as returning user-related data such as follower counts and images, and the title 'User Details by username' anchors the resource and lookup key. However, 'more user related data' is vague and does not explicitly distinguish this from sibling user endpoints beyond the username-based lookup.

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

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

The description gives no guidance on when to use this tool versus sibling alternatives like get_user_userId, get_username_to_id_username, or get_user_userId_followers. No context, prerequisites, or exclusions are provided, leaving the agent to infer usage from the tool name alone.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It fails to mention error handling (e.g., username not found), rate limits, return format, or any side effects. The only extra info is billing per call, which is operational, not behavioral.

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 easy to scan, containing a rationale plus group/billing metadata. It is not overly verbose, but the opening sentence is a use-case statement rather than a definitive action, which slightly reduces its structural effectiveness.

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 1-parameter tool without an output schema, the description still feels incomplete. It does not clarify what the tool returns (presumably a userId) or how to handle failures. Sibling tools exist, so guidance on distinction is needed but absent.

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

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

The schema has one parameter 'username' with zero description coverage. The description adds no semantic detail about the expected format, case sensitivity, or constraints. The parameter name is self-explanatory, but the description does not enhance it beyond that.

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

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

The title clearly states 'Convert username to userId', but the description itself only says 'You'll need the userId to receive tweets, media and replies' – a rationale rather than a direct statement of the tool's function. It doesn't explicitly name the conversion action or distinguish this from sibling tools like get_user_by_username_username or get_user_usernames_to_ids.

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 offers no guidance on when to use this tool versus alternatives. It mentions one context (needing userId for tweets/media/replies), but does not explain when to prefer this over get_user_by_username_username or the batch conversion tool get_user_usernames_to_ids.

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 for behavioral disclosure. It does state that follower counts, images, and related user data are returned, and mentions billing cost, but it omits authentication expectations, error behavior, rate limits, or response boundaries.

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?

It is short at three sentences and the group/billing details are compact. The first sentence 'This is the preferred method of getting any information' adds little factual value and is not front-loaded with an action verb, making the structure only moderately efficient.

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

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

Given the absence of an output schema and annotations, the description should define return shape and usage context much more fully. It only lists two example data types and doesn't explain how this endpoint relates to the large set of user-related siblings, so an agent may invoke it incorrectly or misjudge what it gets back.

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 has 0% schema coverage for the single userId parameter and adds no explanation about how to obtain or format userId. The schema only lists type 'string', so the agent gets no additional semantic meaning from the description.

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

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

The description clearly says the endpoint returns follower counts, images, and other user-related data, so the core purpose is understandable. However, the phrase 'preferred method of getting any information' is overly broad and does not distinguish this general user-details endpoint from the many sibling user-specific endpoints.

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

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

The description gives no concrete when-to-use guidance or alternative comparison. It only claims to be the 'preferred method', which is not a reliable heuristic given that sibling tools like get_user_userId_tweets, get_user_by_username_username, and get_user_userId_followers exist.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses pagination behavior ('use the cursor and count to navigate around') and includes billing/group metadata, but does not mention response shape, authentication needs, or any side effects. It is not misleading, but it is minimal.

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 very concise: a clear one-sentence purpose, a one-sentence navigation note, and two brief metadata labels. Every sentence earns its place and the most important information is front-loaded.

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

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

For a simple 4-parameter read tool, the description covers purpose, pagination, and metadata. However, with no output schema, it does not explain the shape of follower objects or what exactly is returned beyond 'followers.' The schema provides some cursor-structure details, but overall the description 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?

Schema description coverage is high (75%), with cursor and count already documented well. The main description adds only a high-level note that cursor/count are for navigation, which does not materially exceed the schema. Username's override behavior and userId's role are already in the input 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 function: 'Receive all followers of a user.' This is a specific verb and resource, and the tool name/title reinforce the scope. It does not explicitly compare with sibling tools like get_user_userId_followings, but the purpose is unambiguous.

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

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

The description gives clear context: use it to get all followers of a user, with cursor and count for pagination. It does not mention exclusions or alternatives, but the stated purpose is sufficient to infer when the tool should be used.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It does explain cursor/count navigation and mentions the TimelineTimelineCursor objects, which is useful. However, it omits auth requirements, potential side effects, and any specifics about the response structure. This is adequate but not rich.

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

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

The description is concise, with the core purpose stated first ('Receive all followings of a user') and navigation hints following. There is no fluff, but it could arguably be more informative without losing conciseness. It earns a high score for efficiency.

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

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

Given the lack of annotations, output schema, and the existence of sibling tools that differ (basic vs ids), this description is incomplete. It does not explain what distinguishes this variant, what the response looks like, or any access requirements. The pagination hint is helpful but insufficient for full contextual understanding.

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

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

Schema coverage is 75% (count, cursor, username are documented), and the description adds a sentence about using cursor and count for navigation, which reinforces their combined use. The username override is only in the schema, not mentioned in the description. Overall, the description adds minimal value beyond the schema, so a baseline 3 is appropriate.

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

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

The description states 'Receive all followings of a user', which is a clear verb+resource. It does not explicitly differentiate from sibling tools like get_user_userId_followings_basic or get_user_userId_followings_ids, though the name itself implies a full followings list. This is clear but not fully distinguishing.

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

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

No guidance is provided on when to use this tool versus alternatives like followings_basic or followings_ids. The only usage hint is about pagination with cursor and count, but there is no mention of selection criteria or exclusions. This leaves the agent without context for tool choice.

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

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

There are no annotations, so the description carries the full burden of disclosure. It mentions billing per call (1 credit) and lists the output fields, but does not disclose whether the operation is read-only, requires authentication, or has side effects. Critically, it says 'provide only the userId' while the schema allows a username alternative that overrides the userId, making the description misleading about accepted inputs. This lack of clarity around input handling and side effects lowers transparency.

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

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

The description is compact (two sentences) and front-loaded with the core purpose. Including billing and group info is minor but not excessive. It avoids redundancy, though the second sentence repeats 'followings'; this is acceptable. Overall, it's efficient for a simple tool.

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

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

The tool has no output schema, so the description appropriately lists the returned fields (id, username, createdDate, followings, followers). However, it omits essential context such as pagination behavior, any rate limits (apart from billing), authentication requirements, and clarifies the username override. The presence of sibling tools with different scopes further necessitates a clearer explanation of what 'basic' means. Given the simple nature of the endpoint, the description is adequate but leaves notable gaps, especially around input alternatives and potential limitations.

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 schema description coverage at 50%, the description needed to compensate for the undocumented userId parameter, but it only repeats 'provide only the userId' without adding meaning (e.g., format, example, or that it's a numeric string). Meanwhile, it contradicts the schema's optional username parameter. The list of output fields adds some context but not input semantics. The tool description fails to clarify the relationship between userId and username, leaving the agent confused.

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 purpose: returning a basic list of a user's followings, and lists the fields returned. It distinguishes itself from sibling tools by using 'basic' (vs. the likely more detailed get_user_userId_followings and IDs-only get_user_userId_followings_ids), though it doesn't explicitly name those alternatives. The verb and resource are specific and clear.

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

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

The description provides no guidance on when to use this tool versus the sibling followings endpoints. It only instructs to provide the userId, which is a usage instruction, not a selection criterion. No mention of when to prefer 'basic' over 'full' or 'ids' is given, leaving the agent to guess based on the title and 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 for behavioral disclosure. It mentions billing cost and result type, but it does not mention pagination via count/cursor, response format, authentication, rate limits, or error behavior. This is under-specified for a list endpoint with multiple parameters.

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 very short and front-loaded: the first sentence gives the core function and the second adds billing context. There is no redundant prose, though the 'Group: User' text is not particularly useful to an agent.

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 four parameters, no annotations, no output schema, and multiple sibling tools, the description is incomplete. It does not cover pagination, how to specify the user, what the response looks like, or how this differs from followings_basic. It is minimally viable but clearly lacks necessary 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?

Schema description coverage is 0% and the description adds no parameter meaning. It does not explain count, cursor, userId, username, or the relationship between userId and username, leaving four parameters essentially undocumented beyond their bare names.

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 returns the IDs of users that a given user follows, which is specific and directly distinguishes it from sibling tools like get_user_userId_followings or get_user_userId_followers. However, it does not explicitly specify whether the target user is identified by userId or username, though the tool name suggests userId.

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

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

The description gives no guidance on when to use this tool versus alternatives such as get_user_userId_followings or get_user_userId_followings_basic. It only provides a basic operation description and billing info, with no when-to-use or when-not-to-use 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?

The description does not disclose any side effects, error conditions, or response format. It mentions a billing cost but omits critical behavioral details. The reference to non-existent cursor/count parameters further undermines transparency about the actual 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 contains extraneous metadata ('Group: User. Billing per call: 1 Credits.') that is likely available elsewhere and does not aid understanding. The cursor/count mention is irrelevant given the schema, making the description overlong and unfocused.

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 fails to specify the output structure (e.g., list of like objects) or any pagination mechanism, and it contradicts the schema by referencing non-existent cursor/count. Without these details, the tool cannot be used reliably in conjunction with other tools.

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 only parameter, userId, is not described beyond its name. The schema provides no type info beyond string, and the description adds no context about its format, requirements, or meaning. The mention of cursor and count, which are not in the schema, adds confusion rather than clarity.

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

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

The title 'User Likes by userId' and description 'Receive all likes of a user' clearly indicate the tool fetches likes for a specific user. It is distinct from sibling tools like get_tweet or get_user_followers, though it could be more explicit about the nature of 'likes' (e.g., tweets liked).

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 mentions using 'cursor and count to navigate around,' but these parameters are not present in the input schema (only userId is defined). This is misleading and provides no guidance on when to use this tool versus alternatives or how to handle pagination effectively.

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

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

With no annotations, the description carries the transparency burden. It does disclose useful behavior: ordering by recency, pagination/cursor navigation, user group, and billing cost. However, it does not clearly state read-only semantics, return shape, or what happens on invalid usernames/missing media, and the cursor/count reference is not reflected in 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 core description is short and front-loaded: the main purpose is stated first, navigation is captured in one sentence, and the group/billing metadata is compact. No words are wasted.

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

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

The tool is simple, with only one official parameter, so the description does not need to be long. Still, because there is no output schema and no details on cursor/count, returned media structure, or edge cases, the description leaves meaningful gaps for an agent invoking the tool.

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

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

Schema description coverage is 0%, and the description does not add detail about the only schema parameter, userId. It even introduces 'cursor' and 'count' as navigable concepts although they are absent from the input schema with additionalProperties false, which creates ambiguity for correct invocation.

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 the resource plainly ('all media items') and the ordering rule ('most recent'); the tool name and title make the user scoping explicit. It is clearly distinct from sibling tools such as get_user_userId_tweets or get_user_userId_followings because it is the media-specific option.

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

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

The description implies when to use the tool: when media items are needed. It also explains cursor/count navigation, but it does not explicitly say when to choose this over siblings such as get_user_userId_tweets or get_user_userId_likes, nor does it give when-not-to-use guidance.

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

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

The description discloses pagination behavior (using cursor and count) and billing cost (1 credit per call), which are important. However, it omits other behavioral aspects like authentication requirements, potential rate limits, or that it returns only public tweets. Without annotations, the description carries the full burden but only partially covers these traits.

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

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

The description is exceptionally concise, using only two sentences to convey the primary function and key usage hints. It avoids redundancy and fluff, 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?

While the description covers the basic function and pagination, it does not explicitly state that it returns tweets for a specific user (relying on the title and parameter names). It also omits any preconditions or error scenarios. Given the presence of a schema with parameter descriptions, the text is sufficient for basic usage but lacks completeness for edge cases.

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

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

The description only mentions cursor and count for navigation, which is already described in the schema. It does not add any extra meaning for the userId or username parameters, nor does it clarify the relationship between them beyond what the schema states. The description adds negligible value over the parameter descriptions.

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

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

The description clearly states the tool retrieves all tweets ordered by most recent, which indicates a read operation. It distinguishes from sibling tools that handle followers, media, etc., but it does not explicitly mention that it's for a specific user, though the title and parameter imply it.

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

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

The description provides no guidance on when to use this tool versus alternatives. It only mentions pagination via cursor and count, but does not explain scenarios such as fetching a user's timeline or when to prefer this over search or other get_user tools. No comparison with alternatives is given.

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

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

No annotations are provided, so the description carries the full burden. It indicates a read-like operation ('Receive') and provides navigation details, but it does not disclose other behavioral aspects such as response format, error handling, or authentication requirements. The mention of billing per call and group adds some context, but overall transparency is average for a simple fetch 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 extremely concise, with two sentences covering the main function and navigation. It is front-loaded with the primary purpose and includes only essential extra details (Group, Billing). No wasted words or repetition, earning full marks for conciseness.

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 fetch tool, the description gives the core functionality and navigation hints, but it does not explain the response structure (e.g., cursor objects in the entries array) or how to initiate pagination. The schema's cursor description fills some gaps, but the tool description itself lacks sufficient detail for an agent to fully understand the output and pagination workflow.

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

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

The input schema covers 75% of parameters with descriptions (count, cursor, username), and the description summarizes cursor and count usage but does not add new meaning beyond what the schema provides. Since schema coverage is high, the baseline is 3, and the description offers no substantial additional semantic value.

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 tweets and replies ordered by most recent, and specifies the resource (tweets and replies) and action (receive). While it doesn't explicitly contrast with sibling tools like get_user_userId_tweets, the inclusion of 'replies' makes the purpose distinct enough. The description is concise and unambiguous.

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

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

The description implies usage for retrieving tweets and replies for a user, and mentions navigation via cursor and count, but it does not provide explicit guidance on when to choose this tool over alternatives or when not to use it. It lacks exclusions or direct references to sibling tools, so the guidance is only implicit.

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 the batch limit and billing cost, but omits critical behavioral details such as the input format, return mapping (order vs. object), handling of invalid usernames, and any rate limits. 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 core description is a single sentence that is efficient and to the point. It is front-loaded with the primary action and the limit. However, the title contains marketing fluff ('✨ EXCLUSIVE!') and the group/billing info could be separated, but the overall structure is acceptable.

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 minimal schema, no output schema, and no annotations, the description is insufficient for an agent to reliably use the tool. It lacks input specification, output structure, and error semantics, making it incomplete for a batch conversion operation.

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

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

Although there are 0 declared parameters in the schema, the description mentions an implicit input (list of usernames) without specifying how the agent should supply it (e.g., parameter name, format, encoding). The description adds conceptual meaning but fails to compensate for the empty schema, leaving invocation ambiguous.

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 converts a list of usernames to IDs, with a specific limit of up to 100 at a time. This distinguishes it from singular sibling tools like get_username_to_id_username, making the purpose unambiguous.

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

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

The description implies usage for batch conversions of multiple usernames but does not explicitly contrast with the singular alternative or specify when not to use it. The context is clear but lacks exclusionary guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions the HTTP method and capacity for larger requests, but does not state whether it is read-only, any side effects, authentication requirements, or rate limits. This is insufficient for a network 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 concise at three sentences and front-loaded with the core purpose. The added group and billing info are tangential but brief. No unnecessary repetition occurs.

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

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

Given there is no output schema, the description should at least mention what the search returns and how pagination or cursors work. It only vaguely references 'larger requests' and 'large cursors' without explaining response format or usage. For a search tool with one parameter, this is incomplete.

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

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

With 0% schema description coverage, the description must compensate for the single parameter 'searchTerm'. It merely says 'provide a search term', adding no semantic value beyond the schema's type string. It does not explain formatting, encoding, operators, or length limits, leaving the agent underinformed.

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 searches all of Twitter with a search term, and differentiates it from the GET sibling by noting it's a POST request for larger requests. The title 'Search for large cursors' is a bit ambiguous, but the description clarifies the purpose. It does not confuse with other search tools.

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

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

The description implies use when you need 'larger requests' compared to GET, providing some usage context. However, it does not explicitly mention when not to use the GET alternative or any conditions for choosing POST. It also mentions billing and group, which are not usage guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses that this is a POST request, mentions billing cost (1 credit), and implies a read-like operation ('Receive'). However, it doesn't state auth requirements, rate limits, or potential side effects, leaving some behavioral transparency gaps.

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

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

The description is concise, with the key action and usage scenario in the first sentence, followed by useful metadata (group, billing). No fluff or repetition, though 'tweet informations' is awkwardly phrased. It earns its two 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?

The tool is simple (one parameter, no output schema), and the description covers purpose, usage context, and billing. But it lacks parameter explanation and a clearer description of return format (just 'all tweet informations and comments'). This is adequate 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?

The schema has only one required parameter, tweetId, with no description (0% coverage). The description mentions 'by tweetId' but doesn't explain the expected format (e.g., numeric string) or any constraints. Since schema coverage is low, the description should compensate, but it doesn't provide meaningful parameter semantic detail.

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 the tool 'Receive all tweet informations and comments by tweetId', which clearly identifies the verb and resource. The title 'Tweet Details for large cursors' and the clause about digging deeper into replies when the cursor is growing help distinguish it from sibling tools like get_tweet_tweetId, though 'tweet informations' is somewhat vague.

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

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

It explicitly indicates when to use this tool: when the cursor is growing, implying pagination or large reply sets. It doesn't name alternatives but gives clear context for when the POST variant is preferable over GET endpoints. There are no exclusions or alternative names, but the condition is specific enough.

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