X (Twitter) MCP server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources and actions, such as get_user_by_id vs. get_user_by_screen_name for user lookup, and bookmark_tweet vs. favorite_tweet for engagement. However, there is some overlap between get_latest_timeline and get_timeline, which both retrieve home timeline tweets with only subtle differences ('Following' vs. 'For You'), potentially causing confusion for an agent.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as get_user_by_id, delete_tweet, and post_tweet. All names use snake_case uniformly, and verbs like 'get', 'create', 'delete', and 'post' are applied predictably across similar resources, making the set easy to navigate and understand.
Tool Count3/5
With 23 tools, the count is on the higher side for a Twitter API server, bordering on heavy but still within a reasonable scope given the platform's complexity. It covers many aspects like tweets, users, and engagement, but may feel slightly bloated compared to a more streamlined set of 10-15 core tools.
Completeness4/5
The tool set provides comprehensive coverage for core Twitter operations, including CRUD for tweets (post, delete), user lookup (by ID, screen name), engagement (favorite, bookmark), and timelines. Minor gaps exist, such as no direct tools for managing lists or sending direct messages, but agents can work around these with the available tools for most common workflows.
Average 2.9/5 across 23 of 23 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Favorites a tweet' implies a write/mutation operation, but it doesn't disclose any behavioral traits such as authentication requirements, rate limits, side effects, error conditions, or what happens if the tweet is already favorited. This leaves critical behavioral aspects undocumented.
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 at just two words, which is appropriate for a simple action. It's front-loaded with the core purpose, though it could benefit from additional context. There's no wasted verbiage, but it may be overly terse given the lack of other documentation.
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?
Given that this is a mutation tool with no annotations, 0% schema description coverage, and only basic output schema (implied by 'has_output_schema: true'), the description is incomplete. It doesn't address behavioral aspects, parameter meaning, or usage context, making it inadequate for safe and effective tool invocation despite the output schema potentially covering return values.
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 provides no information about the 'tweet_id' parameter beyond what's in the schema (which has 0% description coverage). It doesn't explain what a tweet ID is, where to find it, its format, or any constraints. With low schema coverage, the description fails to compensate, leaving parameter meaning unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Favorites a tweet' is a tautology that essentially restates the tool name with minimal additional information. It specifies the verb ('favorites') and resource ('a tweet'), but doesn't distinguish it from sibling tools like 'bookmark_tweet' or 'unfavorite_tweet' beyond the basic action implied by the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 doesn't mention when to use 'favorite_tweet' instead of 'bookmark_tweet', when to use it versus 'unfavorite_tweet', or any prerequisites or context for its use. The agent must infer usage entirely from the tool name and sibling list.
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 'mocked', implying it may not have real effects, but does not clarify what this means (e.g., whether it simulates voting, requires authentication, or has rate limits). This leaves significant gaps in understanding the tool's 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 extremely concise with a single phrase, 'Vote on a poll (mocked)', which is front-loaded and wastes no words. Every part of the sentence contributes to the core idea, making it efficient in structure.
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?
Given the tool's complexity (a mutation with no annotations, 2 parameters, and an output schema), the description is incomplete. It lacks details on behavior, parameter meanings, and how it integrates with the Twitter context from sibling tools, failing to provide sufficient context for effective use.
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 input schema has 0% description coverage, so parameters 'choice' and 'tweet_id' are undocumented in the schema. The description adds no meaning beyond the schema, failing to explain what 'choice' represents (e.g., poll options) or how 'tweet_id' relates to the poll, which is inadequate given the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Vote on a poll (mocked)' restates the tool name 'vote_on_poll' with minimal elaboration, making it tautological. It specifies the verb 'vote' and resource 'poll' but lacks detail on what 'mocked' entails or how it differs from real voting, and does not distinguish it from sibling tools like 'create_poll_tweet'.
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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing an existing poll), exclusions, or how it relates to sibling tools such as 'create_poll_tweet' or 'get_tweet_details', leaving usage unclear.
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 mentions the operation is 'simulated', hinting at non-production behavior, but fails to detail critical aspects like rate limits, authentication needs, pagination (implied by 'cursor' parameter), or what 'common followers' entails operationally. This leaves significant gaps for safe and effective use.
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 a single, efficient sentence that directly states the tool's action. It's front-loaded with the core purpose, though it could be more structured by elaborating on key details. There's no wasted text, making it appropriately concise for its limited content.
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?
Given the tool has 3 parameters with 0% schema coverage, no annotations, and an output schema (which helps but isn't described), the description is incomplete. It doesn't explain parameter meanings, behavioral constraints, or differentiation from siblings, making it inadequate for the agent to use 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description adds no information about the parameters (user_id, count, cursor), such as what 'user_id' refers to, how 'count' affects results, or how 'cursor' is used for pagination. This fails to compensate for the lack of schema documentation, leaving parameters largely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'retrieves a list of common followers (simulated)', which provides a verb ('retrieves') and resource ('common followers'), but it's vague about what 'common followers' means (e.g., followers shared with another user?). It doesn't differentiate from sibling tools like 'get_user_followers', leaving ambiguity about their distinct 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?
No guidance is provided on when to use this tool versus alternatives such as 'get_user_followers' or 'get_user_following'. The description lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions searching but doesn't disclose behavioral traits like rate limits, authentication needs, pagination (implied by 'cursor' parameter but not explained), or what the search returns (e.g., tweets, users). This is inadequate for a tool with multiple parameters and no annotation coverage.
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, efficient sentence with zero waste. It's front-loaded and appropriately sized for a basic tool, though it under-specifies rather than being overly verbose.
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?
Given complexity (4 parameters, 0% schema coverage, no annotations) and an output schema exists (which helps), the description is incomplete. It doesn't cover parameter meanings, usage context, or behavioral aspects, making it insufficient for effective tool selection and invocation.
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%, so the description must compensate but adds no parameter information. It doesn't explain 'query' (e.g., search syntax), 'count' (max results), 'cursor' (pagination), or 'product' (e.g., 'Top' vs 'Latest'). With 4 parameters and no schema descriptions, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search Twitter with a query' states a clear verb ('Search') and resource ('Twitter'), but it's vague about scope and doesn't distinguish from siblings like 'get_timeline' or 'get_user_mentions' which also retrieve tweets. It specifies the action but lacks detail on what kind of search (e.g., public tweets, users, trends).
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. With many sibling tools for retrieving tweets (e.g., 'get_timeline', 'get_user_mentions'), the description doesn't indicate this is for general keyword-based searches, leaving the agent to infer usage from the name alone.
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 states the retrieval action and simulation aspect, lacking critical information about permissions, rate limits, pagination behavior (implied by cursor parameter), or what 'highlighted' means operationally. This is inadequate for a tool with multiple parameters and no annotation coverage.
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 a single, efficient sentence that gets straight to the point without unnecessary words. However, it's arguably too concise given the lack of parameter and behavioral information needed for this tool.
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?
For a tool with 3 parameters (one required), 0% schema coverage, no annotations, but with an output schema, the description is insufficient. It doesn't explain the simulation aspect, parameter meanings, or behavioral constraints. The output schema helps with return values, but the description should provide more operational context given the complexity.
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%, so the description must compensate but adds no parameter information. It doesn't explain what user_id refers to, what count controls, or how cursor works for pagination. The description fails to provide any semantic context beyond what's minimally inferable from parameter names.
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 ('Retrieves') and resource ('highlighted tweets from a user's timeline'), distinguishing it from siblings like get_timeline or get_user_mentions. However, it doesn't specify what makes tweets 'highlighted' or how this differs from other tweet-fetching tools beyond the simulated aspect.
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 get_timeline or get_user_mentions. The description mentions 'simulated' but doesn't explain what that means for usage decisions, leaving the agent with no context for tool 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 provided, the description carries the full burden of behavioral disclosure. It states 'create' implying a write operation, but fails to mention critical aspects like authentication requirements, rate limits, whether the tweet is publicly posted, or what happens on success/failure. This leaves significant gaps in understanding the tool's behavior and risks.
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 that directly states the tool's purpose without any fluff or redundancy. It is front-loaded and wastes no words, making it efficient for quick understanding, though this brevity contributes to gaps in other dimensions.
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?
Given the tool's complexity (a write operation with 3 parameters), no annotations, and low schema coverage, the description is incomplete. While an output schema exists, the description does not address key contextual elements like behavioral traits, parameter meanings, or usage guidelines, leaving the agent poorly equipped to use the tool effectively.
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 input schema has 0% description coverage, so the description must compensate but adds no parameter details beyond the tool name. It does not explain what 'choices', 'duration_minutes', or 'text' represent (e.g., poll options, voting time, tweet content), their formats, or constraints (e.g., choice count limits, duration range). This fails to provide meaningful semantic context for the parameters.
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 verb 'create' and the resource 'tweet with a poll', making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'post_tweet' (which creates a regular tweet) or 'vote_on_poll' (which interacts with existing polls), leaving room for ambiguity in distinguishing its unique function.
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, such as 'post_tweet' for non-poll tweets or 'vote_on_poll' for interacting with existing polls. It lacks any context about prerequisites, constraints, or typical scenarios, offering minimal help in decision-making.
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 states this is a retrieval operation, implying it's read-only, but doesn't mention pagination behavior (though parameters suggest it), rate limits, authentication requirements, or what the output looks like. The phrase 'uses following as proxy' adds some context but is vague about implementation details.
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 a single, efficient sentence that gets straight to the point. It's appropriately sized for a retrieval tool, with no wasted words. However, the phrase 'uses following as proxy' is somewhat cryptic and could be clarified without adding excessive length.
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 there's an output schema (which should document return values), the description doesn't need to explain outputs. However, for a tool with 3 parameters (0% schema coverage) and no annotations, it should provide more context about pagination behavior and the meaning of 'subscribed'. The current description is minimally adequate but leaves gaps in understanding how to use the tool effectively.
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%, so the description must compensate for undocumented parameters. It only mentions 'specified user' which maps to user_id, but doesn't explain count (default 100, pagination limit) or cursor (pagination token). With 3 parameters and no schema descriptions, the description adds minimal value beyond what's inferred from parameter names.
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's purpose: 'Retrieves a list of users to which the specified user is subscribed'. It specifies the verb 'retrieves' and the resource 'list of users', and distinguishes it from siblings like get_user_followers or get_user_following by focusing on subscriptions. However, it doesn't fully explain what 'subscribed' means in this context, leaving some ambiguity.
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 mentions 'uses following as proxy', which hints at a relationship to 'following' functionality, but doesn't explicitly state when to choose this over get_user_following or other user-related tools. 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions retrieval but doesn't describe important behaviors like pagination (implied by 'cursor' parameter), rate limits, authentication requirements, error conditions, or what the returned list contains. For a tool with 3 parameters and no annotation coverage, this is inadequate.
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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a retrieval tool and front-loads the core functionality.
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 has an output schema (which handles return values), no annotations, and 3 parameters with 0% schema coverage, the description is incomplete. It covers the basic purpose but misses parameter explanations, behavioral context, and sibling differentiation that would make it fully adequate for agent use.
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%, so the description must compensate by explaining parameters. It mentions 'for a given user' which hints at the 'user_id' parameter, but doesn't explain 'count' (defaults to 100) or 'cursor' (pagination). With 3 undocumented parameters, the description adds minimal value beyond what's inferred from the tool name.
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 verb ('retrieves') and resource ('list of followers for a given user'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get_user_followers_you_know' or 'get_user_following', which would be needed for a perfect score.
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 like 'get_user_followers_you_know' or 'get_user_following', nor does it mention prerequisites or context for usage. It simply states what the tool does without indicating appropriate scenarios.
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?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Unfavorites a tweet' implies a mutation (removing a favorite), but it doesn't disclose any behavioral traits: no mention of permissions needed, whether it's reversible, rate limits, or what the output contains. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence ('Unfavorites a tweet') that directly states the purpose without any fluff. It's appropriately sized for a simple tool and front-loaded with the core action, making it easy to parse quickly.
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?
Given the tool's complexity (a mutation with no annotations) and the presence of an output schema (which helps), the description is incomplete. It lacks behavioral details (e.g., permissions, effects), usage guidelines, and doesn't leverage the output schema to explain return values. For a mutation tool in a set with many siblings, this is insufficient.
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 has 0% schema description coverage (parameter 'tweet_id' is undocumented in schema), but it compensates well. 'Unfavorites a tweet' implies the 'tweet_id' parameter identifies the tweet to unfavorite, adding clear semantic meaning beyond the bare schema. With only 1 parameter, this is sufficient for a baseline of 4.
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 'Unfavorites a tweet' clearly states the action (unfavorite) and target resource (a tweet) with a specific verb. It distinguishes from sibling tools like 'favorite_tweet' (opposite action) and 'delete_tweet' (different operation). However, it doesn't specify what 'unfavorite' means in Twitter's context (removing from likes/favorites), keeping it at 4 rather than 5.
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 doesn't mention prerequisites (e.g., the tweet must already be favorited), contrast with 'favorite_tweet', or explain use cases. With sibling tools like 'favorite_tweet' and 'delete_tweet' present, this lack of context is a clear gap.
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 full burden but only states the basic action without disclosing behavioral traits such as permissions needed, rate limits, whether it's idempotent, or what happens if the tweet is already bookmarked. This leaves 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 a single, efficient sentence with zero wasted words, making it easy to parse and front-loaded with the core action. Every word earns its place, though it could benefit from more 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?
Given the tool's moderate complexity (a mutation with 2 parameters), no annotations, and an output schema, the description is minimally adequate but incomplete. It covers the basic purpose but lacks behavioral context and parameter guidance, making it just viable.
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 description coverage is 0%, so the description must compensate but adds no parameter information beyond what's implied by the tool name. It doesn't explain 'tweet_id' or 'folder_id' semantics, though with only 2 parameters and an output schema, the baseline is 3 as the schema handles structure.
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 ('Adds') and target resource ('the tweet to bookmarks'), making the tool's purpose immediately understandable. However, it doesn't differentiate this from sibling tools like 'delete_bookmark' or 'favorite_tweet' beyond the basic verb, missing explicit distinction.
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 like 'favorite_tweet' or 'delete_bookmark', nor does it mention prerequisites or context for bookmarking tweets. It lacks any usage instructions or exclusions.
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 'removes,' implying a destructive mutation, but lacks details on permissions, reversibility, side effects, or response format. For a mutation tool with zero annotation coverage, this is a significant gap in 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 a single, direct sentence with no wasted words, making it highly concise and front-loaded. Every part of the sentence ('Removes the tweet from bookmarks') contributes essential information about the tool's action and target.
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 complexity (a destructive mutation with one parameter) and the presence of an output schema (which likely covers return values), the description is minimally complete. However, with no annotations and incomplete parameter guidance, it leaves gaps in behavioral and usage context that could hinder effective tool selection.
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 description doesn't add any parameter-specific information beyond what the schema provides (a single 'tweet_id' parameter). With 0% schema description coverage, the baseline is low, but the description doesn't compensate by explaining the parameter's meaning, format, or constraints. However, since there's only one parameter and its purpose is implied by the tool name, a score of 3 reflects minimal adequacy.
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 ('removes') and resource ('the tweet from bookmarks'), making the tool's purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'delete_tweet' or 'delete_all_bookmarks', which would require mentioning it's specifically for bookmarks rather than tweet deletion or bulk operations.
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 doesn't mention prerequisites (e.g., the tweet must be bookmarked first), exclusions, or compare it to siblings like 'delete_all_bookmarks' for bulk removal or 'unfavorite_tweet' for similar actions on favorites.
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. While 'Delete' implies a destructive mutation, the description doesn't specify whether this action is reversible, what permissions are required, rate limits, or what happens upon success/failure. This leaves significant behavioral gaps for a destructive 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 with a single, clear sentence that states exactly what the tool does without any unnecessary words. It's perfectly front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive mutation tool with no annotations, the description is minimally adequate but has clear gaps. The existence of an output schema helps, but the description doesn't address important contextual aspects like authentication requirements, irreversibility, or error conditions that would be crucial for safe tool invocation.
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 description mentions 'by its ID' which adds context about the tweet_id parameter's purpose, but with 0% schema description coverage and only 1 parameter, this provides minimal additional value beyond what's obvious from the parameter name. The baseline for 0 parameters would be 4, but with 1 parameter and low coverage, 3 is appropriate.
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 ('Delete') and target resource ('a tweet by its ID'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'delete_bookmark' or 'delete_all_bookmarks', which prevents a perfect score.
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. There's no mention of prerequisites (like authentication), when not to use it, or how it differs from other deletion tools in the sibling list, leaving the agent without contextual 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 carries full burden but offers minimal behavioral insight. It implies a read operation ('Get tweets') but doesn't disclose authentication needs, rate limits, pagination behavior, or what happens if 'count' exceeds available tweets. The mention of 'your home timeline' hints at personalization but lacks detail.
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, efficient sentence that front-loads the core purpose. There's no wasted verbiage, and it directly communicates the tool's function without unnecessary elaboration.
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 moderate complexity (fetching personalized timeline data), no annotations, and an output schema (which handles return values), the description is minimally adequate. It states what the tool does but lacks context on usage, behavioral traits, or parameter nuances, leaving gaps for an AI agent to infer.
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 description adds no parameter semantics beyond what the input schema provides (schema description coverage is 0%, but the schema itself documents 'count' with type and default). Since there's only one parameter with basic documentation in the schema, the baseline is 3—the description doesn't compensate for the coverage gap but doesn't worsen it either.
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 ('Get tweets') and resource ('from your home timeline'), specifying it's for the 'Following' timeline. However, it doesn't explicitly differentiate from sibling tools like 'get_timeline' (which might have different scope) or 'get_user_mentions', leaving some ambiguity about when to choose this specific tool.
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 like 'get_timeline' or 'get_user_mentions'. It mentions the 'Following' timeline but doesn't clarify if this is the default or only option, nor does it reference any prerequisites or exclusions.
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 full burden but only states what the tool does, not how it behaves. It doesn't disclose pagination behavior (cursor usage), rate limits, authentication requirements, data freshness, or what happens with seen_tweet_ids. For a read operation with 3 parameters, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place with no redundancy or unnecessary elaboration, making it easy 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 moderate complexity (3 parameters, read operation), no annotations, but with an output schema (which handles return values), the description is minimally adequate. It states the purpose but lacks parameter explanations and behavioral context that would make it complete for safe, effective use.
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%, so the description must compensate but provides no parameter information. It doesn't explain what 'count' controls (number of tweets), how 'cursor' enables pagination, or what 'seen_tweet_ids' filters. With 3 undocumented parameters, the description adds no semantic value beyond the bare schema.
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 verb 'Get' and the resource 'tweets from your home timeline', specifying it's for the 'For You' algorithmic feed. This distinguishes it from siblings like get_latest_timeline (chronological feed) and get_user_mentions (mentions). However, it doesn't explicitly contrast with all siblings like get_highlights_tweets or search_twitter.
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 retrieving the personalized home timeline feed, but doesn't explicitly state when to use this versus alternatives like get_latest_timeline (chronological) or get_user_mentions. No exclusions or prerequisites are mentioned, leaving some ambiguity about the optimal use case.
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 but provides minimal information. It states the tool retrieves trending topics but doesn't mention authentication requirements, rate limits, data freshness, whether results are personalized or global, or what format the output takes. For a tool that accesses external API data, this represents significant gaps in behavioral 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?
The description is extremely concise at just 5 words, front-loading the core purpose immediately. There's no wasted language or unnecessary elaboration. While it may be too brief for complete understanding, it achieves maximum efficiency in its current form with every word contributing to the core meaning.
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 (which reduces the need to describe return values), the description provides the basic purpose but lacks important context. For a tool with no annotations, 0% schema description coverage, and multiple sibling tools, the description should explain more about what 'trending topics' means, how they're determined, and when to use this versus other retrieval tools. It's minimally adequate but has clear gaps.
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 description mentions no parameters at all, while the schema shows two parameters (category and count) with 0% schema description coverage. Since the schema provides parameter names and types but no descriptions, the description should compensate but doesn't. The baseline is 3 because schema coverage is 0%, but the description fails to add any parameter meaning beyond what's in the bare schema.
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 verb ('Retrieves') and resource ('trending topics on Twitter'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'search_twitter' or 'get_timeline' that also retrieve Twitter content, missing the opportunity to specify this tool focuses specifically on trending topics rather than general search or timeline content.
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. With sibling tools like 'search_twitter' and 'get_timeline' that also retrieve Twitter data, there's no indication that this tool should be used specifically for trending topics rather than other types of content retrieval. No prerequisites, exclusions, or comparison to alternatives 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, so the description carries the full burden of behavioral disclosure. It states the tool 'gets' information, implying a read-only operation, but doesn't mention rate limits, authentication needs, error conditions, or what 'detailed information' entails (e.g., metadata, engagement stats). This leaves significant gaps for a tool interacting with an external API.
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, efficient sentence that front-loads the core purpose without unnecessary words. Every part ('Get detailed information about a specific tweet') earns its place by specifying the action and target.
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 low complexity (one parameter) and the presence of an output schema (which should define return values), the description is somewhat complete but lacks context. It doesn't cover behavioral aspects like rate limits or authentication, which are important for API tools. With no annotations, it should do more to compensate, making it adequate but with clear gaps.
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 description adds no meaning beyond the input schema, which has 0% description coverage and only documents 'tweet_id' as a required string. Since schema coverage is low, the description should compensate but doesn't explain what a tweet_id is or its format. With one parameter and no schema details, a baseline of 3 is applied, but it's minimal.
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 ('Get detailed information') and the resource ('about a specific tweet'), which distinguishes it from siblings like get_timeline or get_user_profile that fetch different resources. However, it doesn't specify what 'detailed information' includes or differentiate from get_highlights_tweets, which might also provide tweet details.
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 like get_timeline (for multiple tweets) or search_twitter (for finding tweets). It implies usage for a single tweet but doesn't specify prerequisites or exclusions, such as whether it works for deleted tweets or requires authentication.
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 it 'fetches' a user, implying a read-only operation, but doesn't specify if it requires authentication, rate limits, error handling, or what happens if the user ID is invalid. This leaves significant gaps in understanding the tool's 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 extremely concise with a single sentence that directly states the tool's action. It is front-loaded and wastes no words, making it easy 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 low complexity (one parameter) and the presence of an output schema, the description is minimally adequate. However, with no annotations and a simple schema, it should provide more context about usage and behavior to be fully helpful, especially with sibling tools that fetch similar resources.
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 description adds no meaning beyond the input schema, which has 0% description coverage. It doesn't explain what 'user_id' represents, its format, or constraints. However, with only one parameter, the baseline is 4, but the lack of any semantic context reduces it to 3, as the schema alone provides minimal 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 the verb ('Fetches') and resource ('a user'), making the purpose immediately understandable. However, it doesn't differentiate from sibling 'get_user_by_screen_name', which fetches the same resource using a different identifier, leaving room for confusion about when to use each.
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 like 'get_user_by_screen_name' or 'get_user_profile'. It lacks context about prerequisites, such as needing a user ID, and doesn't mention any exclusions or specific use cases.
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 mentions retrieval but lacks details on permissions needed, rate limits, pagination behavior (implied by cursor/count but not explained), or what the output contains. This is inadequate for a tool with parameters and potential complexity.
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, efficient sentence with no wasted words, making it easy to parse and front-loaded with the core purpose. It earns its place by clearly stating the tool's function.
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 has an output schema (which handles return values), no annotations, and low schema coverage, the description is incomplete. It covers the basic purpose but misses usage guidelines, parameter details, and behavioral traits, leaving gaps for an AI agent to operate effectively.
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 description coverage is 0%, so the description must compensate, but it only mentions 'the given user' (hinting at user_id). It doesn't explain count or cursor parameters, leaving them undocumented. The baseline is 3 due to high schema coverage, but here coverage is low, so the description adds minimal value beyond the schema.
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 verb ('retrieves') and resource ('users the given user is following'), making the purpose specific and understandable. It distinguishes from siblings like 'get_user_followers' by focusing on following rather than followers, though it doesn't explicitly name alternatives.
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 'get_user_followers' or 'get_user_profile', nor any context about prerequisites or limitations. The description only states what it does, not when it's appropriate.
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 but only states the basic function. It doesn't mention whether this is a read-only operation, if it requires authentication, rate limits, pagination behavior (implied by 'cursor' param but not explained), or what the output contains. This leaves significant gaps for a tool with 3 parameters.
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, front-loaded sentence with zero wasted words. It efficiently conveys the core purpose without unnecessary elaboration, making it easy 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 moderate complexity (3 params, no annotations) but with an output schema (which handles return values), the description is minimally adequate. It covers the 'what' but lacks behavioral context, parameter details, and usage guidance, leaving the agent to infer from schema alone.
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 description adds no parameter-specific information beyond implying 'user_id' is required for targeting. With 0% schema description coverage, it doesn't compensate by explaining 'count' (default, range), 'cursor' (pagination), or 'user_id' format. However, the baseline is 3 since the description at least hints at the core parameter purpose.
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 ('Get') and resource ('tweets mentioning a specific user'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'search_twitter' or 'get_user_profile', but the focus on user mentions is specific enough for basic clarity.
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 'search_twitter' (which might also find mentions) or 'get_user_profile' (for user info). The description lacks context about prerequisites, timing, or exclusions, leaving usage decisions ambiguous.
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 states this is a 'Get' operation, implying it is read-only, but does not specify permissions, rate limits, error conditions, or what 'detailed profile information' entails. For a tool with zero annotation coverage, 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 a single, efficient sentence with no wasted words. It is front-loaded with the core purpose, 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.
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) and the presence of an output schema, the description is minimally adequate. However, with no annotations and unclear differentiation from siblings, it lacks completeness for optimal agent guidance, scoring at the minimum viable level.
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 has 0% description coverage, but the description does not add any parameter-specific information beyond implying a 'user_id' is needed. With one parameter and no schema details, the baseline is 3 as the description does not compensate for the coverage gap but also does not mislead.
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 verb ('Get') and resource ('detailed profile information for a user'), making the purpose unambiguous. However, it does not distinguish this tool from sibling tools like 'get_user_by_id' or 'get_user_by_screen_name', which appear to serve similar user retrieval functions, preventing a score of 5.
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 such as 'get_user_by_id' or 'get_user_by_screen_name'. It lacks context about prerequisites, exclusions, or specific use cases, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states 'Post a tweet' which implies a write/mutation operation, but doesn't disclose behavioral traits like authentication needs, rate limits, whether it's idempotent, or what happens on failure (e.g., duplicate tweets). For a mutation tool with zero annotation coverage, this is a significant gap in 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 a single, efficient sentence that front-loads the core action ('Post a tweet') and lists optional features without waste. Every word earns its place, making it easy to scan and understand 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 complexity (mutation with 4 parameters), no annotations, and an output schema (which reduces need to describe returns), the description is minimally adequate. It covers the basic purpose and parameters but lacks behavioral context and usage guidelines, making it incomplete for safe, effective use by an agent.
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 description coverage is 0%, so the description must compensate. It mentions 'optional media, reply, and tags' which maps to three parameters (media_paths, reply_to, tags) and implies text is required, adding some meaning beyond the bare schema. However, it doesn't explain parameter formats (e.g., what media_paths expects, how tags differ from text) or constraints, leaving gaps.
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 ('Post a tweet') and mentions optional features (media, reply, tags), which distinguishes it from read-only sibling tools like get_timeline or get_tweet_details. However, it doesn't explicitly differentiate from other tweet-creation tools like create_poll_tweet, which is a minor gap.
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 like create_poll_tweet for polls or reply_to for threading context. It mentions optional features but doesn't specify prerequisites, constraints, or typical use cases, leaving the agent to infer usage from parameter names alone.
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 full burden for behavioral disclosure. It states the destructive action ('deletes') but doesn't clarify what 'simulated' means operationally—whether it's a test mode, requires confirmation, or has other safety mechanisms. No information about permissions, rate limits, or response behavior is included, leaving significant gaps for a destructive 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 single, front-loaded sentence that directly states the tool's function without unnecessary words. Every part ('Deletes all bookmarks') earns its place, and the parenthetical '(simulated)' adds critical context efficiently. No structural issues or redundancy are present.
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 destructive nature and zero parameters, the description is minimally adequate but incomplete. It lacks details on the 'simulated' aspect, output behavior (though an output schema exists), and safety considerations. With no annotations and a simple input schema, the description should provide more behavioral context to fully guide the 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 tool has zero parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's action. This meets the baseline for parameter-less tools, though it doesn't add extra semantic context beyond the schema.
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 ('deletes') and target resource ('all bookmarks'), making the purpose immediately understandable. It distinguishes itself from the sibling 'delete_bookmark' by specifying 'all' rather than individual deletions. However, the parenthetical '(simulated)' slightly reduces specificity by indicating this might not be a real deletion operation.
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 like 'delete_bookmark' for individual deletions. There's no mention of prerequisites, warnings about data loss, or contextual recommendations for bulk deletion scenarios. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the basic action ('fetches') without mentioning permissions, rate limits, error conditions, or what the output contains. This leaves significant gaps in understanding how the tool behaves beyond its core 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 a single, efficient sentence with no wasted words. It is appropriately sized for a simple lookup tool and front-loads the essential 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?
Given the tool's low complexity (one parameter) and the presence of an output schema, the description is reasonably complete for its purpose. However, it lacks behavioral context and usage guidelines, which are notable gaps despite the structured support.
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 description mentions 'by screen name', which clarifies the parameter's purpose beyond the schema's generic 'Screen Name' title. However, with 0% schema description coverage and only one parameter, the baseline is 4, but the description adds minimal semantic value, so a 3 is appropriate.
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 verb ('fetches') and resource ('a user'), making the purpose understandable. However, it doesn't distinguish this tool from its sibling 'get_user_by_id', which performs a similar function but uses a different identifier.
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 'get_user_by_id' or 'get_user_profile'. The description offers no context about prerequisites, limitations, or appropriate scenarios for selecting this specific tool.
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:

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

Score Badge

Copy to your README.md:

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

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/rafaljanicki/x-twitter-mcp-server'

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