Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Twitter Api45 MCP Server Show me the latest tweets from elonmusk"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
用于访问 Twitter Api45 API 的 MCP 服务器。
EMCP 是一个强大的 MCP 服务器管理平台，让您无需手动配置即可快速使用各种 MCP 服务器！
🌐 访问 EMCP 平台
📝 注册并登录账号
🎯 进入 MCP 广场，浏览所有可用的 MCP 服务器
🔍 搜索或找到本服务器（bach-twitter_api45）
🎉 点击 "安装 MCP" 按钮
✅ 完成！即可在您的应用中使用
✨ 零配置：无需手动编辑配置文件
🎨 可视化管理：图形界面轻松管理所有 MCP 服务器
🔐 安全可靠：统一管理 API 密钥和认证信息
🚀 一键安装：MCP 广场提供丰富的服务器选择
📊 使用统计：实时查看服务调用情况
立即访问 EMCP 平台 开始您的 MCP 之旅！
Related MCP server: X(Twitter) V2 MCP Server
这是一个 MCP 服务器，用于访问 Twitter Api45 API。
PyPI 包名: bach-twitter_api45
版本: 1.0.0
传输协议: stdio
pip install bach-twitter_api45pip install -e .# 运行（uvx 会自动安装并运行）
uvx --from bach-twitter_api45 bach_twitter_api45
# 或指定版本
uvx --from bach-twitter_api45@latest bach_twitter_api45python server.py# 安装
pip install bach-twitter_api45
# 运行（命令名使用下划线）
bach_twitter_api45此 API 需要认证。请设置环境变量:
export API_KEY="your_api_key_here"变量名 | 说明 | 必需 |
| API 密钥 | 是 |
| 不适用 | 否 |
| 不适用 | 否 |
编辑 Cursor MCP 配置文件 ~/.cursor/mcp.json:
{
"mcpServers": {
"bach-twitter_api45": {
"command": "uvx",
"args": ["--from", "bach-twitter_api45", "bach_twitter_api45"],
"env": {
"API_KEY": "your_api_key_here"
}
}
}
}编辑 Claude Desktop 配置文件 claude_desktop_config.json:
{
"mcpServers": {
"bach-twitter_api45": {
"command": "uvx",
"args": ["--from", "bach-twitter_api45", "bach_twitter_api45"],
"env": {
"API_KEY": "your_api_key_here"
}
}
}
}此服务器提供以下工具:
user_liveChecks if user is broadcasting something right now or not.
端点: GET /broadcast.php
参数:
rest_id (string) 必需: Example value: 44196397
about_profileReturns the information about the profile's registration and usage
端点: GET /about.php
参数:
screenname (string) 必需: Example value: elonmusk
community_membersGets the list of community members.
端点: GET /community_members.php
参数:
community_id (string) 必需: Example value: 1506779564160258059
cursor (string): Example value:
jobs_searchSearch for the jobs on x.com/jobs
端点: GET /jobs.php
参数:
query (string) 必需: Example value: developer
communities_posts_search_latestSearch for the Latest posts in communities
端点: GET /search_communities_latest.php
参数:
query (string) 必需: Example value: superman
cursor (string): Example value:
communities_posts_search_topSearch for the posts in communities post order top.
端点: GET /search_communities_top.php
参数:
query (string) 必需: Example value: superman
cursor (string): Example value:
communities_searchSearch for the communities on the X
端点: GET /search_communities.php
参数:
query (string) 必需: Example value: superman
cursor (string): Example value:
followersGet latest user's followers list
端点: GET /followers.php
参数:
screenname (string) 必需: Example value: elonmusk
cursor (string): Example value:
blue_verified (string): Example value:
user_infoUsing this method you can get information about user by the screenname.
端点: GET /screenname.php
参数:
screenname (string) 必需: Example value: elonmusk
rest_id (string): Twitter user's id. This parameter overwrites screenname parameter.
users_mediaHelps to get a user's media
端点: GET /usermedia.php
参数:
screenname (string) 必需: Example value: elonmusk
rest_id (string): Example value:
cursor (string): Example value:
profiles_by_restidsReturns an array of users by their rest_ids.
端点: GET /screennames.php
参数:
rest_ids (string) 必需: Example value: 44196397,34743251
user_timelineThis endpoint gets lates user's tweets by it's screenname.
端点: GET /timeline.php
参数:
screenname (string) 必需: Example value: elonmusk
rest_id (string): Optional parameter that overwrites the screename. Screename could be a random string if this user id is passed.
cursor (string): Example value:
comunity_postsReturns the posts from the community.
端点: GET /community_timeline.php
参数:
community_id (string) 必需: Example value: 1783990533192651232
cursor (string): Example value:
ranking (string): Example value:
list_followersGet the followers of the list on Twitter / X
端点: GET /list_followers.php
参数:
list_id (string) 必需: Example value: 1177128103228989440
cursor (string): Example value:
list_membersGet the members of the list on Twitter / X
端点: GET /list_members.php
参数:
list_id (string) 必需: Example value: 1177128103228989440
cursor (string): Example value:
list_timelineWith this endpoint you can get the timeline of the lists.
端点: GET /listtimeline.php
参数:
list_id (string) 必需: Example value: 1343798673386434560
cursor (string): Example value:
user_repliesGets user's replies of the user.
端点: GET /replies.php
参数:
screenname (string) 必需: Example value:
cursor (string): Example value:
spaces_infoGive you the basic information about the spaces.
端点: GET /spaces.php
参数:
id (string) 必需: Example value: 1yoJMwpbmaXKQ
searchWARNING: The Search endpoint is rate limited for new customers to 60 requests/minute. Please contact me if you need a higher limit. Email: alexander.xbx@gmail.com
端点: GET /search.php
参数:
query (string) 必需: Example value: cybertruck
cursor (string): Example value:
search_type (string): Example value:
latest_repliesGets the latest replies of the tweet.
端点: GET /latest_replies.php
参数:
id (string) 必需: Example value: 1738106896777699464
cursor (string): Example value:
check_followThis endpoint get latest subscriptins of the user and latest followers for the target account. And checks if user follows the needed account. WARNING: might not be suitable for big accounts or old subscriptions.
端点: GET /checkfollow.php
参数:
user (string) 必需: Example value:
follows (string) 必需: Example value:
tweet_infoWith this endpoint you can get tweet info by it's id.
端点: GET /tweet.php
参数:
id (string) 必需: Example value: 1671370010743263233
tweet_threadGets the basic tweet info and the replies to it.
端点: GET /tweet_thread.php
参数:
id (string) 必需: Example value: 1738106896777699464
cursor (string): Example value:
check_retweetThis endpoint get latest tweets of the user and checks if there is a retweet of the needed tweet. WARNING: might not be suitable for old retweets.
端点: GET /checkretweet.php
参数:
screenname (string) 必需: Example value:
tweet_id (string) 必需: Example value:
trendsPlease let me know if you need other countries in the list.
端点: GET /trends.php
参数:
country (string) 必需: Example value:
affilatesGive you the list of affilates for the corporate account.
端点: GET /affilates.php
参数:
screenname (string) 必需: Example value: x
cursor (string): Example value:
retweetsGet the list of of users who retweeted the tweet.
端点: GET /retweets.php
参数:
id (string) 必需: Example value: 1700199139470942473
cursor (string): The value of the next_cursor field in the response. Example value: HBaE2pGdj9GLqjEAAA==
followingGet the list of accounts user is following.
端点: GET /following.php
参数:
screenname (string) 必需: Example value: elonmusk
cursor (string): Example value:
rest_id (string): Example value:
传输协议: stdio
HTTP 客户端: httpx
MIT License - 详见 LICENSE 文件。
此服务器由 API-to-MCP 工具生成。
版本: 1.0.0
Returns the information about the profile's registration and usage
| Name | Required | Description | Default |
|---|---|---|---|
| screenname | Yes | Example value: elonmusk |
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.
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.
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.
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.
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.
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.
Give you the list of affilates for the corporate account.
| Name | Required | Description | Default |
|---|---|---|---|
| screenname | Yes | Example value: x | |
| cursor | No | Example value: |
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.
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.
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.
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.
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.
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.
This endpoint get latest subscriptins of the user and latest followers for the target account. And checks if user follows the needed account. WARNING: might not be suitable for big accounts or old subscriptions.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | Example value: | |
| follows | Yes | Example value: |
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.
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.
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.
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.
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.
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.
This endpoint get latest tweets of the user and checks if there is a retweet of the needed tweet. WARNING: might not be suitable for old retweets.
| Name | Required | Description | Default |
|---|---|---|---|
| screenname | Yes | Example value: | |
| tweet_id | Yes | Example value: |
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.
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.
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.
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.
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.
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.
Search for the Latest posts in communities
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Example value: superman | |
| cursor | No | Example value: |
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.
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.
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.
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.
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.
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.
Search for the posts in communities post order top.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Example value: superman | |
| cursor | No | Example value: |
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.
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.
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.
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.
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.
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.
Search for the communities on the X
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Example value: superman | |
| cursor | No | Example value: |
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.
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.
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.
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.
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.
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.
Gets the list of community members.
| Name | Required | Description | Default |
|---|---|---|---|
| community_id | Yes | Example value: 1506779564160258059 | |
| cursor | No | Example value: |
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.
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.
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.
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.
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.
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.
Returns the posts from the community.
| Name | Required | Description | Default |
|---|---|---|---|
| community_id | Yes | Example value: 1783990533192651232 | |
| cursor | No | Example value: | |
| ranking | No | Example value: |
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.
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.
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.
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.
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.
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.
Get latest user's followers list
| Name | Required | Description | Default |
|---|---|---|---|
| screenname | Yes | Example value: elonmusk | |
| cursor | No | Example value: | |
| blue_verified | No | Example value: |
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.
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.
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.
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.
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.
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.
Get the list of accounts user is following.
| Name | Required | Description | Default |
|---|---|---|---|
| screenname | Yes | Example value: elonmusk | |
| cursor | No | Example value: | |
| rest_id | No | Example value: |
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.
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.
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.
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.
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.
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.
Search for the jobs on x.com/jobs
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Example value: developer |
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.
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.
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.
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.
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.
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.
Gets the latest replies of the tweet.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Example value: 1738106896777699464 | |
| cursor | No | Example value: |
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.
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.
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.
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.
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.
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.
Get the followers of the list on Twitter / X
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | Example value: 1177128103228989440 | |
| cursor | No | Example value: |
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.
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.
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.
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.
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.
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.
Get the members of the list on Twitter / X
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | Example value: 1177128103228989440 | |
| cursor | No | Example value: |
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.
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.
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.
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.
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.
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.
With this endpoint you can get the timeline of the lists.
| Name | Required | Description | Default |
|---|---|---|---|
| list_id | Yes | Example value: 1343798673386434560 | |
| cursor | No | Example value: |
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.
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.
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.
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.
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.
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.
Returns an array of users by their rest_ids.
| Name | Required | Description | Default |
|---|---|---|---|
| rest_ids | Yes | Example value: 44196397,34743251 |
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.
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.
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.
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.
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.
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.
Get the list of of users who retweeted the tweet.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Example value: 1700199139470942473 | |
| cursor | No | The value of the next_cursor field in the response. Example value: HBaE2pGdj9GLqjEAAA== |
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.
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.
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.
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.
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.
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.
WARNING: The Search endpoint is rate limited for new customers to 60 requests/minute. Please contact me if you need a higher limit. Email: alexander.xbx@gmail.com
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Example value: cybertruck | |
| cursor | No | Example value: | |
| search_type | No | Example value: |
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.
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.
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.
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.
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.
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.
Give you the basic information about the spaces.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Example value: 1yoJMwpbmaXKQ |
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.
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.
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.
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.
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.
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.
Please let me know if you need other countries in the list.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Example value: |
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.
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.
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.
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.
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.
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.
With this endpoint you can get tweet info by it's id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Example value: 1671370010743263233 |
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.
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.
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.
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.
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.
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.
Gets the basic tweet info and the replies to it.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Example value: 1738106896777699464 | |
| cursor | No | Example value: |
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.
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.
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.
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.
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.
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.
Using this method you can get information about user by the screenname.
| Name | Required | Description | Default |
|---|---|---|---|
| screenname | Yes | Example value: elonmusk | |
| rest_id | No | Twitter user's id. This parameter overwrites screenname parameter. |
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.
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.
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.
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.
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.
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.
Checks if user is broadcasting something right now or not.
| Name | Required | Description | Default |
|---|---|---|---|
| rest_id | Yes | Example value: 44196397 |
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.
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.
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.
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.
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.
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.
Gets user's replies of the user.
| Name | Required | Description | Default |
|---|---|---|---|
| screenname | Yes | Example value: | |
| cursor | No | Example value: |
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.
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.
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.
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.
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.
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.
Helps to get a user's media
| Name | Required | Description | Default |
|---|---|---|---|
| screenname | Yes | Example value: elonmusk | |
| rest_id | No | Example value: | |
| cursor | No | Example value: |
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.
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.
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.
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.
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.
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.
This endpoint gets lates user's tweets by it's screenname.
| Name | Required | Description | Default |
|---|---|---|---|
| screenname | Yes | Example value: elonmusk | |
| rest_id | No | Optional parameter that overwrites the screename. Screename could be a random string if this user id is passed. | |
| cursor | No | Example value: |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Twitter/X read-only MCP server — 12 tools: search, users, tweets, followers, timelines, trends.
X (formerly Twitter): X (formerly Twitter) public and private data API for search, posts (Tweets).
Twitter: Access real-time Twitter/X data as soon as it's posted! With the Twitter/X AIO API, you.
FastMCP server for posting formatted content to X (Twitter) — Tollbooth-monetized, DPYC-native
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
