Twitter Api45 MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools have distinct purposes targeting different Twitter/X resources (e.g., user_info vs. tweet_info vs. communities_search), but there is some functional overlap that could cause confusion. For example, 'followers' and 'list_followers' both retrieve follower lists but for different entities, while 'check_follow' and 'check_retweet' have similar verification logic but for different actions, potentially leading to misselection if not carefully read.
Naming Consistency2/5
The naming is inconsistent with mixed conventions: some use snake_case (e.g., 'user_info', 'tweet_info'), others use camelCase (e.g., 'profiles_by_restids'), and some are verbose or unclear (e.g., 'comunity_posts' with a typo, 'communities_posts_search_latest'). There is no predictable pattern like verb_noun throughout, making it harder to navigate and understand the tool set at a glance.
Tool Count2/5
With 28 tools, the count is too high for a typical MCP server, leading to potential bloat and complexity. While Twitter/X is a broad domain, many tools could be consolidated (e.g., multiple search and retrieval functions) or omitted to streamline the interface, making it feel heavy and less user-friendly for agents.
Completeness4/5
The tool set covers a wide range of Twitter/X functionalities, including user profiles, tweets, communities, lists, searches, and media, with good CRUD-like coverage for retrieval and verification. However, there are minor gaps, such as lack of tools for creating or modifying content (e.g., posting tweets, managing lists), which limits full lifecycle operations but still supports most read and search workflows effectively.
Average 2.6/5 across 28 of 28 tools scored. Lowest: 1.4/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 is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the description discloses no behavioral traits—what data is returned (trending hashtags? topics? volumes?), error conditions, or rate limits. It mentions a 'list' of countries but doesn't explain the supported values or format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is brief (one sentence), the content is inappropriate for a tool definition—it reads as a user feedback request rather than functional documentation. The sentence does not earn its place in helping an agent understand or select the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a single-parameter tool, the description is fundamentally incomplete. It fails to explain the tool's purpose, the expected return data, or valid inputs for the country parameter. Without an output schema, the description carries the full burden of explaining what the tool produces, which it entirely neglects.
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 reported as 100%, establishing a baseline of 3. However, the description adds minimal value—only implying the country parameter filters by country without specifying format (ISO code, name, etc.). The schema's description field ('Example value: ') is effectively empty, but per rubric guidelines for high coverage, the score remains at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description completely fails to state what the tool does. It mentions requesting other countries but never indicates that this tool retrieves trending topics or what resource it operates on. The agent cannot determine the tool's function from this text alone.
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?
No guidance provided on when to use this tool versus siblings like 'search' or 'communities_posts_search_latest'. The description contains zero usage context or prerequisites.
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, yet the description discloses no behavioral traits. It fails to mention pagination behavior (despite having a 'cursor' parameter), rate limits, authentication requirements, or the structure/format of the returned replies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While brief at one sentence, the description is not well-structured. The phrase 'user's replies of the user' is redundant and confusing. The sentence fails to front-load critical distinctions or value, making it inefficient despite its brevity.
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 absence of an output schema and the presence of two parameters with empty placeholder descriptions, the description is inadequate. It omits expected return value information, pagination details, and how this tool filters results relative to the user's other content.
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 context signals indicate 100% schema description coverage (both parameters have description fields), establishing a baseline of 3. However, the description text itself adds no parameter semantics—such as explaining that 'screenname' identifies the target user or that 'cursor' is for pagination—relying entirely on the schema's placeholder 'Example value:' strings.
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 'Gets user's replies of the user' is tautological and awkwardly phrased. It implies retrieval of replies associated with a user but fails to clarify whether these are replies BY the user or TO the user, and does not differentiate from siblings like 'latest_replies' or 'user_timeline'.
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?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives such as 'user_timeline' (which gets original posts) or 'latest_replies' (which may get recent replies regardless of user), nor does it mention prerequisites like requiring a valid screenname format.
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?
Without annotations, the description carries the full burden of disclosing behavior, yet it only implies read-only access through the verb 'get' without confirming safety or idempotency. It omits critical details such as rate limits, authentication requirements, and what data format the timeline returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description wastes words with the phrase 'With this endpoint you can' rather than starting with the action verb, failing to front-load critical information. While only one sentence, the bureaucratic phrasing reduces clarity and information density.
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 absence of annotations and output schema, the description inadequately explains what the timeline contains (e.g., tweets, replies, metadata) or how pagination behaves. A timeline retrieval tool requires disclosure of return content type and volume limits, which are missing here.
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 100% description coverage, meeting the baseline threshold where the description need not duplicate parameter documentation. However, the schema descriptions only provide example values without semantic explanations, and the main description adds no clarification about what constitutes a valid list_id or cursor.
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 'timeline of the lists,' which provides a general sense of the operation but remains ambiguous about whether it returns tweets, list updates, or other content. It fails to differentiate from sibling tools such as user_timeline or list_members, leaving the agent uncertain about the specific resource being accessed.
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 like user_timeline or list_members, nor does it explain pagination strategies using the cursor parameter. There are no prerequisites or conditions mentioned that would help an agent determine proper invocation context.
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, yet the description discloses no behavioral traits. It omits whether the tool requires authentication, what happens if the Space ID is invalid/expired, rate limits, or whether the data is real-time or cached.
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, brief sentence with no redundant words. However, 'Give you' could be more professional/action-oriented (e.g., 'Retrieves'). It is appropriately front-loaded for its length.
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 output schema, the description should explain what information is returned about a Space. It fails to do so. While the tool has only one parameter, the absence of behavioral context and return value description leaves significant 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?
Schema coverage is 100%, establishing a baseline of 3. However, the description adds no clarification about what the 'id' represents (Space ID vs. other ID types) or how to obtain it. The schema description only provides an example value without semantic context.
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 identifies the target resource (Spaces) but uses vague phrasing ('basic information') and a weak verb ('Give you'). While it distinguishes from siblings (tweets, users, communities), it fails to specify what specific data is returned (metadata, participants, status, etc.).
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?
No guidance provided on when to use this tool versus alternatives like search or discovery tools. No prerequisites (e.g., valid Space ID format) or error conditions 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 the full burden of behavioral disclosure but provides none. It does not clarify that this is a read-only operation, does not explain pagination behavior (despite the cursor parameter), and omits any mention of rate limits, auth requirements, or return value structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At six words, the description is efficiently structured without waste, but it is underspecified rather than appropriately concise. Given the lack of annotations and output schema, additional sentences explaining usage and behavior would be warranted.
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?
Without an output schema or annotations, the description should explain what member data is returned and how pagination works. It lacks differentiation from similar sibling tools and provides no context about community membership semantics (e.g., public vs. private communities, moderation status).
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 100%, providing examples for both community_id and cursor. The description adds no semantic meaning beyond the schema baseline, nor does it explain the cursor's role in pagination or the expected format of the community_id beyond the example given.
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 'Gets the list of community members' is essentially a tautology that converts the tool name into a verb phrase without adding specificity. It fails to distinguish from sibling tool 'list_members' or clarify what constitutes a 'community' in this context (X/Twitter communities vs. other groupings).
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 provided on when to use this versus 'list_members' or other community-related tools. No mention of prerequisites (e.g., valid community_id format) or pagination workflow despite the cursor parameter implying pagination is required for large result sets.
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 'Returns' implies a read-only operation, the description omits critical details: what specific data constitutes 'registration and usage', whether the lookup is real-time or cached, rate limits, or error conditions (e.g., private accounts).
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 with no redundant phrases. However, extreme brevity becomes a liability given the lack of annotations and output schema—conciseness here manifests as under-specification rather than disciplined clarity.
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?
Despite having only one simple parameter, the tool lacks an output schema. The description fails to compensate by explaining what data structure is returned or what 'registration and usage' information actually includes (e.g., creation date, tweet frequency, login history), leaving significant gaps in the agent's understanding.
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 100% description coverage with the 'screenname' parameter fully documented including an example value ('elonmusk'). The description adds no parameter-specific context, but given the schema completeness, it meets the baseline expectation without penalty.
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 uses a clear verb ('Returns') and identifies the resource ('profile's registration and usage'), but 'registration and usage' remains vague (creation date? activity metrics?). Crucially, it fails to differentiate from siblings like 'user_info' or 'profiles_by_restids', leaving the agent uncertain which profile tool to select.
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 zero guidance on when to use this tool versus the 20+ sibling user/profile lookup tools available. There is no mention of prerequisites, specific use cases, or conditions where this tool is preferred over 'user_info' or 'profiles_by_restids'.
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 discloses almost nothing: no mention that cursor controls pagination, no explanation of ranking behavior, no rate limits, and no description of what the returned posts contain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is appropriately brief, but it is under-informative rather than efficiently dense. The brevity results from omission of critical details rather than disciplined editing.
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?
Inadequate for a 3-parameter tool involving pagination. Missing: differentiation from sibling search tools, explanation of cursor-based pagination, ranking options, and return structure (no output schema to compensate).
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?
While schema has 100% coverage, the descriptions are only example values ('Example value: 1783990533192651232') without semantic meaning. The description adds no context for what cursor (pagination) or ranking (sort order) actually do, leaving the agent to guess their purpose.
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?
States the basic action (returns posts) and resource (community), but lacks specificity regarding which community (requires ID) and fails to differentiate from sibling search tools like communities_posts_search_latest or communities_posts_search_top.
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?
Provides no guidance on when to use this tool versus the search alternatives (communities_posts_search_latest/top), no mention of pagination workflows, and no prerequisites (e.g., needing to obtain community_id first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully communicates the rate limiting constraint (60 req/min), which is valuable operational context. However, it omits other critical behavioral traits: whether the operation is read-only (implied but not stated), pagination behavior, or what constitutes a successful response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The three-sentence structure is front-loaded with the rate limit warning (appropriate for a WARNING label), and sentences are efficient. However, the contact email occupies space that could have been used to describe the tool's actual purpose, revealing misplaced prioritization rather than true conciseness.
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 search tool with 3 parameters and no output schema, the description is incomplete. It fails to identify the searchable resource (critical given numerous sibling search tools), explain the pagination cursor, or describe the search_type parameter's purpose. The rate limit warning alone is insufficient context for proper 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?
Schema description coverage is 100%, establishing a baseline of 3. The description adds no parameter-specific guidance beyond the schema's example values (e.g., 'cybertruck' for query). It does not clarify the expected format for cursor pagination or valid values for search_type.
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 mentions 'The Search endpoint' but fails to specify what resource is being searched (tweets, users, etc.) or how it differs from sibling search tools like communities_search or jobs_search. Given the Twitter/X context of siblings, this omission forces agents to guess the tool's scope.
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?
While the description warns about rate limits (60 requests/minute), it provides no guidance on when to select this generic search tool versus more specific alternatives like communities_posts_search_latest or jobs_search. No prerequisites or selection criteria are specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Beyond stating it's a retrieval operation ('gets'), it lacks pagination details (despite 'cursor' parameter), rate limits, result count limits, or error behavior (e.g., private accounts).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is efficient but front-loaded with filler ('This endpoint') and contains grammatical errors ('lates', 'it's' instead of 'its'). The errors reduce clarity despite brevity.
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 crowded tool ecosystem (numerous timeline/search variants), absence of output schema, and lack of annotations, the description should clarify what content is returned (tweets vs replies vs media) and pagination behavior. It does not.
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 has 100% coverage with examples and relationships (rest_id overwrites screenname). Description mentions screenname but adds no semantic context for 'cursor' (pagination) or 'rest_id' (internal ID format) beyond what's in the schema. Baseline 3 appropriate.
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?
States basic function (getting user's tweets) but contains typos ('lates', 'it's') and fails to differentiate from siblings like 'latest_replies', 'user_replies', or 'users_media'. The mention of 'endpoint' is implementation noise that doesn't help agent selection.
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?
Provides no guidance on when to use this versus the 20+ sibling tools (e.g., when to prefer this over 'latest_replies' or 'search'). Does not mention if this includes retweets, replies, or media.
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, and the description fails to disclose critical behavioral traits: it doesn't confirm this is read-only (though implied), doesn't explain the pagination mechanism suggested by the 'cursor' parameter, and doesn't describe the return format or what constitutes an 'affiliate' in this context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and appropriately brief, but 'Give you' is wordy and imprecise compared to direct action verbs. The typo 'affilates' and lack of front-loaded key constraints (like pagination) slightly reduce effectiveness.
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 only two parameters and no output schema, the description is still inadequate. It omits pagination behavior (critical given the cursor parameter), doesn't clarify the relationship between affiliates and the corporate account, and provides no indication of the data structure returned.
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?
While the schema has 100% description coverage (per context signals), the descriptions are only example values ('x', empty string) without semantic meaning. The tool description adds no parameter context, failing to explain that 'screenname' refers to the corporate account or that 'cursor' handles pagination.
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 it provides a list of affiliates (misspelled as 'affilates') for corporate accounts, distinguishing it from sibling user-centric tools like 'followers'. However, 'Give you' is a weak, informal verb that lacks precision compared to 'Returns' or 'Lists', and the typo reduces 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?
The mention of 'corporate account' hints at the specific context (corporate vs. personal accounts), but provides no explicit guidance on when to use this versus siblings like 'followers' or 'following', nor does it state prerequisites for the screenname parameter.
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 fails to indicate whether this is a read-only operation, explain pagination behavior despite the cursor parameter, or describe rate limiting. It does not disclose what search syntax is supported (exact match, partial, boolean).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded and avoids verbosity, but it is overly terse given the rich sibling context (24 tools). It fails to earn its keep regarding differentiation and leaves critical contextual gaps that require additional sentences.
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?
Despite low structural complexity (2 flat parameters), the description is incomplete because it fails to differentiate from numerous sibling tools and provides no hints about the output structure (absent output schema) or search matching logic necessary for an agent to use this tool effectively over alternatives.
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?
Per the rubric, with 100% schema description coverage, the baseline is 3. The description adds no parameter-specific context, but the schema technically documents both parameters (albeit with only example values rather than semantic descriptions). The description does not clarify the cursor's role in pagination beyond the schema's empty example.
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 identifies the verb ('Search') and resource ('communities'), but fails to specify what searchable fields are queried (names, topics, descriptions) or distinguish this tool from siblings like the general 'search' tool or 'communities_posts_search_latest' (which searches posts within communities rather than communities themselves).
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 explicit guidance is provided on when to use this tool versus alternatives like 'search' or 'communities_posts_search_latest'. The agent receives no signals about prerequisites (e.g., whether to use this before fetching community posts) or exclusion criteria.
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. While 'Gets' implies read-only access, the description fails to disclose pagination behavior (despite the cursor parameter), result limits, rate limiting, or whether deleted/restricted replies are filtered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence contains no wasted words, but given the absence of annotations and output schema, it is inappropriately sized—too minimal to convey necessary behavioral context or parameter semantics. Front-loading is moot with only four words.
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?
With no output schema and no annotations, the description should compensate by explaining return structure, pagination mechanics, and sibling differentiation. It provides none of these, leaving the agent to infer behavior solely from parameter names and examples.
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 coverage is 100%, establishing a baseline of 3. However, the description adds no semantic value beyond the schema—the schema only provides example values (not explanations) for 'id' and 'cursor', and the description doesn't clarify that 'id' is the target tweet ID or that 'cursor' controls pagination.
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 basic verb ('Gets') and resource ('latest replies of the tweet'), but fails to distinguish from sibling tools like 'user_replies' or 'tweet_thread'. It also omits scope details like how many replies are returned or what 'latest' means chronologically.
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 provided on when to use this versus 'tweet_thread' (which also returns conversation threads) or 'user_replies'. No mention of prerequisites like tweet visibility or authentication needs.
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?
Zero annotations provided, yet the description discloses no behavioral traits like error handling for deleted/private tweets, rate limiting, authentication requirements, or whether quoted tweets are expanded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence contains filler phrases ('With this endpoint you can') that delay the core verb. Contains grammar error ('it's' instead of 'its'). While brief, it wastes words on implementation details rather than value proposition.
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?
Without output schema or annotations, the description omits what 'tweet info' actually contains (text, author, media, engagement metrics). For a lookup tool with 26 siblings, this vagueness increases risk of selecting the wrong tool.
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 coverage is 100% with an example ID value provided. The description mentions 'by it's id' but adds no semantic context beyond the schema (e.g., ID format rules, where to obtain valid IDs, or case sensitivity requirements).
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?
States the basic action ('get tweet info') but uses the vague noun 'info' instead of specific data points (content, author, metrics). Fails to differentiate from siblings like 'tweet_thread' or 'retweets' which also retrieve tweet-related data by ID.
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?
Provides no guidance on when to use this versus 'tweet_thread' for conversation threads or 'retweets' for engagement data. No mention of prerequisites like tweet visibility, deleted status, or permissions.
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 offers almost none. It does not explain the cursor parameter's role in pagination, what happens when a user has no media, rate limits, or the structure of returned media objects. The only behavioral hint is 'get,' implying a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (5 words), but contains filler words ('Helps to') that could be replaced with a precise verb ('Retrieves'). While appropriately short for a simple retrieval tool, the vagueness of 'Helps to' wastes the limited space without conveying clear operational semantics.
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 presence of pagination (cursor parameter), three input parameters, and no output schema or annotations, the description is insufficient. It should acknowledge the pagination capability, clarify the relationship between screenname and rest_id, or indicate the volume/type of data returned. As written, it provides only a high-level label.
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 100% description coverage with example values provided, establishing a baseline of 3. The description adds no additional parameter context (e.g., explaining that rest_id is an alternative identifier, or that cursor is for pagination), but the schema adequately documents the parameters without needing supplementary description text.
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 identifies the general resource (user's media) and action (get), but uses weak phrasing ('Helps to get') that creates ambiguity about whether the tool performs the action or assists with it. It implicitly distinguishes from siblings like user_timeline or user_replies by specifying 'media,' but lacks specificity about what constitutes media (photos, videos, etc.).
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 provided on when to use this tool versus alternatives like user_timeline, or when to use rest_id versus screenname. The description fails to mention that screenname is required while rest_id is optional, leaving the agent to discover parameter requirements solely from the schema.
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 fails to explain what 'top' ranking is based on (engagement, likes, etc.), pagination behavior beyond the cursor parameter's existence, or whether the search is case-sensitive.
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 sentence with no filler content. While the phrasing 'post order top' is grammatically awkward, every word attempts to convey functional scope, achieving brevity without redundancy.
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 search tool with 2 parameters and no output schema or annotations, the description is insufficient. It omits expected details such as the ranking algorithm for 'top' posts, maximum result limits, and the structure of returned data.
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 100% description coverage (query and cursor both documented), establishing a baseline score of 3. The description mentions 'top' ordering, which adds semantic context to the search results, but provides no additional syntax guidance, format examples, or pagination logic beyond the schema's example values.
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 basic action (search) and resource (posts in communities) but uses awkward phrasing ('post order top') that reduces clarity. It implicitly distinguishes from the 'latest' sibling by mentioning 'top', but the non-standard grammar makes the scope ambiguous.
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 the sibling 'communities_posts_search_latest' or general search tools. The description lacks prerequisites, rate limit warnings, or criteria for 'top' ordering.
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 'get information' but does not disclose what specific user data is returned (profile fields, metadata, tweets), whether the operation is read-only, or any rate limiting concerns.
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 immediately states the tool's purpose. While appropriately brief, it sacrifices necessary detail about the tool's scope and return values.
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, output schema, and the existence of multiple sibling user-lookup tools, the description is insufficient. It fails to specify what user information is retrieved or what distinguishes this endpoint from others.
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?
With 100% schema description coverage, the schema adequately documents both parameters including the overwrite behavior. The description mentions 'by the screenname' which aligns with the required parameter but adds no additional semantic value beyond the schema.
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 user information using a screenname, providing a clear verb and resource. However, it fails to distinguish from siblings like 'about_profile' or 'profiles_by_restids', leaving ambiguity about which user lookup tool to choose.
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 'about_profile', or when to prefer 'rest_id' over 'screenname' (despite the schema noting that rest_id overwrites screenname).
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 reveals almost nothing. It does not state whether this requires authentication, what the return format contains (user objects? IDs?), how pagination behaves (cursor expiration?), or what happens if the screenname doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At only five words, the description is certainly concise and front-loaded, but it is underspecified rather than efficiently informative. For a tool supporting pagination and filtering, this brevity leaves critical gaps that force the agent to infer usage patterns.
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 three parameters (including pagination and filtering controls), no output schema, and no annotations, the description is inadequate. It omits essential operational context: the pagination workflow using 'cursor', the purpose of 'blue_verified' filtering, and the structure of returned follower data.
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?
Context signals indicate 100% schema description coverage, establishing a baseline of 3. While the schema provides example values for parameters, the description adds no semantic context—particularly failing to explain that 'cursor' is for pagination or what the 'blue_verified' filter actually does (boolean? string? filter logic?).
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 uses a clear verb ('Get') and identifies the resource ('user's followers list'), making the basic purpose understandable. However, it does not distinguish from the sibling tool 'list_followers' (which likely retrieves followers of a curated list rather than a user), and the word 'latest' is ambiguous—it could mean 'most recent followers' or 'current/up-to-date list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus siblings like 'following' (which retrieves who a user follows) or 'list_followers'. It fails to mention that the 'cursor' parameter enables pagination for large follower lists, or explain what values are expected for the 'blue_verified' filter.
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 fails to disclose pagination behavior (critical given the cursor parameter), authentication requirements, error handling for deleted tweets, or whether results are real-time vs cached. 'Get' implies read-only but lacks specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief with a single sentence, but the duplicate 'of' ('list of of') is a typo that reduces professionalism and clarity slightly. Information is front-loaded appropriately.
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 2-parameter tool with no output schema and no annotations, the description is insufficient. It omits critical context about pagination behavior implied by the cursor parameter and provides no hint about return value structure (e.g., user objects, count limits).
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?
With 100% schema description coverage, the baseline is 3. The description mentions 'the tweet' which loosely maps to the 'id' parameter, but adds no semantic context for 'cursor' (e.g., explaining pagination) or parameter relationships beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves users who retweeted a tweet using specific verb 'Get' and resource 'list of users'. However, it contains a typo ('list of of') and does not explicitly distinguish from sibling tool 'check_retweet' which likely verifies specific retweets rather than listing all.
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 provided on when to use this versus siblings (like check_retweet), pagination strategies with the cursor parameter, or rate limit considerations. The description states only what the tool does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to deliver. It doesn't mention pagination behavior (despite having a cursor parameter), rate limits, authentication requirements, or whether results are real-time. The word 'Search' implies read-only access, but safety characteristics are not explicit.
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 consists of a single, front-loaded sentence with no redundancy. While extremely brief, every word serves a purpose. However, the brevity comes at the cost of omitting necessary guidance, preventing a perfect score.
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 absence of an output schema and annotations, the description should explain return values, result structure, or pagination behavior. With only 7 words describing a 2-parameter search tool, critical context is missing that would help an agent predict outputs or handle errors.
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 100% description coverage (both parameters have example values), establishing a baseline score of 3. The description text itself adds no semantic information about the parameters—it doesn't explain that 'query' accepts keywords or that 'cursor' handles pagination. It relies entirely on the schema examples.
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 provides a clear verb ('Search') and resource ('Latest posts in communities'), and the inclusion of 'Latest' helps distinguish it from the sibling 'communities_posts_search_top'. However, it doesn't explicitly clarify the distinction from 'comunity_posts' (which likely retrieves posts without search filtering) or define what 'communities' refers to.
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 fails to mention when to prefer 'latest' over 'top' results (communities_posts_search_top), or when to use 'comunity_posts' instead. No prerequisites or contextual triggers are provided.
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 disclosure burden but reveals nothing about rate limits, authentication requirements, pagination behavior (critical given the 'cursor' parameter), or error handling (e.g., private accounts). 'Get' implies read-only but lacks explicit safety confirmation.
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?
Extremely concise at 7 words in a single sentence. While efficiently worded, it is arguably under-specified given the tool's complexity (pagination, dual ID schemes) and could benefit from an additional sentence explaining the cursor-based pagination.
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?
Incomplete for a tool with pagination capabilities and alternative lookup methods. The description omits how to handle the cursor for large result sets, what 'rest_id' represents, and how this differs from the 'followers' sibling tool. No output schema exists to compensate.
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 100%, establishing a baseline of 3. The description adds no parameter context beyond the schema, failing to explain that 'cursor' handles pagination, 'rest_id' is an alternative identifier, or that 'screenname' is the primary lookup key.
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/list) and target resource (accounts the user is following). However, it fails to distinguish from the sibling 'followers' tool (which likely retrieves the inverse relationship), a common point of confusion that should be explicitly clarified.
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 provided on when to use this versus siblings (e.g., 'followers'), no explanation of when to use 'rest_id' versus 'screenname', and no mention of pagination workflows despite the presence of a 'cursor' parameter.
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 fails to mention return format (job IDs? full listings?), pagination behavior, rate limits, or whether the search is real-time. It only specifies the target domain.
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 single sentence is front-loaded and contains no filler words. However, given the complete absence of annotations and output schema, the description is arguably too brief to stand alone as sufficient documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool, the description covers the basic operational scope but lacks necessary context about response structure and behavioral constraints that would typically be provided by annotations or an output schema.
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 has 100% coverage with the 'query' parameter example 'developer'. The description adds no semantic context about what the query accepts (keywords, company names, locations), but since the schema is fully documented, it meets the baseline without requiring compensation.
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 (search) and resource (jobs on x.com/jobs), specifying the exact platform domain. It implicitly distinguishes from the general 'search' sibling by restricting scope to X's job platform, though it doesn't explicitly contrast the two tools.
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 provided on when to use this versus the general 'search' tool or other discovery methods. No mention of prerequisites like authentication requirements or geographic limitations of X's job listings.
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. While 'Get' implies read-only safety, the description fails to disclose pagination behavior (despite the cursor parameter), rate limits, or what constitutes a valid list_id format beyond the schema example.
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?
Extremely concise single sentence with no filler words. However, it may be overly terse given the lack of output schema and annotations—additional context would be valuable rather than wasteful.
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?
With no output schema and no annotations, the description should explain return values (user objects), pagination mechanics, and distinguish list followers from list members. It provides none of this context, leaving significant 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?
Schema description coverage is 100% (both parameters have example values in the schema), establishing a baseline of 3. The description adds no parameter context, leaving the agent to infer that cursor is for pagination solely from the parameter 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 states a specific action ('Get') and resource ('followers of the list'), distinguishing it from the sibling 'followers' tool (which implies user followers) and 'list_members'. However, it could clarify that 'list' refers to Twitter/X Lists specifically.
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 provided on when to use this versus 'list_members' (members added to a list vs. users following the list), nor when to use the cursor parameter for pagination. No prerequisites or alternatives 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 the full burden of behavioral disclosure but offers almost none. It does not explain pagination behavior (how the cursor works), what data is returned (user objects vs IDs), rate limits, or error conditions. The word 'Get' implies read-only access but this is not explicitly stated.
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 single sentence is appropriately brief and front-loaded with the core action. While extremely minimal, it contains no filler or redundant text—every word serves a purpose, even if the overall description is underspecified.
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 output schema and annotations, the description should provide more context about return values, pagination mechanics, and list member semantics. For a 2-parameter tool interacting with Twitter/X's list API, the current description is insufficient for robust agent operation.
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 coverage is 100%, establishing a baseline of 3. The description adds no parameter semantics beyond the schema, which itself only provides example values rather than explanations (e.g., the 'cursor' parameter has an empty example with no explanation of its pagination 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 uses a specific verb ('Get') and resource ('members of the list'), making the basic purpose clear. However, it fails to distinguish from sibling tools like 'list_followers' or 'community_members', which could cause confusion about which tool retrieves list subscribers versus list members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'list_followers'), nor does it mention pagination requirements despite the presence of a 'cursor' parameter. No prerequisites or rate limit warnings are included.
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 offers minimal information. It does not clarify read-only status, rate limits, error handling (e.g., deleted tweets), or the structure of the returned thread data. The mention of 'basic' tweet info is vague regarding what fields are included.
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 single-sentence description is front-loaded and contains no redundant words. However, given the absence of annotations and output schema, the extreme brevity leaves significant gaps in necessary context, suggesting it is under-sized rather than optimally concise.
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?
The tool lacks both annotations and an output schema, yet the description does not compensate by explaining the return structure (how replies are organized), pagination mechanics, or differentiating from related tools. For a tool retrieving threaded conversation data, this leaves critical operational context undocumented.
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 100% description coverage (with examples), establishing a baseline score of 3. The description itself adds no parameter-specific context, such as explaining that 'id' refers to the root tweet ID or that 'cursor' is for paginating through long reply threads.
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 uses specific verbs ('Gets') and identifies the resource (basic tweet info and replies). However, it does not explicitly distinguish from the sibling tool 'tweet_info', which likely retrieves only the tweet without the reply thread, leaving some ambiguity about when to choose this tool over 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?
There is no guidance on when to use this tool versus siblings like 'tweet_info' (for single tweets) or 'user_replies' (for replies by a specific user). The description also fails to mention the pagination behavior implied by the 'cursor' parameter or prerequisites like tweet ID format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full disclosure burden. It reveals important implementation details—that it scans the user's 'latest tweets' rather than using a direct lookup— which explains the temporal limitation. However, it omits critical behavioral context: return value format (boolean vs object), error handling for private users, and rate limit implications of timeline scanning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) and front-loads the primary action, but wastes words with 'This endpoint' (redundant for MCP tools) and uses grammatically incorrect 'get' instead of 'gets'. The WARNING is appropriately placed at the end, but 'needed tweet' is imprecise terminology that reduces clarity per word.
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 lack of output schema and annotations, the description provides minimal viable context by explaining the temporal scope limitation. However, it fails to describe the return structure (what constitutes a 'found' vs 'not found' retweet), possible error states, or the practical limit of 'latest' tweets (how many days/hours back), leaving operational gaps for the agent.
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?
While the schema has 100% field coverage, the parameter descriptions are empty placeholders ('Example value: '). The description text mentions 'user' and 'needed tweet' which map to the parameters, but fails to compensate for the schema gaps by specifying formats (e.g., whether screenname includes '@', if tweet_id is numeric) or constraints, leaving parameter semantics under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a user's recent tweets to check for a specific retweet ('checks if there is a retweet of the needed tweet'). However, it uses awkward phrasing ('needed tweet' instead of 'specified tweet') and fails to explicitly distinguish its purpose from the sibling 'retweets' tool, which likely lists all retweets rather than checking a specific user's timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a negative usage constraint via the WARNING about old retweets, implying the tool shouldn't be used for historical checks. However, it lacks explicit guidance on when to prefer this over the 'retweets' sibling tool or other alternatives, and doesn't mention prerequisites like the target user's visibility settings.
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 it mentions the return type (array), it fails to disclose critical operational details such as maximum number of rest_ids allowed per call, error handling for invalid IDs, whether the operation is read-only, or rate limiting implications.
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 redundant words. It is appropriately front-loaded with the verb and return type, 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 low complexity (single string parameter) and absence of an output schema, the description adequately covers the basic return structure ('array of users'). However, it lacks completeness regarding error behaviors, batch size constraints, and the structure of user objects within the array.
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 coverage is 100% with one parameter. The description adds semantic context by confirming the parameter represents 'rest_ids' (user identifiers), which complements the schema's example value (44196397,34743251) by clarifying what the numbers represent. Baseline score appropriate for high schema coverage.
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 (Returns) and resource (array of users) and specifies the identifier type (rest_ids), which implicitly distinguishes it from sibling tools like user_info that likely use usernames. However, it does not explicitly differentiate from similar profile lookup tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as user_info or about_profile. It does not mention prerequisites, rate limits, or optimal use cases (e.g., batch lookups vs. single lookups).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Fails to clarify what 'broadcasting' means (live Spaces, video stream, etc.), what return type to expect (boolean vs object), error conditions, or rate limiting. Minimal behavioral disclosure beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 9 words with no redundancy. Front-loaded with action and target. Appropriate length for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter boolean check tool, description is minimally adequate but has gaps. No output schema exists, yet description doesn't indicate what gets returned (true/false, object with broadcast details, etc.) or define the broadcasting scope.
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 has 100% description coverage with example value. Description adds no additional parameter context, but baseline is 3 when schema coverage is high. Neither description nor schema explains what 'rest_id' represents (user ID), though the example suggests numeric string format.
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 uses specific verb 'Checks' with resource 'user broadcasting' and temporal scope 'right now'. It distinguishes from siblings like user_info or user_timeline by focusing specifically on live broadcast status, though 'broadcasting' could be more specific (e.g., Spaces vs live video).
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 provided on when to use this tool versus alternatives like spaces_info or user_info. No mention of prerequisites or conditions where this check is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It reveals important behavioral limitations (fetches 'latest' subscriptions/followers only, warns about scale issues) but omits safety profile, rate limits, and return value format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences convey mechanism, purpose, and warning without excessive verbosity, but typos ('subscriptins') and informal phrasing ('needed account') detract from professional 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?
For a simple boolean-check tool with 2 parameters and no output schema, the description covers the critical limitation (scale/timing constraints) but fails to describe what the tool returns (boolean, object, etc.).
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?
While the schema technically has 100% description coverage, the descriptions are empty placeholders ('Example value: '). The description clarifies the relationship mapping ('user' is the potential follower, 'follows' implies the target/needed account), meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool checks if a user follows a target account, distinguishing it from sibling list tools like 'followers' or 'following'. However, it contains typos ('subscriptins' for subscriptions) and slightly awkward phrasing ('get' instead of 'gets') that prevent 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a warning about unsuitable use cases ('might not be suitable for big accounts or old subscriptions'), but lacks explicit guidance on when to prefer this over siblings like 'followers' or 'following' for different use cases.
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:

[![bachai-twitter-api45 MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-twitter-api45/badges/card.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-twitter-api45)

Score Badge

Copy to your README.md:

[![bachai-twitter-api45 MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-twitter-api45/badges/score.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-twitter-api45)

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/BACH-AI-Tools/bachai-twitter-api45'

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