twikit-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.45
Disambiguation4/5
Most tools target distinct resources and actions, and descriptions clarify sources (e.g., get_tweet vs get_user_tweets vs get_timeline). However, with 62 tools, some overlap in purpose (many get_* and search_* tools) creates mild selection ambiguity.
Naming Consistency4/5
Tool names follow a consistent verb_noun snake_case pattern (send_tweet, get_user_followers, delete_tweet). Minor inconsistencies exist, such as 'like_tweet' vs 'unfavorite_tweet' (favorite/like) and the xchat_* prefix subgroup.
Tool Count1/5
62 tools is an extreme count, far exceeding the typical 3-15 well-scoped range. Even for a comprehensive Twitter client, this number burdens agent selection and increases cognitive load.
Completeness4/5
The tool set covers a wide range of Twitter/X functionality: tweets, users, DMs, lists, communities, scheduled tweets, polls, articles, and notifications. Minor gaps exist, such as no delete_list or explicit media upload for send_tweet, but core workflows are well covered.
Average 4/5 across 58 of 62 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 14 commits in the last 12 weeks
- Last stable release on August 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It only states the action 'Retweet a tweet by ID' without disclosing side effects, authentication requirements, potential errors (e.g., already retweeted), or rate limits. No behavioral transparency is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, but it includes an 'Args' block that redundantly restates the schema. While it is front-loaded and free of fluff, the redundant parameter line detracts from overall value. It is minimal but not efficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is severely incomplete. It lacks usage context, behavioral details, and parameter semantics. For a mutation tool with no annotations, this level of sparseness is inadequate for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description says 'tweet_id: The tweet ID,' which simply repeats the schema's property title 'Tweet Id'. It adds no semantic meaning beyond the schema, leaving the parameter's format, source, or constraints unexplained. Schema description coverage is 0%, and the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Retweet a tweet by ID.' This provides a clear verb+resource combination, unambiguously indicating the action of retweeting a specific tweet. It is distinguishable from sibling tools like send_tweet or delete_retweet, though it doesn't explicitly mention that it creates a retweet on behalf of the authenticated user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no indication of when to use this tool versus alternatives such as like_tweet or send_tweet. There is no mention of prerequisites, context, or exclusions. It entirely lacks usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 simply restates the tool's purpose without disclosing what actually happens on join (e.g., immediate membership vs. pending approval, idempotency, error behavior if already a member). This is a significant gap for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (two lines), which is efficient, but it sacrifices needed detail. It is not a model of conciseness because it omits essential context that could be conveyed in a few additional sentences. The structure is clean, but the content is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool has only one parameter and appears simple, the context signals reveal a complex domain with many community-related siblings (get_community, request_to_join_community, leave_community). The description fails to address idempotency, privacy implications, or the difference between public and private community joins. The presence of an output schema is not exploited; no return-value expectations are given.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description merely repeats 'community_id: The community ID to join' — a tautology that adds no semantic insight beyond the parameter name. No format, source, or example is given, so the agent gains no additional understanding of how to obtain or supply this ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Join' with a clear resource 'a Twitter Community', immediately distinguishing it from siblings like leave_community and request_to_join_community. The action is unambiguous and matches the tool name exactly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no mention of when to use this tool versus request_to_join_community, which is a critical distinction in community join flows. The agent receives no contextual cues about prerequisites or alternative actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and the parameter, with no mention of side effects (e.g., whether an already-liked tweet errors or is idempotent), required permissions, rate limits, or reversibility. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with only two sentences separating the main purpose and the parameter description. It is front-loaded and free of fluff. However, the 'Args' section largely duplicates the schema, which is slightly redundant, but overall the structure is clean and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description is minimally viable. The action is self-explanatory and the output schema likely documents return values. However, it lacks usage guidelines and behavioral transparency, making it incomplete for an agent that needs to know when to use it and what side effects to expect. This earns a 'minimum viable' score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description repeats the parameter name and type ('tweet_id: The tweet ID.') without adding meaning beyond the schema. Schema description coverage is 0%, so the description should compensate, but it does not clarify the ID format (integer vs string), any constraints, or how to obtain the ID. The minimal elaboration is largely redundant with the schema's property name and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Like a tweet by ID.' It identifies the verb (like) and resource (tweet), and the listener is given the required input. Although it doesn't explicitly differentiate from siblings like 'unfavorite_tweet', the verb 'like' is unique and unambiguous. The purpose is specific and easily understood.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives. There is no mention of prerequisite steps (e.g., verifying the tweet exists), no exclusions, and no comparison to similar actions like 'unfavorite_tweet' or 'retweet'. The description simply states the action without any contextual or alternative usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It fails to state that the tool is read-only, non-destructive, or any side effects. It only lists parameters, leaving the agent uninformed about the tool's behavior beyond inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a clear docstring format. Every sentence adds value, but it could be slightly more structured (e.g., separating behavior from parameters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 does not need to explain return values. However, it omits important context such as search scope (e.g., recent tweets, full archive) and authentication needs. It is minimally complete but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to all three parameters by explaining query, count, and product, including defaults. Since schema description coverage is 0%, this fills a critical gap and helps the agent understand parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search tweets' as the purpose, which is a specific verb and resource. However, it does not differentiate from sibling tools like search_user or get_timeline, which also involve searching or retrieving tweets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 search_community or get_timeline. The description lacks context about the appropriate use case or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Get recent tweets' but does not disclose behavior such as rate limits, pagination, or handling of protected users. With no annotations provided, the description should provide more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences with no filler. It front-loads the purpose and immediately follows with parameter explanations. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to detail return values. It adequately covers the core functionality for a simple retrieval tool, though it could mention common fields like text or timestamp.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains both parameters beyond the schema: screen_name format ('without @') and count meaning ('Number of tweets to fetch') with its default value. Since schema has 0% description coverage, this adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'recent tweets from a specific user,' which identifies the specific verb and resource. It is distinct from siblings like get_tweet (single tweet) and get_timeline (home timeline), though it could explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., get_tweet for a single tweet, search_tweets for keyword-based search). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses pagination and lack of count parameter, but does not mention whether the operation is read-only, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a clear argument list. Every sentence adds value, and no words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not explain return values. It covers parameters and key behavior (paginated, no count), but lacks usage guidelines and behavioral transparency, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning: 'query' is described as a search query string, and 'cursor' as a pagination cursor from previous next_cursor. This compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for Twitter Communities by query, with pagination. It differentiates from general search tools (search_tweets, search_user) by specifying 'Communities', but could be more explicit about distinction from search_community_tweet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful guidance on pagination and cursor usage, and notes that count parameter is not supported. However, it lacks explicit when-to-use vs alternatives like search_community_tweet.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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 implies a mutating action without covering permissions, irreversibility, or response behavior. For a state-changing tool, this lacks important disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the purpose, followed by the parameter breakdown. No wasted words, appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter action, the description is minimally adequate but lacks behavioral context such as membership requirements, side effects, or reversibility. The output schema reduces the need for return-value documentation, but absent annotations leave gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, and the description explains 'community_id: The community ID to leave,' adding semantic meaning beyond the schema's type/title. Though brief, it fully covers the sole parameter in a low-coverage schema context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Leave a Twitter Community' with a specific verb (leave) and resource (community). It is unambiguous and easily distinguished from sibling actions like join_community.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., being a member) or contrast with join_community, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals the tool performs a write operation and mentions character limit, but lacks details on success behavior, error responses, idempotency, or potential side effects. Since no annotations exist, the description fails to provide sufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences and a brief argument list. Every word is necessary and front-loaded, making it efficient for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 the basic purpose and parameters. However, it lacks usage context among siblings and does not address potential failures, making it incomplete for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaningful value by specifying text max length (280 chars) and explaining reply_to as an optional tweet ID. This goes beyond the schema's simple type definitions, though the format of reply_to could be more precise.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sends a tweet, optionally as a reply, which is a specific verb+resource combination. It distinguishes itself from other tweet-related tools like delete_tweet, retweet, and create_scheduled_tweet by focusing on sending a new tweet immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 create_scheduled_tweet or send_dm. There is no mention of prerequisites, authentication, or rate limits, leaving the agent without context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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 pagination behavior (cursor from previous next_cursor) and count constraints (default 20, max 100), but does not mention rate limits, authentication requirements, or search behavior like case sensitivity or matching logic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single-sentence purpose followed by a bullet list of argument explanations. Every sentence is informative and there is no redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (context indicates 'Has output schema: true'), the description does not need to detail return values. However, it misses the scope of what fields are searched (e.g., username, display name) and does not mention error conditions or behavior when no results are found. This is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema: it explains that cursor comes from a previous response's next_cursor, and specifies the default and maximum for count. The schema only provides types and defaults, so this adds value for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for users by query (paginated)', specifying the verb and resource. It is distinct from sibling tools like get_user_info (which requires a specific user) and search_community (which searches communities). However, it does not specify which user attributes are searched (e.g., username, display name), which could provide more clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to find users by a query string, but does not explicitly contrast with other user-related tools such as get_user_info or follow_user. There is no guidance on when not to use this tool or mention of prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It only states the action 'Unlike' without detailing side effects, error conditions, idempotency, or permissions. Minimal disclosure for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by an argument spec with no unnecessary words. It is appropriately sized for a simple one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 the essentials. However, it lacks behavioral details such as prerequisites or error handling, and with no annotations, some gaps remain for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explicitly explains tweet_id as 'The tweet ID to unlike', adding meaning beyond the schema's simple title. This directly connects the parameter to its role in the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Unlike a tweet by ID', using a specific verb and resource. It distinguishes the tool from siblings like 'like_tweet' and 'delete_tweet', 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys when to use the tool: when you want to unlike a tweet. There is no explicit mention of alternatives or exclusions, but the context is clear enough for an agent to select this tool for unliking operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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 states the action is a removal but does not mention potential side effects, required authentication, error conditions, or reversibility, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured, leading with the purpose and then listing parameters in a clean Args block. Every sentence earns its place, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal tool, the description covers the essential parameters and the key invocation constraint. However, with no annotations, it falls short on behavioral details like return values, error handling, or permission requirements, though the tool's simplicity mitigates this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds valuable meaning beyond the schema: it clarifies that screen_name is without '@' and user_id is numeric, and explicitly states list_id is required. This compensates for the 0% schema description coverage, though parameter descriptions remain minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear, specific verb 'Remove' and resource 'a user from a Twitter List', making the tool's action unambiguous. It also distinguishes from sibling tools by explicitly stating the removal action, contrasting with add_list_member.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit and important usage constraint: 'Caller must provide exactly one of screen_name / user_id.' This prevents common invocation errors, though it does not discuss when to use this tool versus alternatives or 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.
Behavior2/5
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 behavioral traits. It only mentions that an answer may be required for some communities, but it does not disclose side effects, outcome of the request, reversal options, or any permission requirements. This is a significant gap for a mutation-type tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear one-line purpose, a short clarifying note about policies, and an args list. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the output schema exists to describe return values. The description covers the core action and the key conditional parameter. However, it does not explicitly address how this tool relates to the sibling pick_community or what happens after a request is submitted, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description compensates by explaining both parameters. community_id is defined as 'The community ID to request to join,' and answer is described as optional but required for some moderator-approval communities. This adds meaningful context beyond the schema's bare property titles, though it could still clarify the format of community_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb and resource: 'Request to join a Twitter Community.' It also distinguishes from sibling tools by noting the context of restricted join policies requiring moderator approval, which separates it from direct joining tools like join_community.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining that this tool is for communities with restricted join policies. However, it does not explicitly mention alternatives (e.g., using join_community for open communities) or offer exclusionary guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 risk of rate-limiting and temporary restriction, which is helpful. However, it does not mention other aspects like permission requirements, idempotency, or what happens if the user is not blocked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences and a bullet point. The first sentence states the purpose, and the note is clearly separated. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple unblock action, the description covers the core purpose, parameter usage, and an important warning. Although it could mention error handling or prerequisites, the presence of an output schema (unknown content) may compensate. Overall fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value to the input schema by explaining that screen_name should be a 'Twitter username (without @)'. This clarifies the format, which is not present in the schema (0% coverage).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Unblock a user by screen name', which is a specific verb and resource. It distinguishes itself from sibling tools like block_user and mute_user by the action unblock.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a warning about rate-limits and bulk usage, but does not explicitly state when to use this tool versus alternatives like unmute_user or block_user. It implicitly defines usage as unblocking, but lacks comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'Vote on an X poll' without disclosing side effects, reversibility, rate limits, or the possibility of failure (e.g., poll closed, already voted). The metadata source information is helpful but does not address the behavioral implications of casting a vote.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a clear one-line purpose and then provides necessary context and a structured argument list. It is efficient, with no redundant fluff. The repetition between the prose and the arg list is minor and serves to clarify each parameter, so it remains appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations and the output schema is not shown, the description covers all parameters and adds useful domain context (poll structure, metadata source). It could mention potential failure conditions or the action's irreversibility, but it is otherwise complete enough for a relatively simple voting action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 lack of parameter details. It fully compensates by explaining each of the four parameters: selected_choice is the label and must be non-empty, card_uri and card_name come from poll card metadata, and tweet_id identifies the tweet containing the poll. This adds critical meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action with 'Vote on an X poll,' a specific verb and resource. It distinguishes itself from siblings like create_poll by focusing solely on voting on an existing poll. The additional context about poll structure (2-4 choices, duration) reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating that card_uri and card_name come from the tweet's poll card metadata and are obtainable via get_tweet, implying the need to fetch the tweet first. It does not explicitly mention alternatives or exclusion scenarios, but the guidance on prerequisites is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It transparently discloses that X rate-limits and risk-scans mute operations, and that bulk usage may lead to account restrictions. This is valuable 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short paragraphs. It front-loads the core purpose, then adds the critical rate-limit warning, and finally details the parameter format. Every sentence is necessary and well-placed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description covers the purpose, format, and a key behavioral warning. The output schema likely explains return values, so the description does not need to. It is complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the screen_name parameter (0% coverage). The description clarifies that it expects a Twitter username without the @ symbol, adding meaningful semantic information that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Mute a user by screen name,' which clearly identifies the verb (mute) and resource (user). It distinguishes from sibling tools like block_user and unmute_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns about aggressive rate limiting and advises against bulk usage, providing implicit usage guidance. However, it does not explicitly compare with alternatives like block_user or specify when to choose mute over block.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses pagination behavior through the cursor parameter and count limits (default 20, max 100), which are useful operational details. It stops short of mentioning read-only semantics, rate limits, or other potential constraints, but provides meaningful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose. The Args list is a clean, structured reference with one line per parameter. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with an output schema, the description covers the essential details: scope, query, count limits, and pagination. No critical gaps remain, and the output format is presumably available in the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description explains each parameter: community_id, query, count (with default and max), and cursor (from previous response's next_cursor). This fully compensates for the sparse schema and adds clarity to parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Search tweets within a Twitter Community (paginated).' It identifies the specific resource (tweets within a community) and distinguishes from siblings like search_tweets (general search) and get_community_tweets (likely without a query).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 search_tweets or get_community_tweets. The description simply states what it does without context on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must disclose all behavioral aspects. It mentions rate-limiting and potential temporary restriction, which is valuable. But it does not disclose whether the user must be followed beforehand, what happens if the screen name does not exist, or any side effects beyond the warning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences and a one-line Args description. No extraneous information; front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description provides the essential: action, parameter format, and a usage warning. Missing prerequisites (e.g., must be following) but still fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter 'screen_name' is explained with format hint ('without @'), which adds value beyond the schema (which only specifies type string). Schema coverage is 0% but the description compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies the action ('Unfollow a user') and the method ('by screen name'). Clearly distinguishes from sibling 'follow_user'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides rate-limit warning and advises against bulk usage, giving clear context for appropriate use. However, does not explicitly state when not to use this tool (e.g., if not currently following the user) or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get a user's profile metadata by screen name OR numeric user ID.' This uses a specific verb ('Get') and resource ('profile metadata'), and the two identifier options are explicitly mentioned. It also distinguishes itself from sibling tools like get_user_followers or search_user by focusing on profile metadata for a single user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool: 'Caller must provide exactly one of screen_name / user_id.' This is a critical usage constraint. However, it does not explicitly mention when to use this tool versus alternatives like search_user or get_user_tweets, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses rate limiting and risk scanning behavior beyond the schema, which is valuable. But with no annotations provided, the description carries the full burden; it omits other behavioral traits like reversibility or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff: first sentence states purpose, second adds crucial context. Well front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the action and presence of output schema, the description covers purpose, parameter details, and important rate-limit behavior fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Clarifies the screen_name parameter format (without @), adding essential meaning beyond the schema's type and title. Parameter is simple but comprehensively explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (unmute) and resource (user) with the specific input (screen name). Distinct from sibling tools like mute_user and block_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns against bulk usage due to rate limiting and risk scanning, providing clear usage context. However, does not explicitly contrast with alternatives beyond the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the message is private and that bulk calls risk account suspension, adding important behavioral context beyond what the schema provides. It doesn't cover all failure modes but does provide meaningful risk information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with a clear purpose statement followed by a risk warning and an Args list. Every sentence adds value, and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 3-parameter tool and the presence of an output schema, the description covers the core purpose, parameter semantics, and key risk warning. It lacks explicit when-to-use vs alternatives, but combined with schema and output schema it is sufficient for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds crucial semantics beyond the bare schema: it specifies that screen_name should be without '@', that text must be non-empty, and that media_id is optional. Since schema description coverage is 0%, this fully compensates for the schema's lack of parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear action verb ('Send') and identifies the specific resource ('a direct message to a user by screen name'). This distinguishes it from siblings like send_tweet and send_dm_to_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that DMs are private and warns against bulk-calling due to X's aggressive anti-spam, which helps an agent decide when to invoke this tool sparingly. It doesn't explicitly name alternatives, but the screen-name targeting implies one-on-one DMs, distinguishing it from send_dm_to_group.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the message is PRIVATE and warns about aggressive anti-spam and account suspension, which is valuable behavioral context. It doesn't cover all possible behaviors (e.g., rate limits, failure modes), but the disclosed warnings are significant for a messaging tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-structured: a one-line purpose, a brief warning note, and a bulleted Args list. Every sentence adds value, no fluff, and the formatting makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 purpose, usage warning, and all parameters. It doesn't need to describe return values because an output schema exists. The anti-spam warning adds crucial context, making this fully adequate for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates fully with an explicit Args section. It explains group_id (conversation ID), text (required, must not be empty), and media_id (optional media ID), adding meaning beyond the schema's type/title information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Send a direct message to a group conversation,' which clearly states the action, resource, and scope. This distinguishes it from sibling tools like send_dm (which presumably targets an individual user) and other DM-related tools by explicitly mentioning 'group'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for group conversations and includes a strong anti-spam warning ('Do not bulk-call... may suspend the account'). However, it doesn't explicitly name alternatives or state when NOT to use this tool (e.g., 'use send_dm for individual users'), so it lacks explicit exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it warns about returning PRIVATE decrypted message text from your own machine and explicitly states that reading does NOT mark the conversation read on X. It doesn't mention rate limits or auth needs, but for a simple read tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured: a one-line purpose, a critical privacy note, a return format section, and an args list. Every sentence adds value, with no repetition of schema information already present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no annotations) and the description covers all essential aspects: purpose, output format (oldest-first messages with fields), parameter source and constraints, and behavioral notes. It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully. conversation_id is explained as coming from xchat_list_conversations, and limit is given with range (1-500) and default (50), plus the semantic 'most recent kept'. This goes well beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read messages from one XChat (encrypted DM) conversation', using a specific verb and resource. It distinguishes itself from siblings like xchat_list_conversations (lists conversations) and get_dm_history (likely regular DMs) by specifying the XChat encrypted DM context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool and directs the user to get conversation_id from xchat_list_conversations. However, it doesn't explicitly name alternatives or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 openly discloses that private message previews are returned, that previews use placeholder text for non-text attachments, and that results are ordered by newest activity first. This is strong transparency, though it omits details like rate limits, authentication, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately concise. It front-loads the core purpose, includes a necessary privacy note, specifies the output JSON structure, and documents arguments. Each section serves a distinct purpose without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 no annotations, the description covers all essential aspects: what it does, output format, parameter constraints, and a privacy caveat. It is complete enough for an agent to invoke the tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 provides explicit ranges for 'limit' (1-500), clarifies the default (50), and explains 'unread_only' as filtering to conversations with unread messages. The schema only has titles and defaults, so these details are essential and well-covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('List') and resource ('XChat conversations'), and adds sorting criterion ('newest activity first'). It distinguishes itself from sibling tools like xchat_get_history, which likely focuses on message history within a conversation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on what the tool does and highlights a privacy caveat about returning private message previews from the user's machine. While it doesn't explicitly mention alternatives or when not to use it, the purpose is well-scoped and the note implies caution appropriate for the tool's nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full responsibility for behavioral disclosure. It explicitly states the operation is read-only ('opens the resulting SQLite file read-only'), asserts 'Nothing is sent, marked read, or modified', and explains the local decryption context. This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary, behavior details, output shape, and configuration. It is slightly longer than strictly necessary but every sentence carries meaningful information—no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having zero parameters and an output schema, the description fully explains the tool's behavior, expected outputs (state, database_path, conversation_count, last_updated, discovery), and configuration prerequisites. This is complete for an agent to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds useful configuration context via environment variables (XCHAT_BROWSER, XCHAT_BROWSER_PROFILE, XCHAT_DATABASE_PATH), though these are not formal parameters. No schema coverage issues exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Check whether XChat (encrypted DMs) can be read on this machine.' It clearly distinguishes itself from sibling tools like xchat_list_conversations and xchat_get_history by focusing on readability/status rather than content retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is a pre-flight check for accessing XChat local storage, and it explains the discovery flow when no store is configured. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![twitter-mcp MCP server](https://glama.ai/mcp/servers/tangivis/twitter-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tangivis/twitter-mcp)

Score Badge

Copy to your README.md:

[![twitter-mcp MCP server](https://glama.ai/mcp/servers/tangivis/twitter-mcp/badges/score.svg)](https://glama.ai/mcp/servers/tangivis/twitter-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tangivis/twitter-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server