twitterapi-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool maps to a distinct resource and action: user lookup by username/ID, tweet fetching by user/ID/search/replies, follower/following lists, and auth/write. No two tools overlap in purpose.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern (get_, search_, login_, create_). The naming convention is uniform and predictable across the entire set.
Tool Count5/5
With 11 tools, the set is well-scoped for a Twitter API server covering basic reads, search, and a minimal write path. Each tool has a clear purpose and the count fits comfortably in the ideal range.
Completeness3/5
The read side is well covered (user, tweets, followers, search), and create_tweet provides a write entry point. However, there are notable missing operations such as delete/update tweet, follow/unfollow, or like/retweet, leaving the write surface incomplete.
Average 3.3/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals nothing about pagination, rate limits, authentication requirements, ordering, or behavior for invalid usernames. For a tool with no annotation coverage, this is a meaningful gap, though the read-only nature is at least implied by 'get'.
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?
One clean sentence with zero wasted words, front-loading the core action. Slightly under-specified given the complete absence of annotations, but as concisness goes, it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, more burden falls on the description. It lacks pagination expectations, auth context, and the critical contrast with get_user_following. An agent could call it, but might fetch the wrong direction or be surprised by truncation at the default count.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both username and count are documented with descriptions, including default and max for count. The tool description adds no parameter-level meaning, but per the rubric a baseline of 3 applies when the schema covers parameters thoroughly.
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?
'Get followers of a specific user' states a specific verb (get), resource (followers), and scope (of a specific user). It distinguishes well from get_user_tweets, get_user_by_username, and get_user_by_id, and the direction is clear from the name vs. get_user_following, though the description itself doesn't explicitly call out that sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. It doesn't clarify the relationship to get_user_following (incoming vs. outgoing connections), nor when search_users might be preferable. An agent must infer usage entirely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the action ('Get users') without mentioning ordering, pagination behavior, rate limits, authorization requirements, or whether the response contains full user objects. The description adds no behavioral detail beyond the tool's basic purpose.
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, direct sentence with no wasted words. It is not padded, but it is very brief; this makes it concise rather than appropriately detailed for more complex use cases, so a slight deduction from the top is warranted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description does not explain what the returned data looks like or how pagination via 'count' behaves. It also fails to distinguish itself from get_user_followers, making the overall context incomplete for an agent deciding whether this tool fits the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both 'username' and 'count' already described in the schema. The description does not add any additional meaning about parameters, so the baseline of 3 is appropriate—the schema does the heavy lifting and the description is not required to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action ('Get') and a clear resource ('users that a specific user is following'), so an agent can understand the basic operation. However, it does not explicitly differentiate from the sibling tool get_user_followers, relying on the tool name to disambiguate the direction of the relationship.
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 given on when to choose this tool over alternatives. The sibling list includes get_user_followers, and the description does not mention that get_user_following is for the 'following' direction while get_user_followers is for the reverse, leaving selection partially to inference.
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. 'Search for tweets using keywords' only states the basic operation. It does not disclose authentication requirements, rate limits, result ordering, pagination, or whether default result_type applies. The operation is likely read-only, but this is implied rather than stated, and no additional behavioral traits are revealed.
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 concise sentence that directly conveys the action and resource. It is front-loaded and contains no filler. While it is somewhat sparse, it earns its place as an efficient high-level summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description provides little beyond the core action. It fails to mention return value expectations, pagination, default result_type behavior, or usage context versus sibling tools. The schema covers parameters, but the overall contextual picture is incomplete for an agent deciding whether and how to invoke this 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 100%, so the baseline is 3. The description's phrase 'using keywords' adds no new meaning beyond the query parameter description already in the schema. It does not elaborate on count or result_type, but the schema fully documents them, so no deduction is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Search for tweets using keywords.' It clearly says what the tool does and is distinguishable from siblings like search_users and get_user_tweets by the resource and keyword-based approach. However, it does not explicitly differentiate from alternatives, 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?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention siblings such as search_users, get_user_tweets, or get_tweet_by_id, nor does it give any exclusions or prerequisites. The only implicit cue is 'using keywords,' which suggests keyword-based search, but no clear context or when-not-to-use advice is 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?
No annotations are provided, and the description gives no behavioral details such as authentication requirements, rate limits, pagination, or the shape of returned data. 'Search' implies read-only behavior, but that is not explicitly disclosed, leaving the full burden on the description unfulfilled.
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 concise sentence with no wasted words. However, it is so brief that it borders on restating the tool name, which slightly limits its value even though it is structurally clean.
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 schema fully documents parameters, but there is no output schema and no description of what a 'user' result contains or how this tool fits among the exact-lookup siblings. For a low-complexity tool this is adequate yet leaves noticeable gaps in selection and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'query' and 'count' already described in the schema. The tool description adds no additional meaning about parameters, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search') and resource ('Twitter users'), making the core action clear. It distinguishes itself from search_tweets by targeting users rather than tweets, but does not explicitly contrast with get_user_by_username or get_user_by_id for exact lookups.
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 given for when to use this tool versus sibling tools like get_user_by_username, get_user_by_id, or search_tweets. The agent must infer from the name that this is query-based search, which is not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral disclosure burden. It indicates a read operation with no side effects, but it does not mention authentication requirements, behavior for nonexistent or private tweets, rate limits, or response shape. This is a significant gap for a tool that may require context the schema cannot provide.
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 filler. It is concise and easy to parse, though it borders on restating the tool name rather than adding substantial new information.
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 one-parameter, single-purpose read tool, the description is minimally adequate for knowing what to call and with what argument. However, it omits useful contextual details such as authentication expectations, error cases, and when to prefer a sibling tool like search_tweets. Given the simplicity, this is a moderate gap.
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 already provides full coverage of the single parameter with a clear description ('Twitter tweet ID'). The tool description adds no parameter semantics beyond restating 'by its ID', so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation (get), the resource (tweet), and the selection mechanism (by ID). It is specific enough to be distinguished from search or user-based tweet-listing siblings, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by its ID' implies the tool should be used when the caller already knows the tweet ID, but it does not explicitly state when not to use it or mention sibling tools as alternatives. Usage context is clear but underdeveloped.
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 behavioral burden. 'Get' implies a read operation, but the description discloses no additional behavior such as authentication needs, pagination, rate limits, ordering, or what exactly constitutes a reply.
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, focused sentence with no filler and the primary operation front-loaded. It is appropriately concise, though it could have included slightly more context without becoming bloated.
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 two-parameter read tool, this is minimally adequate for selecting the tool. However, with no annotations and no output schema, it leaves unspecified aspects like return format, ordering, pagination, and whether authentication is required, so it is not fully 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 100%, with both tweet_id and count already documented clearly, including count's default and maximum values. The description adds no extra parameter meaning beyond what the schema provides, so the schema-covered baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb-resource pair ('Get replies' + 'specific tweet') and is easily distinguishable from user-level or search endpoints. It does not explicitly name a sibling alternative like get_tweet_by_id, so it stops 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to a specific tweet' implies usage when a tweet_id is already known, giving some contextual signal. However, it provides no explicit guidance about when not to use this tool or how it differs from alternatives such as get_tweet_by_id or search_tweets.
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 bears the full burden of behavioral disclosure. It only states the core action and does not mention ordering, rate limits, authentication requirements, or return format.
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 short sentence with no redundant information. It is front-loaded and efficiently communicates the tool's 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?
For a simple two-parameter tool, the schema covers parameter details and the description covers the core purpose. Though no output schema exists, the return is evident from the name and description, and no critical invocation details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already documented including defaults, constraints, and format. The description adds no semantic value beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (get) and resource (tweets from a specific user), making the tool's function immediately understandable. It implies a user-scoped scope that distinguishes it from siblings like search_tweets, though it doesn't name alternatives explicitly.
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 like search_tweets or get_user_by_username. The intended context is only implied by the description, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get', implying a read operation, but does not mention authentication requirements, rate limits, not-found behavior, private-account handling, or what fields are returned.
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 with no filler. It front-loads the action and the resource, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter read tool, and the purpose is clear, but there is no output schema and no behavioral detail about response format or error conditions. The description is minimally viable but leaves an agent uncertain about what the result will look like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the schema already documents that username is required and should be submitted without '@'. The description adds no additional parameter meaning beyond what the schema provides, which matches the baseline for high 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 ('Get') with a clear resource ('Twitter user information') and a specific retrieval method ('by username'). It is immediately distinguishable from the sibling get_user_by_id, so an agent can understand what this tool does without opening the schema.
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 given about when to prefer this tool over get_user_by_id or search_users. The description implies it should be used when a username is available, but it never states this explicitly or mentions any exclusions or alternative conditions.
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 disclose side effects and behavior, but it only says 'for write actions.' It does not explain whether login creates a session, returns an auth token, verifies credentials, or persists state, leaving important authentication-flow behavior opaque.
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 one short sentence with no filler. The core purpose is front-loaded, and the credential requirement is included without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotation coverage, so the description should explain what happens after login, such as session/token behavior or expected return values. It does neither, which is a material gap for a stateful authentication 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 100%, and the schema already documents both parameters as 'Twitter password' and 'Twitter username or email.' The description merely restates that credentials are required, adding no new semantic detail, so the baseline score of 3 is appropriate.
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 ('Login') and resource ('Twitter account'), and scopes the operation to 'write actions'. This clearly distinguishes it from all sibling read/search tools and from create_tweet, making its 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 explicitly says the tool is needed for write actions, giving the agent a clear precondition for using it before mutating operations. It does not explicitly name alternative tools or say when not to use it, but the write-action framing is sufficient context.
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 behavioral disclosure burden. It does state the authentication requirement and that a new tweet is created, but it does not mention side effects such as publishing the tweet publicly, rate limits, or failure/return behavior. This is a moderate disclosure, not a glaring omission.
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 front-loaded sentence contains the action, target resource, and the key precondition. There is no filler or redundancy, and 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?
For a simple two-parameter create operation with a fully described schema, the description is nearly complete: it covers the action and login prerequisite. It could mention what a successful response looks like, but the absence of an output schema and simple mutation semantics make this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the schema already documents text (max 280) and reply_to (tweet ID, optional). The description adds no parameter detail, but none is needed because the schema handles it fully, so the baseline of 3 applies.
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 names a specific action ('Create') and resource ('a new tweet'), making the tool's function unambiguous. It also notes the login precondition and is clearly distinct from the sibling read/search tools, including login_user.
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 only usage guidance is the parenthetical '(requires login)', which implies the agent should authenticate first but does not explicitly name login_user or state when not to use this tool. The intended use is strongly implied by the name and purpose, but no explicit when/when-not guidance is provided.
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 must carry the behavioral burden, and it does convey that this is a read-only retrieval operation. However, it does not disclose authentication requirements, rate limiting, or behavior for non-existent or private users, which are relevant gaps for a live API tool. The core behavior is clear, but the description is thin on consequences and edge cases.
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 with no filler or repetition. The verb, resource, and lookup key are all present and front-loaded, so an agent can parse the definition quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool the description is adequate, but it leaves out what information is returned, whether authentication is needed, and what happens for unknown IDs. Since there is no output schema and no annotations, this missing context is not supplied elsewhere, so the description is only minimally 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 100%: the user_id parameter is already documented as 'Twitter user ID'. The tool description simply repeats this notion ('by user ID') without adding format details, whether the ID is a numeric string, or how it relates to the returned user record. Baseline 3 applies because the schema handles the parameter documentation.
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 a specific verb ('Get'), resource ('Twitter user information'), and lookup key ('by user ID'), which clearly distinguishes it from siblings like get_user_by_username, get_user_tweets, and get_tweet_by_id. The combination of resource and identifier leaves no ambiguity about what this tool retrieves.
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 'by user ID' gives a clear context for when this tool applies: when the caller has the user ID rather than a username or tweet ID. It does not explicitly name alternatives or state when not to use it, but the ID-based lookup condition is enough to route an agent correctly among the listed siblings.
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:

[![twitterapi-mcp MCP server](https://glama.ai/mcp/servers/kinhunt/twitterapi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kinhunt/twitterapi-mcp)

Score Badge

Copy to your README.md:

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

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