Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Twitter MCP search tweets about MCP servers"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Twitter/X — search tweets, post, reply, and engage via AI agents.
Built by is.team — the AI-native project management platform.
Add to your MCP config (.mcp.json for Claude Code, or Claude Desktop settings):
{
"mcpServers": {
"twitter": {
"command": "npx",
"args": ["-y", "@isteam/twitter-mcp"],
"env": {
"TWITTER_API_KEY": "your-api-key",
"TWITTER_API_SECRET": "your-api-secret",
"TWITTER_ACCESS_TOKEN": "your-access-token",
"TWITTER_ACCESS_TOKEN_SECRET": "your-access-token-secret"
}
}
}
}Related MCP server: X(Twitter) V2 MCP Server
Tool | Description |
| Search tweets by keywords, hashtags, or phrases (max 100 results) |
| Get recent mentions of the authenticated user |
| Get a user's recent tweets by username |
Tool | Description |
| Post a new tweet (max 280 characters) |
| Reply to a tweet |
| Quote tweet with your commentary |
| Delete a tweet |
| Like a tweet |
| Retweet a tweet |
| Follow a user by username |
Tool | Description |
| Get authenticated user info (followers, following, tweet count) |
| Get a specific tweet with author info and metrics |
| Look up a user by username |
| Update your profile (name, bio, url, location) |
Variable | Required | Description |
| Yes | Twitter API key (consumer key) |
| Yes | Twitter API secret (consumer secret) |
| Yes | OAuth 1.0a access token |
| Yes | OAuth 1.0a access token secret |
Go to the Twitter Developer Portal
Create a project and app
Set up OAuth 1.0a with read and write permissions
Generate your access token and secret from the "Keys and tokens" tab
Copy all four values into your MCP config
Twitter API v2 enforces per-endpoint rate limits in 15-minute windows:
Endpoint | Limit | Notes |
| 300 / 15 min | ~20/min |
| 450 / 15 min | Requires Basic tier |
| 300 / 15 min | |
| 300 / 15 min | |
| 300 / 15 min | |
| 450 / 15 min |
Idempotency note: Twitter API does not deduplicate identical tweets — posting the same text twice creates two tweets. If your agent retries on timeout, it may create duplicates. Use get_user_tweets to verify before retrying a post.
Backoff: When rate-limited, the API returns 429 Too Many Requests with a x-rate-limit-reset header (Unix timestamp). Wait until that time before retrying.
Monitor your brand:
"Search for tweets mentioning 'is.team' in the last 24 hours and show engagement metrics"
Engage with your audience:
"Check my recent mentions and reply to any questions with helpful answers"
Post an update:
"Tweet: Just shipped our new AI-powered project management feature! Check it out at is.team"
is.team is an AI-native project management platform where AI agents and humans collaborate as real teammates. AI agents join boards, create tasks, chat, and get work done — just like any other team member.
Part of the is.team open-source MCP ecosystem:
@isteam/mcp — Project management
@isteam/google-ads-mcp — Google Ads
@isteam/twitter-mcp — Twitter/X
@isteam/bluesky-mcp — Bluesky
@isteam/linkedin-mcp — LinkedIn
MIT
Delete a tweet by ID
| Name | Required | Description | Default |
|---|---|---|---|
| tweet_id | Yes | ID of the tweet to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as destructive nature, irreversibility, or authentication requirements. The minimal description gives no insight beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the action and resource, with no unnecessary words. It is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature of deletion and lack of annotations, the description is insufficient. It does not explain return behavior, error conditions, or any consequences, leaving the agent unprepared for using this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes tweet_id as 'ID of the tweet to delete'. The description adds no additional meaning beyond what the schema provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'tweet', distinguishing it from sibling tools that involve creating or reading tweets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool (e.g., only for own tweets) or any prerequisites or alternatives. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Follow a user by username
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Username to follow (without @) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states the action but does not disclose behavior on errors (user not found, already following), side effects, or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. However, it could be slightly more informative without being verbose, so not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema), the description covers the core action but lacks context on prerequisites and error scenarios, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'username' is described in the schema. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Follow') and resource ('a user'), and the parameter specification makes it distinct from sibling tools, none of which perform a follow action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or conditions for use (e.g., user existence, authentication requirements).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get info about the authenticated Twitter/X account
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The phrase 'Get info' implies a read operation with no side effects. Without annotations, the description could better disclose what data is returned, but it is clear this is an authenticated read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words, effectively communicating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, briefly mentioning the kind of info returned (e.g., user profile fields) would improve completeness. However, the description is adequate for a zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so baseline is 4. The description adds no parameter-level detail, which is acceptable as there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'info about the authenticated Twitter/X account'. This clearly distinguishes it from siblings like get_tweet and get_user which require user IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use the tool (when needing info about the authenticated account). However, it does not explicitly state when not to use it or mention alternatives like get_user, which would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent mentions of the authenticated account
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | Number of mentions to fetch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only states 'recent mentions' without clarifying rate limits, pagination behavior, or whether results are limited to the authenticated user's network. The description does not reveal if the tool is read-only or if any side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that immediately conveys the tool's purpose. It is appropriately sized for a simple tool, though it could include more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter, no output schema, and simple functionality, the description is minimally adequate. However, it lacks details on return format, limits, or auth requirements, which would improve completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for its single parameter, 'max_results', which is described with default, minimum, and maximum values. The description adds no additional meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves mentions for the authenticated account, using a specific verb and resource. It distinguishes itself from siblings like 'get_tweet' or 'get_user_tweets' by focusing on mentions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_tweets' or 'get_user_tweets'. There is no mention of preconditions, exclusions, or best practices for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific tweet by ID (author, metrics, text)
| Name | Required | Description | Default |
|---|---|---|---|
| tweet_id | Yes | Tweet ID to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose behavioral traits such as error handling, rate limits, authentication needs, or what happens if the tweet is not found. The read-only nature is assumed but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with essential information. The parenthetical example fields add clarity without unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool, the description gives basic return field hints but is incomplete: it does not mention error responses, full return structure, or authentication. Sibling tools like get_user_tweets have similar complexity, so this is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for the single parameter tweet_id. The description adds value by explicitly mentioning the return fields (author, metrics, text), which compensates for the missing output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get details of a specific tweet by ID' and lists example fields like author, metrics, text. It uses a specific verb and resource, distinguishing it from sibling tools like get_user_tweets or get_mentions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Usage is implied by the straightforward read operation, but excludes alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a Twitter user profile by username
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Twitter username (without @) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. It only states 'look up' without revealing rate limits, data freshness, error handling, or whether authentication is required beyond what is implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, simple resource (user profile), and sibling tools providing context, the description is adequate but could mention what profile fields are returned or any limitation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes 'username' as 'Twitter username (without @)'. The description adds no further parameter nuances, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Look up a Twitter user profile by username' uses a specific verb and resource, clearly distinguishing it from siblings like get_tweet (different resource) and get_me (different scope).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., search_tweets or get_user_tweets). No context about prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent tweets from a specific user by username
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Twitter username (without @) | |
| max_results | No | Number of tweets to fetch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only says 'recent tweets' without clarifying ordering, time range, rate limits, or authentication requirements. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Front-loaded with the main action. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description omits return structure, pagination, or ordering. For a simple tool, it lacks completeness on expected output and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds no extra meaning beyond what the schema already provides. Description does not elaborate on format of username or max_results behavior beyond schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get recent tweets from a specific user by username', which is a specific verb+resource and distinguishes from siblings like get_tweet (single tweet) 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_mentions or search_tweets. The description does not mention exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Like a tweet by ID
| Name | Required | Description | Default |
|---|---|---|---|
| tweet_id | Yes | ID of the tweet to like |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the basic action, omitting critical traits like idempotency, auth requirements, or effects on existing likes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It could be slightly expanded for completeness without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the description lacks important behavioral context such as whether the action is reversible or requires authentication. Partially adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% as the parameter tweet_id has a description. The tool description adds no extra meaning beyond what the schema already provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Like') and the resource ('a tweet'), clearly distinguishing it from siblings like retweet or reply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as retweet or reply_tweet, nor any context about prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a new tweet (max 280 chars)
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Tweet text (max 280 characters) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It only mentions the character limit but omits other behaviors like authentication requirements, rate limits, or irreversibility of posting. Vague 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. It could be more structured but remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite tool simplicity (1 param, no output schema), the description lacks completeness: no return value info, no safety hints, no prerequisites. An agent would benefit from more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the only parameter 'text' has a description and maxLength. The description adds minimal value ('new tweet') beyond what's already in the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Post a new tweet') and includes the constraint ('max 280 chars'). It distinctly distinguishes from sibling tools like reply_tweet and quote_tweet by focusing on original tweets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings. For example, it does not specify that this is for original tweets only, nor does it mention alternatives like reply_tweet for replies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quote tweet — add your commentary on top of another tweet
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Quote text (max 280 characters) | |
| tweet_id | Yes | ID of the tweet to quote |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states the basic action without disclosing behavioral traits like creating a new tweet, linking to the original, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence front-loads the action with no waste, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with 2 parameters and no output schema, the description is nearly complete but could mention that it creates a new tweet and includes the original.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds no additional meaning beyond what the schema already provides for text and tweet_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('quote tweet') and what it does ('add your commentary on top of another tweet'), distinguishing it from siblings like post_tweet and reply_tweet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for adding commentary to an existing tweet, but lacks explicit guidance on when to use vs alternatives (e.g., retweet with comment) or prerequisites like ensuring tweet_id exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reply to a specific tweet by its ID
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Reply text (max 280 characters) | |
| tweet_id | Yes | ID of the tweet to reply to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states the basic action, omitting side effects, auth requirements, rate limits, or reply visibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, fully front-loading the purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists and annotations are absent; the description fails to provide necessary context such as return format, side effects, or usage prerequisites for a social media mutation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters. The description adds no extra meaning beyond the schema, meeting the baseline but not exceeding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reply to a specific tweet by its ID' uses a clear verb ('Reply') and specifies the resource ('tweet'), making the action distinct from siblings like 'post_tweet' and 'quote_tweet'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives; usage is implied by the description but lacks when-not or alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retweet a tweet by ID
| Name | Required | Description | Default |
|---|---|---|---|
| tweet_id | Yes | ID of the tweet to retweet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It does not disclose behavioral traits such as rate limits, authentication requirements, what happens if the tweet is already retweeted, or side effects like creating a new tweet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. It is appropriately sized for a simple tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one parameter and no output schema, the description is minimally adequate. However, it lacks behavioral context and could benefit from clarifying that retweeting does not add a comment, especially given sibling tools like 'quote_tweet'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with 'tweet_id' described in the schema. The description adds no additional meaning beyond what the schema already provides, meeting the baseline for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'retweet' and resource 'tweet' with the qualifier 'by ID', clearly distinguishing it from sibling tools like 'like_tweet', 'quote_tweet', and 'reply_tweet'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'quote_tweet' or 'reply_tweet', nor are there any conditions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search recent tweets. Supports operators: "exact phrase", from:user, -exclude, has:links, is:reply, lang:en. Requires Basic tier.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Twitter search query. Supports operators: "exact phrase", from:user, -excludeWord, has:links, is:reply, lang:en etc. | |
| max_results | No | Number of results (10-100) | |
| next_token | No | Pagination token from previous search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It implies a read-only operation but does not disclose behaviors like rate limits, pagination details, or response format beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no extraneous information. The first sentence states the core purpose, and the second adds operator details and requirement. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacking output schema and annotations, the description is adequate but minimal. It covers the query operator support and max_results range, but omits details about pagination behavior, result ordering, or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (baseline 3). The description adds 'Basic tier' context but does not provide additional meaning about parameters beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('search') and resource ('recent tweets'), and lists supported operators. However, it does not explicitly differentiate from sibling tools like get_tweet or get_user_tweets, which would warrant a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions 'Requires Basic tier' as a prerequisite and lists operators, providing some context for use. But it lacks guidance on when not to use this tool or when to prefer alternatives (e.g., get_tweet for a single tweet).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update Twitter profile — name, bio/description, url, location (v1.1 API)
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Display name (max 50 chars) | |
| description | No | Bio/description (max 160 chars) | |
| url | No | Profile website URL | |
| location | No | Location (max 30 chars) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states 'Update' without disclosing side effects, rate limits, or confirmation of changes. Minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence front-loaded with key information; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple update tool with well-documented parameters, but lacks explanation of return value or any constraints not in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100%) with descriptions; description only restates field names and max lengths without adding new meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it updates Twitter profile fields (name, bio, url, location) with API version. Distinguishes from sibling tools that deal with tweets or follows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when updating profile fields, but no explicit when-to-use, when-not-to-use, or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: posting, replying, quoting, retweeting, liking, searching, etc. There is no overlap or ambiguity between tool functionalities.
All tools follow a consistent verb_noun pattern (e.g., delete_tweet, follow_user, get_tweet, like_tweet, post_tweet). The pattern is uniform and predictable.
14 tools is well-scoped for a Twitter client. It covers all essential interactions (posting, interacting, reading, searching) without being excessive or insufficient.
The set covers the major Twitter operations (tweet, reply, quote, retweet, like, follow, search, profile update). Minor gaps like unfollow/unlike are absent but do not severely hinder basic workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Twitter/X read-only MCP server — 12 tools: search, users, tweets, followers, timelines, trends.
Remote MCP server for The Colony — a social network for AI agents (posts, DMs, search, marketplace).
MCP server for QPost — lets AI agents publish video and image posts to YouTube, TikTok, Instagram.
MCP server for building and testing AI agents with multi-model experimentation and insights.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/isteamhq/twitter-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
