Twitter MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between get_twitter_user and get_twitter_user_by_id (both retrieve user profiles via different identifiers) and between search_twitter and search_twitter_advanced (both search tweets, with the latter being a superset). The descriptions clarify the differences, preventing major confusion.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with clear verb_noun structures (e.g., add_twitter_watch, get_twitter_user_tweets, search_twitter_advanced). The naming is predictable and uniform across all 12 tools.
Tool Count5/5
With 12 tools, the server is well-scoped for Twitter/X monitoring and data retrieval. The count is appropriate, covering user management, tweet fetching, search, and monitoring without being overwhelming or insufficient for the domain.
Completeness4/5
The toolset provides strong coverage for monitoring and retrieving Twitter data, including user profiles, tweets, searches, and follower events. Minor gaps exist, such as no tools for posting tweets or interacting with tweets (e.g., liking, retweeting), but core retrieval and monitoring workflows are well-covered.
Average 3.2/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 3 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

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 tool performs a deletion (implying a destructive mutation) but doesn't specify whether this action is reversible, requires special permissions, has side effects, or provides confirmation feedback. For a destructive tool with zero annotation coverage, this lack of detail 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 extremely concise and well-structured: a clear purpose statement followed by a parameter explanation. Every sentence earns its place, with no redundant or verbose language. It's front-loaded with the core action, making it easy for an agent to quickly grasp the tool's function.
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 destructive nature, lack of annotations, and absence of an output schema, the description is incomplete. It doesn't cover critical aspects like what happens after deletion (e.g., success confirmation, error handling), whether the watch_id must be valid, or how this interacts with other monitoring functions. For a mutation tool with no structured safety cues, more context is needed.
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 includes an 'Args' section that documents the single parameter 'watch_id' as 'The monitoring record ID to delete,' adding semantic meaning beyond the schema (which has 0% description coverage and only provides type information). This compensates adequately for the low schema coverage, establishing a baseline understanding of the parameter's 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 ('Delete') and resource ('a Twitter user from monitoring list'), making the purpose unambiguous. It distinguishes itself from sibling tools like 'add_twitter_watch' by specifying deletion rather than addition. However, it doesn't fully differentiate from other potential deletion operations in the sibling set, 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., needing an existing watch_id), exclusions, or relationships with sibling tools like 'get_twitter_watch' for retrieving IDs. The agent must infer usage from context alone, which is insufficient for clear 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 full burden for behavioral disclosure. It states 'Get' which implies a read operation, but doesn't specify whether this requires authentication, rate limits, what happens if the ID is invalid, or the format of returned data. For a tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with two sentences: a purpose statement and parameter documentation. While efficient, the parameter section could be more integrated. There's no wasted text, but the structure feels slightly disjointed rather than fully cohesive.
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 1 parameter with 0% schema coverage, no annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't explain what a 'Twitter article' is versus tweets, how results differ from search tools, error conditions, or return format. For a retrieval tool in a crowded namespace, more context is needed.
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 schema provides no parameter descriptions. The description adds minimal semantics by naming 'article_id' as 'Twitter article ID', but doesn't explain what format this ID takes (numeric, alphanumeric, URL), where to find it, or provide examples. It compensates slightly but inadequately for the coverage gap.
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 'Twitter article by ID', making the purpose understandable. However, it doesn't differentiate this tool from potential siblings like 'get_twitter_user_tweets' or 'search_twitter', which might also retrieve Twitter content. The purpose is clear but lacks sibling differentiation.
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 siblings like 'get_twitter_user_tweets' and 'search_twitter' that might retrieve similar content, there's no indication whether this tool is for specific article IDs, whether it's faster/more precise, or any prerequisites. Usage is implied from the name but not explicitly 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 the full burden of behavioral disclosure. It states the tool returns KOL followers but doesn't describe what constitutes a KOL (e.g., criteria like follower count, verification status), how results are formatted (e.g., list, count, pagination), rate limits, authentication needs, or error handling. This leaves significant gaps for an agent to understand the tool's behavior beyond basic functionality.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a clarifying sentence and parameter details. There's no wasted text, and the structure is logical. However, it could be slightly more concise by integrating the parameter note into the main flow, but it's still efficient.
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 complexity (retrieving specialized follower data), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain what a KOL is, how results are returned, or any behavioral constraints (e.g., rate limits, data freshness). For a tool that likely involves API calls and data processing, this leaves too many unknowns for effective agent use.
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 minimal semantics beyond the input schema. It defines 'username' as 'Twitter username (without @)', which clarifies formatting but doesn't explain validation (e.g., length, allowed characters) or provide examples. With 0% schema description coverage and only 1 parameter, this compensates slightly but remains basic. The baseline is 3 due to low parameter count, but more detail would improve utility.
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: 'Get KOL (Key Opinion Leader) followers for a Twitter/X user' and elaborates with 'Returns which influential accounts (KOLs) are following this user.' This specifies the verb (get/return), resource (KOL followers), and scope (for a specific user). However, it doesn't explicitly differentiate from sibling tools like 'get_twitter_user' or 'get_twitter_follower_events', which reduces clarity about when this specific tool is uniquely appropriate.
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 sibling tools like 'get_twitter_user' (which might return general user info) or 'get_twitter_follower_events' (which might track follower changes), nor does it specify prerequisites (e.g., whether the user must be public or monitored). Usage is implied by the purpose but lacks explicit context 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 tool adds a user to a monitoring list but doesn't explain what monitoring entails, whether this is a write operation, if there are rate limits, or what happens on success/failure. This leaves significant gaps for an agent to understand 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief and front-loaded with the main purpose, followed by parameter details. The two-sentence structure is efficient, though the 'Args:' section could be integrated more smoothly into the flow.
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 lack of annotations and output schema, the description is incomplete. It doesn't cover what the tool returns, error conditions, or the implications of 'monitoring' (e.g., what data is collected, how it's accessed). For a tool that likely involves ongoing data collection, this is a significant oversight.
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, but the description compensates by explaining the 'username' parameter as 'Twitter username to monitor (without @)', adding crucial semantic context beyond the schema's basic type information. Since there's only one parameter, this is sufficient for clarity.
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 ('Add') and resource ('Twitter user to monitoring list'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from its sibling 'get_twitter_watch', which likely retrieves the monitoring list rather than adding to it.
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_twitter_watch' or 'delete_twitter_watch'. The description lacks context about prerequisites, such as whether the user must exist or if there are limits to the monitoring 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?
No annotations are provided, so the description carries the full burden. It mentions 'deleted tweets' but doesn't disclose critical behavioral traits: whether this requires prior setup (like a watch), rate limits, authentication needs, what happens if no deleted tweets exist, or the format of returned data. The description is minimal and lacks operational context.
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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a structured 'Args:' section. There's no wasted text, and each sentence adds value. It could be slightly more concise by integrating the args into the main flow, but it's efficient overall.
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 complexity (fetching deleted tweets likely involves monitoring or API constraints), no annotations, no output schema, and 2 parameters, the description is incomplete. It doesn't explain what 'deleted tweets' entails (e.g., recently deleted, all-time), how results are returned, or any dependencies on other tools like 'add_twitter_watch'. More context is needed for safe and effective use.
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%, so the description must compensate. It adds meaningful semantics: 'username' is clarified as 'Twitter username (without @)', and 'limit' specifies 'Maximum tweets to return (default 20, max 100)'. This goes beyond the schema's basic titles, providing practical usage details. However, it doesn't cover all edge cases (e.g., username validation).
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: 'Get deleted tweets from a Twitter/X user.' It specifies the verb ('Get') and resource ('deleted tweets'), and distinguishes it from siblings like 'get_twitter_user_tweets' (which presumably gets regular tweets). However, it doesn't explicitly contrast with all siblings (e.g., 'search_twitter'), so it's not a perfect 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., whether the user must be monitored first), nor does it differentiate from similar tools like 'get_twitter_user_tweets' or 'search_twitter' beyond the 'deleted' aspect. Usage context is implied but not explicit.
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 mentions the tool retrieves events with a limit (default 20, max 100), which adds some context, but lacks critical details like rate limits, authentication requirements, data freshness, or error handling. For a tool accessing external API data with no annotations, 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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a structured 'Args:' section. There's no wasted text, and each sentence earns its place by explaining parameters. Minor improvement could be made by integrating parameter details more seamlessly, but it's 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?
Given 3 parameters with 0% schema coverage and no output schema or annotations, the description is moderately complete. It covers parameter meanings well but lacks behavioral context (e.g., API constraints, error responses) and output details. For a tool that fetches event data from Twitter/X, more information on data format or limitations would enhance completeness.
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%, so the description must compensate. It successfully explains all three parameters: 'username' (Twitter username without @), 'is_follow' (True for followers, False for unfollowers), and 'limit' (default and max values). This adds meaningful semantics beyond the bare schema, though it doesn't cover edge cases like invalid usernames.
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: 'Get follower/unfollower events for a Twitter/X user.' It specifies the verb ('Get') and resource ('follower/unfollower events'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_twitter_kol_followers' or 'get_twitter_user', which might also retrieve follower-related data.
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 sibling tools or contexts where other tools might be more appropriate, such as using 'get_twitter_user' for general user info or 'get_twitter_kol_followers' for specific follower types. Usage is implied through parameter descriptions but not explicitly 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 burden. It states this is a 'Get' operation but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what happens with invalid/non-existent IDs. For a read operation with zero 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. The two-sentence structure is efficient, though the 'Args:' section formatting is slightly redundant with the schema but adds clarity.
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 (single parameter read operation), no annotations, and no output schema, the description is minimally adequate. It covers the purpose and parameter semantics but lacks behavioral context and usage guidance, leaving gaps for an 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 adds meaningful semantics beyond the schema. The input schema has 0% description coverage (just 'User Id' title), but the description clarifies that 'user_id' is a 'Twitter user ID (numeric string)', specifying the format and context. This compensates well for the schema gap.
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 with a specific verb ('Get') and resource ('Twitter/X user profile information'), and specifies the lookup method ('by user ID'). However, it doesn't explicitly differentiate from sibling tools like 'get_twitter_user' (which might use 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?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_twitter_user' (possibly by username) and 'search_twitter', there's no indication of when this specific ID-based lookup is preferred or required.
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 tool returns 'a list of Twitter accounts being monitored', which clarifies the output type. However, it lacks critical behavioral details: whether this requires authentication, rate limits, pagination for large result sets, or error conditions. For a read operation 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 extremely concise and well-structured: two clear sentences that front-load the core functionality ('Get all Twitter monitoring users') followed by the return value. Every word earns its place with zero redundancy or 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 simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does and what it returns. However, for a tool that likely involves API calls to Twitter, it should ideally mention authentication requirements or rate limiting considerations. The absence of output schema means the description should more fully describe the return format.
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 0 parameters with 100% schema description coverage (empty schema). The description appropriately doesn't discuss parameters since none exist. It focuses on what the tool does rather than parameter details, which is correct for a parameterless tool. Baseline 4 is appropriate as no parameter information is needed.
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: 'Get all Twitter monitoring users for the current user' specifies the verb ('Get'), resource ('Twitter monitoring users'), and scope ('for the current user'). It distinguishes from siblings like 'get_twitter_user' by focusing on monitored accounts rather than general user data. However, it doesn't explicitly differentiate from all siblings like 'get_twitter_kol_followers' which might overlap conceptually.
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 when this tool is appropriate compared to siblings like 'get_twitter_user' or 'search_twitter', nor does it specify prerequisites or exclusions. The context is implied (retrieving monitored accounts) but lacks explicit usage instructions.
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. While it lists parameters, it doesn't describe what the tool actually returns (tweet objects, metadata format), rate limits, authentication requirements, error conditions, or whether this is a read-only operation. The description focuses on inputs rather than behavioral outcomes.
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 efficiently structured with a brief purpose statement followed by a comprehensive parameter list. Each parameter explanation is clear and minimal. While somewhat lengthy due to 15 parameters, every line adds value and the structure is logical with parameter documentation following the initial summary.
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 complex tool with 15 parameters, no annotations, and no output schema, the description is incomplete. It thoroughly documents inputs but provides no information about return values, error handling, rate limits, or authentication requirements. The agent cannot understand what results to expect or operational constraints.
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 and 15 parameters, the description provides excellent parameter semantics by explaining each parameter's purpose with clear examples (e.g., 'hashtag: Filter by hashtag (without #)', 'lang: Language code (e.g. "en", "zh")', 'product: Sort by "Top" or "Latest"'). This fully compensates for the lack of schema 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 'Advanced Twitter/X search with multiple filters' which specifies the verb (search) and resource (Twitter/X) with the qualifier 'advanced' to indicate enhanced filtering capabilities. It distinguishes from the simpler 'search_twitter' sibling tool by emphasizing 'multiple filters' and 'advanced' nature, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the simpler 'search_twitter' sibling tool. There's no mention of use cases, prerequisites, or trade-offs between this advanced search and other Twitter-related tools on the server.
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 default values and limits, but doesn't cover important aspects like rate limits, authentication requirements, pagination, error handling, or what 'recent' means (time window). For a read operation with 4 parameters, this leaves significant 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 perfectly structured: a clear purpose statement followed by a well-organized parameter breakdown. Every sentence earns its place, with no wasted words. The information is front-loaded and efficiently presented.
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 no annotations and no output schema, the description does a decent job but has gaps. It covers parameters well but lacks information about return format, error conditions, rate limits, and authentication requirements. For a tool with 4 parameters and multiple sibling tools, it's adequate but not comprehensive.
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 must compensate - and it does well by explaining all 4 parameters: username format ('without @'), limit range and defaults, and the boolean filters' purposes. It adds meaningful context beyond the bare schema, though it doesn't specify exact return formats.
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 action ('Get recent tweets') and resource ('from a specific Twitter/X user'), distinguishing it from siblings like get_twitter_user (user profile) or search_twitter (general search). The verb+resource combination is precise and unambiguous.
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 tweets from a specific user, but provides no explicit guidance on when to use this tool versus alternatives like get_twitter_user_by_id (which might get user info) or search_twitter (for broader searches). The context is clear but lacks sibling differentiation.
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 default and maximum values for 'limit' (20, max 100), which adds useful context, but fails to address critical aspects like rate limits, authentication requirements, pagination, or what happens when no results match. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its operational 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 efficiently structured with a clear purpose statement followed by a bullet-point style parameter explanation. Every sentence earns its place by providing essential information without redundancy. The formatting makes 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 5 parameters with 0% schema coverage and no output schema, the description does a reasonable job explaining inputs but lacks information about return values, error conditions, or authentication requirements. For a search tool with multiple filtering options and no structured output documentation, it should provide more complete context about what the tool returns and how results are structured.
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%, so the description must compensate. It successfully adds meaning for all 5 parameters by explaining their purposes (e.g., 'Filter tweets from specific user (without @)', 'Filter by hashtag (without #)'), including default values and constraints for 'limit'. This provides clear semantic context beyond the bare schema, though it doesn't cover all possible edge cases or interactions between parameters.
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 action ('Search Twitter/X for tweets') and resource ('tweets matching criteria'), distinguishing it from sibling tools like 'get_twitter_user_tweets' or 'search_twitter_advanced' by focusing on general search functionality. It uses precise language that immediately conveys the tool's function without ambiguity.
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 implies usage context through the parameter explanations (e.g., 'Filter tweets from specific user'), but it doesn't explicitly state when to use this tool versus alternatives like 'search_twitter_advanced'. It provides clear filtering criteria but lacks explicit guidance on tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 tool retrieves profile information but does not specify whether this is a read-only operation, if it requires authentication, rate limits, error handling, or what the output format looks like (e.g., JSON structure). This leaves significant gaps for an AI agent to understand 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 front-loaded with the core purpose in the first sentence, followed by a concise 'Args' section that efficiently explains the parameter. Every sentence earns its place without redundancy, 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 (1 parameter, no nested objects) but lack of annotations and output schema, the description is partially complete. It covers the purpose and parameter well, but fails to address behavioral aspects like output format, error cases, or authentication needs, which are important for a tool interacting with an external API like Twitter/X.
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 description coverage is 0%, so the description must compensate. It provides clear semantics for the single parameter 'username,' explaining it is a Twitter username without the @ symbol and giving an example ('elonmusk'). This adds essential meaning beyond the basic schema, fully documenting the parameter.
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 purpose with a specific verb ('Get') and resource ('Twitter/X user profile information'), and distinguishes it from siblings like get_twitter_user_by_id (which uses ID instead of username) and get_twitter_user_tweets (which retrieves tweets rather than profile info).
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 implies usage context by specifying 'by username,' which helps differentiate it from get_twitter_user_by_id. However, it lacks explicit guidance on when to use this tool versus alternatives like get_twitter_user_by_id or search_twitter, and does not mention 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.

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:

[![opentwitter-mcp MCP server](https://glama.ai/mcp/servers/6551Team/opentwitter-mcp/badges/card.svg)](https://glama.ai/mcp/servers/6551Team/opentwitter-mcp)

Score Badge

Copy to your README.md:

[![opentwitter-mcp MCP server](https://glama.ai/mcp/servers/6551Team/opentwitter-mcp/badges/score.svg)](https://glama.ai/mcp/servers/6551Team/opentwitter-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/6551Team/opentwitter-mcp'

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