twikit-mcp

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool targets a distinct resource+action combination, such as get_user vs get_user_by_id vs search_users, which are clearly separated by lookup key. Opposite actions like like/unlike and retweet/undo_retweet are unambiguous, leaving no confusion about tool purpose.
Naming Consistency4/5
The set largely follows a consistent verb_noun pattern, e.g., search_users, get_tweet, post_tweet, like_tweet. Minor deviations like whoami and rate_limit_status, plus inconsistent DM naming (get_dm_history vs send_direct_message), slightly weaken the pattern but it remains readable.
Tool Count2/5
With 27 tools, the set is above the 25-tool threshold, feeling heavy and potentially overwhelming for an agent. While each tool has a purpose, the count is excessive for a focused client, and some operations could be merged or omitted.
Completeness4/5
The core Twitter workflows are well covered, including tweets, users, follows, likes, retweets, DMs, and trends. However, missing reverse operations like unbookmark_tweet and the lack of a get_user_likes method create minor dead ends for common interaction patterns.
Average 3.5/5 across 27 of 27 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- Last stable release on July 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention side effects, authentication requirements, rate limits, or failure modes (e.g., already retweeted). The only transparency is the action itself, which is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, making it concise. However, it is under-specified and could include important context without becoming verbose, so it does not earn full marks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, this description is incomplete. It omits details about the result, potential errors, or authentication, which are necessary for an agent to invoke the tool correctly and handle outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single parameter tweet_id. The phrase 'by id' adds no semantic value beyond the parameter name itself, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retweet' and identifies the resource as 'a tweet by id', clearly indicating the action. It distinguishes from sibling tools like post_tweet and undo_retweet, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It simply states the action without any context, prerequisites, or exclusions, leaving the agent to infer usage on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states what the tool does but doesn't mention return format, pagination, rate limits, or any caveats. Since the verb 'get' implies a read operation, it is minimally informative but still lacks transparency about what the returned trends contain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. It is appropriately short for a simple getter, though it could add a bit more detail without becoming verbose. Overall, it is concise and structurally sound.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is underspecified. It fails to explain what 'trends' represents or how the parameters affect output, leaving an agent uncertain about the return payload and parameter semantics. This is a simple tool, but completeness is still low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the two parameters (count and category). It mentions 'category' but not 'count', giving no hint about how count affects results or the valid enum values. The description adds little meaning beyond the schema's structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get') and resource ('trends') with a category qualifier, distinguishing it from sibling tools that focus on tweets, users, or direct messages. However, it lacks an explicit differentiator from other list-style tools, as no sibling explicitly mentions trends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool over alternatives, such as search_tweets or get_home_timeline. It neither mentions prerequisites nor excludes inappropriate contexts. The single sentence provides no contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether muting is reversible, whether the user is notified, or what effects it has on timeline visibility. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy or unnecessary words. It front-loads the verb and resource, making it efficient, though it could have used the space to add more value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter mutation tool, the description is too sparse. It omits the behavioral implications of muting, how it compares to blocking/unfollowing, and any user-facing outcomes. The absence of annotations and output schema makes this incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description merely repeats 'given user id' without adding any format, requirements, or semantics beyond the schema's string type. It does not clarify what kind of user ID is expected or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mute the account with the given user id' clearly states the action (mute) and the resource (account identified by user id). However, it does not differentiate from the sibling tool 'block_user', which is a similar action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use mute_user versus the alternative block_user or follow_user. The description only states the action without any context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any side effects of blocking a user (e.g., whether it also unfollows, impacts DMs, or requires authentication). It only states the action without explaining consequences or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly conveys the tool's purpose. It is concise and front-loaded, with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and minimal parameter documentation, the description is insufficient. It does not cover potential side effects, error conditions, or what happens after blocking, leaving the agent with incomplete information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description adds no meaning beyond the parameter name. It merely says 'the given user id,' which provides no additional detail about the format, type, or requirements of user_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Block'), the resource ('the account'), and the scope ('with the given user id'). This distinguishes it from sibling tools like follow_user, mute_user, and unfollow_user, which involve different actions on the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like mute_user or unfollow_user. There is no mention of prerequisites, context, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description offers no behavioral traits beyond the basic action. It does not mention idempotency, error conditions, required authentication, or return value. With no annotations provided, the description carries the full burden and fails to disclose any additional behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with no annotations, and the description provides only the core action. It lacks context about when to use it, side effects, or requirements. Although an output schema exists, the description is too thin to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate by explaining the parameter. It only echoes that the parameter is the user id, providing no additional meaning such as format, validation, or relationship to other resources.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Unfollow') and the target ('the account with the given user id'), using a specific verb and resource. It is easily distinguished from sibling tools like follow_user, block_user, and mute_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as follow_user or block_user. The description only states the action without any contextual usage instructions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral information. It does not disclose whether bookmarking is reversible, idempotent, or requires authentication, nor what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides only the basic action. It omits return value, side effects, and error conditions, leaving the tool insufficiently specified for an agent to invoke with full confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'by id' but adds no detail beyond the schema's tweet_id field. With 0% schema description coverage, it fails to compensate with format, validation, or additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (bookmark) and the resource (tweet), specifying the identifier. It is unambiguous and distinct from sibling tools, which handle likes, retweets, and follows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to bookmark versus like, retweet, or follow, nor any context about prerequisites. It solely states the action without exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. 'Look up' implies a read-only operation, but the description does not state what data is returned, how errors are handled (e.g., user not found), or any rate limits. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the purpose without unnecessary words or repetition. It is appropriately sized for a simple lookup operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, the description is minimally adequate. However, it lacks any mention of when to use this tool over the sibling 'get_user' and does not describe expected return behavior, which would be important for an agent to select it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only lists 'user_id' as a string, and the description adds 'numeric user id', which clarifies that although the schema type is string, the value should be numeric. This is useful semantic information, but it does not explain the format, range, or any validation beyond type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Look up') and the resource ('user profile') with a specific identifier ('numeric user id'). It is unambiguous about what the tool does, though it does not explicitly differentiate from the sibling 'get_user' tool, leaving mild ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives like 'search_users' or 'get_user'. There is no mention of prerequisites, exclusions, or context where this tool is preferred, so the usage is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the action of sending a message, adding no information about side effects, authentication requirements, rate limits, or response behavior. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and efficient, consisting of two concise sentences with no redundant information. It gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations) and the existence of sibling tools like get_dm_history, the description is too brief. It lacks usage context, behavioral expectations, and any differentiation from alternatives. The presence of an output schema partially compensates for return value explanations, but overall completeness is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to two of three parameters: it specifies that user_id is the recipient and explains reply_to as an optional message id. Although the text parameter is not described, its meaning is self-evident. Since schema coverage is 0%, this partial clarification still provides value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Send a direct message to a user id.' It uses a specific verb and resource, making the purpose clear. However, it does not explicitly distinguish this from sibling tools like get_dm_history, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or context for use. The description simply states the action without elaborating on appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the action without mentioning side effects (e.g., adds to following list), idempotency, error behavior, or authentication requirements. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or repetition. It earns its place by stating the action and the target, achieving maximum efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, but the description lacks sufficient context. It doesn't mention any prerequisites, consequences, or how to handle edge cases like already following the user. It's adequate for a basic understanding but leaves gaps that an agent would need to resolve elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for explaining the parameter. It merely says 'with the given user id,' which adds no meaning beyond the schema's 'User Id' title. No format, constraints, or examples are provided, leaving the agent to infer the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Follow') and the target resource ('the account with the given user id'), distinguishing it from sibling tools like unfollow_user, block_user, and mute_user. The verb+resource combination leaves no doubt about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply says what it does without contextualizing when it's appropriate (e.g., to start following a user) or noting any conditions like authentication or rate limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must shoulder the transparency burden. It discloses pagination behavior ('Paginated via cursor') and parameter behavior ('tweet_type selects the tab'), which are useful. However, it does not mention authentication requirements, rate limits, or what happens on invalid user_id, leaving significant behavioral aspects unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose, and includes key behavioral hints without unnecessary fluff. Every word contributes value, and the format is highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal for a tool with four parameters and no output schema. It lacks any mention of return format, error cases, or parameter interactions. While it covers the core purpose, it fails to provide a complete picture for an agent to use it reliably in varied contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains tweet_type (selects tab) and cursor (pagination), but leaves 'count' entirely unaddressed and 'user_id' only implicitly obvious. With four parameters, this partial coverage is insufficient for an agent to correctly construct calls, especially regarding count's role relative to cursor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a user's tweets') and resource ('user's tweets'), distinguishing it from sibling tools like get_user or get_user_followers. The mention of tweet_type selecting the tab adds specificity about the scope (tweets, replies, media, likes), which clarifies the tool's functionality. However, it doesn't explicitly differentiate from search_tweets, which could also return tweets, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to retrieve a user's tweets by profile tab), but it provides no explicit guidance on when not to use it or alternatives like search_tweets. The context is clear enough for selection, but lacks the direct comparative language that would elevate it to a 4 or 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic action. It does not disclose idempotency, required state (e.g., must already be retweeted), failure behavior, or return values, leaving the agent without crucial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool, the description is adequate for basic understanding but lacks behavioral and usage details that an agent needs for correct invocation, such as error cases and side effects. The absence of annotations and output schema increases the need for more descriptive context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, tweet_id, is mentioned in the description ('by tweet id'), but the description does not add detail about the expected format or source. With 0% schema coverage, this minimal clarification helps but is not substantial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Undo a retweet by tweet id' clearly states the action (undo) and resource (retweet), and specifies the input identifier. It is distinct from sibling tools like retweet and delete_tweet, as it specifically targets retweets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance or alternatives are mentioned. The context is implied by the name and action, but the description does not say when to use this versus other tools, nor does it provide prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states the action and the kind values, but doesn't mention pagination behavior (cursor), count limits, rate limits, or what the response contains. This is a minimal statement that leaves the agent without key behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately identifies the action and resource, with no filler or unnecessary detail. It is optimally concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the core purpose but omits any information about return format (no output schema), pagination with cursor, or behavioral constraints. The absence of annotations and output schema places greater responsibility on the description, which it does not fully meet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage for parameters is 0%, and the description only restates the enum values for 'kind' without explaining count or cursor. The schema itself provides defaults and types, but the description does not add practical guidance on parameter usage, such as how cursor controls pagination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the authenticated user's home timeline, with the specific kind values enumerated. This verb+resource phrasing distinguishes it from related tools like get_user_tweets or search_tweets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for the current user's home feed, but doesn't explicitly state when to prefer this over alternatives. The 'authenticated user' phrasing provides some differentiation, but no direct exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions pagination via cursor, which is useful, but it omits other behavioral aspects such as authentication requirements, rate limits, error handling, or whether the response includes only user IDs or full user objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, with the purpose stated first and the pagination detail second. Every word is purposeful, and no redundant information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description must explain the full behavior and return value. It only states that it lists accounts and is paginated, leaving gaps about what the response looks like, how count affects results, and what happens when no retweets exist. For a 3-parameter tool, this is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It implicitly explains 'tweet_id' as the given tweet, and 'cursor' as the pagination mechanism, but 'count' is not mentioned. This partial compensation earns a middle score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List accounts that retweeted the given tweet,' using a specific verb and resource. It distinguishes itself from siblings like get_favoriters (which lists liking accounts) by explicitly naming the retweet action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to retrieve retweeters for a given tweet, but it provides no explicit context on when to prefer this over similar tools like get_favoriters or search_users. There is no mention of exclusions or alternative options, though the intended use is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states the action and target, but does not mention reversibility, idempotency, error conditions (e.g., if the tweet was not liked), or authentication requirements. This is minimal beyond what the tool name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. It is perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a simple one-parameter input, the description is still too thin. It does not address what happens on failure, whether the operation is idempotent, or any side effects. An agent would need to infer too much for a complete understanding of the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, with only the parameter name 'tweet_id' and type string. The description adds 'by id', clarifying that the parameter identifies the target tweet, but it does not specify format (numeric string, URL, etc.) or constraints. Some added meaning, but limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove your like from a tweet by id' clearly states the action (remove), the resource (your like), and the target (a tweet by id). It distinguishes from siblings like like_tweet (which adds a like) and delete_tweet (which deletes the tweet itself).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this to undo a like. However, there is no explicit mention of when to use this vs alternatives such as like_tweet or delete_tweet. No exclusions or alternative guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Like (favorite)') but does not mention authentication requirements, whether liking is reversible, how duplicate likes are handled, or what kind of response to expect. This is a clear gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. Every word contributes to understanding the tool's purpose and input.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description is minimally viable but incomplete. It lacks usage guidelines, behavioral details, and any caveats or prerequisites. For a straightforward like action, this may suffice, but it does not fully prepare an agent for real-world invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter tweet_id with 0% description coverage. The description's 'by id' does connect the parameter to the tweet being liked, adding some semantic value beyond the schema's bare 'Tweet Id' title. However, it does not clarify the expected format (e.g., numeric string) or any validation requirements, so it only partially compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Like (favorite)' and clearly identifies the resource ('a tweet by id'). It distinguishes itself from sibling tools like unlike_tweet, retweet, and bookmark_tweet by naming the exact action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by id' implies when to use the tool: when a tweet ID is known and the user wants to like it. However, it provides no explicit context about when not to use it or mention alternatives such as unlike_tweet for undoing the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds value by explaining that max_id pages older messages, which is a behavioral trait not evident from the schema. However, it does not mention other behaviors like response format, ordering, or potential rate limits. The description is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose, and contains no filler. It efficiently conveys the tool's function and pagination behavior in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and no output schema. The description covers the main action and pagination, but it does not describe what the response contains (e.g., message objects, timestamps) or any limitations. Given the lack of annotations and output schema, this is a noticeable gap, but the description still provides the essential context for using the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that user_id is the user whose history is retrieved and that max_id is used for pagination to older messages. This adds meaning beyond the raw schema, though it could be more detailed about the exact format of max_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: "Get direct-message history with a user id." This is a specific verb+resource combination that distinguishes it from siblings like send_direct_message and search_users. The mention of max_id for pagination adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the primary use case: retrieving DM history for a given user. However, it does not explicitly discuss when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It is adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden. It discloses pagination via cursor, which is useful, but does not mention authentication requirements, rate limits, error behavior, or response format. This is a read-only operation, reducing risk, but the disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and immediately states pagination. No wasted words, all information is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers the core action and pagination. However, with no output schema and no annotations, it lacks details on the exact structure of returned 'accounts' (e.g., user objects vs. IDs), ordering, or error conditions, leaving reasonable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the user_id parameter ('given user id') and cursor (pagination), adding meaning. However, it omits the count parameter entirely, leaving its purpose inferable only from the schema default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists accounts following a given user id, using a specific verb and resource. It is easily distinguished from sibling tools like get_user_following (which lists who a user follows) and search_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving followers but does not explicitly state when to use this tool versus alternatives like get_user_following. Sibling tools exist but are not referenced, leaving usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses pagination behavior via cursor, which is useful, but does not disclose response format, authorization requirements, or behavior of the count parameter. This adds some transparency but not fully comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with purpose and immediately mentions pagination. No filler; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool, the description covers the core purpose and pagination, but the absence of output schema and lack of count semantics leave some ambiguity. It is adequate but not feature-complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds meaning to the cursor parameter by mentioning pagination and implies tweet_id as the target tweet. However, the count parameter is not explained at all, leaving a meaningful gap with low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource 'accounts that liked the given tweet,' which clearly differentiates it from sibling tools like get_retweeters and get_user_tweets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use (when listing likers of a tweet) but does not mention alternatives or exclusions, such as differentiating from get_retweeters for retweets. Thus it meets 'clear context, no exclusions' but not explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose one behavioral trait: pagination via cursor. However, it does not mention authentication requirements, rate limits, ordering, error cases, or return format. The pagination note adds some value beyond the schema, making it minimally transparent but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the primary purpose and adds the key pagination detail. Every word earns its place, and there is no redundancy or filler. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with 3 parameters and no output schema, the description covers the core action and pagination. However, it omits details about the 'count' parameter and the return format, which would be helpful given there is no output schema to clarify results. Still, the description is adequate for an agent to invoke the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'user_id' implicitly ('given user id') and explicitly mentions 'cursor' for pagination. However, it does not explain the 'count' parameter at all, leaving a gap. This partial coverage earns a mid-range score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and a clear resource: 'accounts the given user id follows'. This distinguishes it from sibling tools like get_user_followers, which lists followers instead. The purpose is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: to retrieve accounts a user follows. However, it does not explicitly state when to use this versus alternatives (e.g., get_user_followers) or mention any exclusions or prerequisites. No explicit guidance is given, so it relies on the agent to infer from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses that the response includes engagement counts and media, which is useful. However, it omits important details like authentication requirements, error handling, or rate limits, making it minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Fetch', and contains no unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and the presence of an output schema, the description covers the core purpose and return highlights. It lacks details on error cases or usage nuances, but it is adequate for a simple fetch-by-ID operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description should compensate. It only repeats 'by its id' without adding meaning beyond the parameter name 'tweet_id'. No format, example, or constraints are provided, leaving the parameter semantics under-explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and identifies the exact resource ('a single tweet by its id'). It also adds distinguishing details ('including engagement counts and media') that differentiate it from sibling tools like get_user_tweets or get_home_timeline, which retrieve multiple tweets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies clear usage context: use this when you have a tweet ID and need that specific tweet with engagement and media. However, it does not explicitly exclude alternatives or mention when not to use it, such as retrieving multiple tweets via get_user_tweets or search_tweets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure and does add pagination via cursor as a behavioral trait. However, it does not mention whether authentication is required, the return format, or any other side effects. The disclosure is minimal but present, warranting a mid-range score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every part is informative, and the pagination mention is a natural extension of the search functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description does not explain the return value structure or what fields are included in the results. It also leaves the count parameter behavior implicit. However, for a straightforward search with pagination, it covers the essential usage, so it's adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'query' is the search term and 'cursor' enables pagination, but it does not explain the 'count' parameter, though its name and default value give some hint. This partial compensation earns a solid 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Search' with the resource 'user accounts' and the qualifier 'matching a query', which clearly defines the tool's function and distinguishes it from sibling tools like get_user or get_user_by_id that fetch specific users. The mention of pagination via cursor adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for open-ended search by query, which clearly differentiates it from direct lookups by ID or other user-related actions. However, it does not explicitly state when not to use it or name alternative tools, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses pagination behavior and supports for X operators, which adds value. However, it does not explicitly state that it is a read-only operation or describe the response format, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, front-loaded with the core verb, and no wasted words. The mention of operators and parameters is packed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description covers the key functional aspects: search, product type, pagination, and operator support. It omits count but that is a minor detail. Overall it is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains product (enum values) and cursor (pagination), and gives a query example, but does not describe the count parameter or its default behavior. It adds meaning beyond the schema but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search tweets', a specific verb+resource pair that clearly distinguishes this tool from search_users and other tweet-related tools. It also adds extra scope by explaining product types and search operators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on how to use the tool: choosing product (Top/Latest/Media) and using X search operators, plus pagination via cursor. It does not explicitly name alternatives or exclusions, but the purpose is obvious enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. 'Delete' implies a destructive, likely irreversible action, and 'your own tweets' conveys an ownership requirement. However, it does not state irreversibility, potential errors, or permission requirements beyond ownership, which would be useful for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates everything essential about the tool. It is front-loaded with the verb and resource, and every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is adequate. It covers what the tool does and the ownership constraint. Missing details like return value or error behavior are not critical for such a straightforward delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (tweet_id) with no description, and schema description coverage is 0%. The description says 'by id', which clarifies that the tweet_id parameter is the identifier of the tweet to delete. This compensates for the schema's lack of detail, though it could specify the expected format or where to obtain the ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (one of your own tweets), and the method (by id). It distinguishes this from sibling tools like like_tweet or post_tweet by specifying ownership and deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'your own tweets' provides clear context on when to use this tool, implying it should not be used for tweets belonging to others. However, it does not explicitly mention alternatives or exclusions beyond that, though the intent is clear given the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. The verb 'look up' implies a read-only operation, but the description does not explicitly state safety, rate limits, or error behavior. It is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the main action. It is concise, with no wasted words or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, a one-line description is largely sufficient, and the output schema covers return values. The description adequately explains the input format, but lacks explicit mention of error handling or side-effect-free guarantees, which would be beneficial given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides the parameter name and type with 0% coverage, so the description must compensate. The description clarifies that screen_name takes a @handle format with an example ('jack'), adding meaningful semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up a user profile by @handle (screen name), which is a specific verb+resource combination. It distinguishes itself from sibling tools like get_user_by_id (which uses an ID) and search_users, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by specifying the identifier type (@handle/screen name) with an example, implying this is the tool to use when you have a screen name rather than an ID. However, it does not explicitly mention when to use alternative tools like get_user_by_id, stopping short of a full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral information. It discloses the reply_to mechanism and the >280 character capability with an eligibility caveat. It does not discuss rate limits, authentication, or irreversibility, but for a tweet-posting tool this is a reasonable level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and no redundant fluff. Each sentence adds distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the small parameter count and presence of an output schema, the description covers the essential functionality and optional modifiers. It could mention rate limits or post visibility, but for a simple tool it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It explains reply_to as a tweet id and is_note_tweet as enabling long-form, which is not evident from the schema. Text is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Post a tweet' as a specific verb+resource. The name and description distinguish it from siblings like delete_tweet, retweet, and send_direct_message by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for replying (reply_to) and long-form posts (is_note_tweet). Does not explicitly name alternatives or when-not-to-use, but the instructions cover the main usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It does convey that the tool returns the authenticated user's id and validates the session, but it omits potential behavioral details such as error responses on invalid sessions or rate limits. Minimal but acceptable for a simple read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's action and purpose. Every word earns its place with no redundancy or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's extreme simplicity (no parameters, no output schema, no annotations), the description fully covers what an agent needs to know: what it returns and why it might be used. There are no missing details that would affect tool selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, and the schema is empty with 100% coverage. The baseline of 4 applies since there is no parameter meaning to add beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Return') and resource ('the authenticated account's own user id'), which distinguishes it from sibling tools like get_user or get_user_by_id that target other users. It also adds the purpose of confirming session validity, making its function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'confirms the session works' provides clear context for when to use this tool (e.g., to verify authentication or retrieve the current user's id). However, it does not explicitly exclude alternatives or mention when not to use it, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool is non-consuming and auth-free, which are key behavioral traits. However, it does not describe the return format or any potential edge cases, so it is not a perfect 5. Still, it goes well beyond a bare statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs, each sentence earning its place. It states the main purpose first, followed by safety guarantees, then configuration source. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (zero parameters, no annotations, no output schema), the description provides essential context: what it does, that it is safe, and how the configuration is set. It does not spell out the exact output shape, but for a status-reporting tool this is a minor gap. Overall, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain parameter semantics. The baseline is 4 for such cases. The description adds value by referencing the related environment variables, TWIKIT_MCP_RATE_LIMIT and TWIKIT_MCP_RATE_LIMIT_PER_MINUTE, which provide context for how the reported configuration is populated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool "Report the current client-side rate-limit configuration," using a specific verb and resource. It is easily distinguishable from sibling tools, all of which perform Twitter API actions, whereas this tool reports internal rate-limiting state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes that the tool "Does not require auth and does not consume a rate-limit token," indicating it is safe to call anytime without side effects. It also mentions environmental configuration variables, but stops short of explicitly stating when to choose this over alternatives. For a status tool with no siblings, this is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bintangtimurlangit/twikit-x-mcp'

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