로컬 자격 증명이나 토큰 설정 없이 Twitter API 액세스를 제공하는 MCP(Model Context Protocol) 서버입니다. 트윗 검색, 사용자 트윗 가져오기, 트윗 게시, 트윗 답글 작성 등 핵심 Twitter 작업을 제공합니다.
https://www.youtube.com/watch?v=LOxFqCTPedc
Related MCP server: TwitterAPI MCP Server
헤드리스 및 원격 작업 : 이 서버는 브라우저나 로컬 파일 접근 없이 원격 환경에서 완전히 헤드리스로 실행될 수 있습니다.
분리된 아키텍처 : 모든 클라이언트가 OAuth 흐름을 독립적으로 완료한 다음 자격 증명을 컨텍스트로 이 MCP 서버에 전달하여 자격 증명 저장소와 서버 구현이 완전히 분리됩니다.
집중 기능 : 트윗 검색, 사용자 트윗 받기, 트윗 게시, 트윗 답글 등 핵심적인 Twitter 작업을 제공합니다.
Docker 지원 : 컨테이너화를 염두에 두고 설계되어 환경에 구애받지 않고 한 번의 클릭으로 완벽하게 격리된 설정이 가능합니다.
안정적인 종속성 : Twitter API 통합을 위한 표준 Python 요청 라이브러리를 기반으로 구축되었습니다.
Twitter API를 사용하여 트윗 검색
특정 사용자의 최근 트윗 가져오기
특정 사용자의 최근 답변 가져오기
새로운 트윗을 게시하세요
기존 트윗에 답장하기
액세스 토큰을 별도로 새로 고침
자동 새로 고침 토큰 처리
Python 3.10 이상
Twitter API 자격 증명(클라이언트 ID, 클라이언트 비밀, 액세스 토큰 및 새로 고침 토큰)
지엑스피1
# Build the Docker image
docker build -t mcp-twitter-noauth .Claude 구성에 다음을 추가하여 Docker 이미지를 사용하도록 Claude Desktop을 구성할 수 있습니다.
{
"mcpServers": {
"twitter": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"buryhuang/mcp-twitter-noauth:latest"
]
}
}
}참고: 이 구성을 사용하면 도구 사용 섹션에 설명된 대로 도구 호출 시 Twitter API 자격 증명을 제공해야 합니다. 자격 증명 저장소와 서버 구현을 분리하기 위해 Twitter 자격 증명은 환경 변수로 전달되지 않습니다.
여러 플랫폼에 Docker 이미지를 게시하려면 docker buildx 명령을 사용할 수 있습니다. 다음 단계를 따르세요.
새로운 빌더 인스턴스를 만듭니다 (아직 만들지 않았다면):
docker buildx create --use여러 플랫폼에 대한 이미지를 빌드하고 푸시합니다 .
docker buildx build --platform linux/amd64,linux/arm64,linux/arm/v7 -t buryhuang/mcp-twitter-noauth:latest --push .지정된 플랫폼에서 이미지를 사용할 수 있는지 확인하세요 .
docker buildx imagetools inspect buryhuang/mcp-twitter-noauth:latest이 서버는 MCP 도구를 통해 트위터 기능을 제공합니다. 전용 토큰 갱신 도구를 사용하면 인증 처리가 간소화됩니다.
mcp-server-twitter-noauthClaude와 같은 MCP 클라이언트를 사용하는 경우 인증을 처리하는 두 가지 주요 방법이 있습니다.
액세스 토큰과 새로 고침 토큰이 모두 있는 경우:
{
"twitter_access_token": "your_access_token",
"twitter_refresh_token": "your_refresh_token",
"twitter_client_id": "your_client_id",
"twitter_client_secret": "your_client_secret"
}액세스 토큰이 만료된 경우 새로 고침 토큰만으로 새로 고칠 수 있습니다.
{
"twitter_refresh_token": "your_refresh_token",
"twitter_client_id": "your_client_id",
"twitter_client_secret": "your_client_secret"
}이렇게 하면 새로운 액세스 토큰과 만료 시간이 반환되며, 이를 후속 호출에 사용할 수 있습니다.
Twitter API를 사용하여 트윗을 검색하세요:
{
"twitter_access_token": "your_access_token",
"query": "your search query",
"max_results": 10
}응답에는 텍스트, 생성 시간, 작성자 정보 등의 트윗 데이터가 포함됩니다.
특정 사용자의 최근 트윗을 가져옵니다.
{
"twitter_access_token": "your_access_token",
"user_id": "twitter_user_id",
"max_results": 10
}특정 사용자의 최근 답변 가져오기:
{
"twitter_access_token": "your_access_token",
"user_id": "twitter_user_id",
"max_results": 10
}새로운 트윗을 게시하세요:
{
"twitter_access_token": "your_access_token",
"text": "This is a test tweet from the MCP Twitter server"
}기존 트윗에 답장하기:
{
"twitter_access_token": "your_access_token",
"tweet_id": "id_of_tweet_to_reply_to",
"text": "This is a reply to the original tweet"
}다음 중 하나를 사용하여 twitter_refresh_token 도구를 호출하여 시작하세요.
전체 자격 증명(액세스 토큰, 새로 고침 토큰, 클라이언트 ID 및 클라이언트 비밀번호) 또는
액세스 토큰이 만료된 경우 새로 고침 토큰, 클라이언트 ID 및 클라이언트 비밀번호만 있으면 됩니다.
반환된 새 액세스 토큰을 후속 API 호출에 사용합니다.
토큰 만료를 나타내는 응답을 받으면 twitter_refresh_token 도구를 다시 호출하여 새로운 토큰을 받으세요.
이 접근 방식은 모든 작업에 대해 클라이언트 자격 증명을 요구하지 않고도 대부분의 API 호출을 간소화하는 동시에 필요할 때 토큰 새로 고침을 활성화합니다.
필요한 Twitter API 자격 증명을 얻으려면 다음 단계를 따르세요.
Twitter 개발자 포털 로 이동
새로운 프로젝트와 앱을 만듭니다
OAuth 2.0 인증 설정
앱에 대한 OAuth 설정을 구성하세요
클라이언트 ID와 클라이언트 비밀번호를 생성합니다.
액세스 토큰과 새로 고침 토큰을 얻으려면 OAuth 흐름을 완료하세요.
이 서버는 토큰 자동 갱신을 구현합니다. 액세스 토큰이 만료되면 서버는 갱신 토큰, 클라이언트 ID, 클라이언트 비밀번호를 사용하여 사용자 개입 없이 새 액세스 토큰을 얻습니다.
이 서버는 Twitter API 자격 증명에 직접 액세스해야 합니다. 토큰과 자격 증명은 항상 안전하게 보관하고 신뢰할 수 없는 사람과 공유하지 마세요.
자세한 내용은 LICENSE 파일을 참조하세요.
Get recent replies by a specific user
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | Maximum number of tweets to return (default: 10) | |
| twitter_access_token | Yes | Twitter OAuth2 access token | |
| user_id | No | Twitter user ID (optional if username is provided) | |
| username | No | Twitter username/handle (optional if user_id is provided) |
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 ('Get recent replies') but lacks details on rate limits, authentication requirements (beyond the required parameter), pagination, error handling, or what 'recent' means (e.g., time frame). This leaves significant gaps for an AI agent to understand how to use it effectively.
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's front-loaded with the core action and resource, making it highly efficient and easy to parse. Every word earns its place by conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (fetching user replies from an API), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like rate limits or authentication needs, nor does it hint at the return format (e.g., tweet objects, error responses). This leaves the AI agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all four parameters thoroughly. The description doesn't add any meaning beyond what the schema provides (e.g., it doesn't clarify the relationship between 'user_id' and 'username' or explain 'recent' in context of 'max_results'). Baseline 3 is appropriate when the schema does the heavy lifting.
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 'Get recent replies by a specific user' clearly states the verb ('Get') and resource ('replies by a specific user'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'twitter_get_user_tweets' or 'twitter_reply_to_tweet' beyond the 'replies' keyword, which is why it doesn't reach a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'twitter_get_user_tweets' (which might fetch all tweets including replies) or 'twitter_search_tweets' (which could search for replies), nor does it specify any prerequisites or exclusions beyond what's implied by the parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent tweets by a specific user
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | Maximum number of tweets to return (default: 10) | |
| twitter_access_token | Yes | Twitter OAuth2 access token | |
| user_id | No | Twitter user ID (optional if username is provided) | |
| username | No | Twitter username/handle (optional if user_id is provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It doesn't disclose rate limits, pagination, error handling, or what 'recent' means (e.g., time range). The mention of 'recent' is vague and lacks operational details.
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 zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It lacks details on authentication requirements (beyond schema), return format, error cases, and behavioral constraints like rate limits, leaving significant gaps for an AI 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?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying user-specific retrieval, which is already clear from the tool name and schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 'Get' and resource 'recent tweets by a specific user', making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'twitter_get_user_replies' or 'twitter_search_tweets', which would require more specificity about scope or filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'twitter_get_user_replies' for replies or 'twitter_search_tweets' for broader searches, nor does it specify prerequisites beyond the implied authentication.
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
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The tweet text content | |
| twitter_access_token | Yes | Twitter OAuth2 access token |
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. 'Post a new tweet' implies a write operation, but it doesn't disclose critical traits such as rate limits, authentication requirements (beyond what's in the schema), potential side effects (e.g., tweet visibility), or error handling. The description is minimal and lacks necessary context for safe and effective use.
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 'Post a new tweet' is extremely concise—a single, front-loaded sentence with zero wasted words. It efficiently communicates the core action without unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a write operation (posting a tweet) with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication needs, rate limits, or what the tool returns (e.g., tweet ID or success status). For a mutation tool, this leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('text' and 'twitter_access_token'). The description adds no additional meaning beyond what the schema provides, such as format details or constraints. Baseline score of 3 is appropriate since the schema does the heavy lifting.
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 'Post a new tweet' clearly states the action (post) and resource (tweet), making the purpose immediately understandable. It distinguishes from siblings like 'twitter_reply_to_tweet' by specifying a new tweet rather than a reply, though it doesn't explicitly contrast with other siblings like 'twitter_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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing authentication via twitter_access_token), exclusions, or comparisons to siblings like 'twitter_reply_to_tweet' for replying or 'twitter_get_user_tweets' for reading. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refresh the access token using the refresh token and client credentials
| Name | Required | Description | Default |
|---|---|---|---|
| twitter_access_token | No | Twitter OAuth2 access token (optional if expired) | |
| twitter_client_id | Yes | Twitter OAuth2 client ID for token refresh | |
| twitter_client_secret | No | Twitter OAuth2 client secret (required only for confidential clients) | |
| twitter_refresh_token | Yes | Twitter OAuth2 refresh token |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions using 'refresh token and client credentials' but doesn't disclose behavioral traits like whether this invalidates old tokens, requires specific permissions, has rate limits, or what the output looks like (no output schema). For a security-sensitive tool, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Refresh the access token') without unnecessary words. Every part earns its place by specifying the method and resources used.
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 complexity of OAuth2 token refresh, no annotations, and no output schema, the description is incomplete. It lacks details on authentication flow, error handling, or return values, leaving significant gaps for the agent to operate safely and 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 description coverage is 100%, so parameters are well-documented in the schema. The description adds minimal value beyond the schema by implying the purpose of refresh but doesn't provide additional context like parameter interactions or edge cases. Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('Refresh') and the resource ('access token'), specifying it uses 'refresh token and client credentials'. It distinguishes from siblings like posting or searching tweets by focusing on authentication renewal. However, it doesn't explicitly contrast with other auth-related tools (none listed), 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.
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 is provided. The description implies it's for refreshing tokens but doesn't specify prerequisites (e.g., when access token expires), exclusions, or how it relates to initial authentication. With no annotations, this leaves the agent guessing about context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reply to an existing tweet
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The reply text content | |
| tweet_id | Yes | ID of the tweet to reply to | |
| twitter_access_token | Yes | Twitter OAuth2 access token |
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. While 'Reply to' implies a write/mutation operation, the description doesn't disclose critical behavioral traits such as authentication requirements (implied by the access token parameter but not stated), rate limits, whether replies are public/private, or what happens on success/failure. For a mutation tool with zero annotation coverage, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence ('Reply to an existing tweet') that efficiently conveys the core purpose. It's front-loaded with no wasted words, making it easy to parse quickly. Every word earns its place, though this conciseness comes at the cost of completeness.
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 complexity of a social media write operation with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., success confirmation, reply ID, error details), behavioral aspects like rate limits or permissions, or how it differs from sibling tools. For a 3-parameter mutation tool, this minimal description leaves too many gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. The schema has 100% description coverage with clear explanations for 'text', 'tweet_id', and 'twitter_access_token'. Since schema coverage is high (>80%), the baseline score is 3, as the description doesn't compensate with additional context like format examples or constraints.
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 ('Reply to') and the resource ('an existing tweet'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'twitter_post_tweet' (which presumably posts original tweets) or 'twitter_get_user_replies' (which retrieves replies). The description is specific but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'twitter_reply_to_tweet' over 'twitter_post_tweet' for posting content, nor does it indicate prerequisites like needing an access token or a valid tweet ID. There's no explicit when/when-not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for tweets using the Twitter API
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | Maximum number of tweets to return (default: 10) | |
| query | Yes | The search query to execute | |
| twitter_access_token | Yes | Twitter OAuth2 access token |
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 mentions using the Twitter API but fails to describe key traits: whether it's read-only or has side effects, rate limits, authentication requirements (implied by the twitter_access_token parameter but not explained), or what the search returns (e.g., format, pagination). This is inadequate for a tool with no annotation coverage.
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, making it appropriately concise. However, it's front-loaded with only basic information and lacks structure for more complex details, which slightly limits its effectiveness given the tool's functionality.
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 complexity of a search tool with no annotations and no output schema, the description is incomplete. It doesn't explain return values, error handling, or behavioral nuances like rate limiting. With siblings present, it also fails to provide contextual differentiation, leaving significant gaps for an AI agent to understand full usage.
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%, so the schema already documents all three parameters (max_results, query, twitter_access_token) with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as query syntax examples or token usage details, resulting in a baseline score of 3.
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 'Search for tweets using the Twitter API' states the basic action (search) and resource (tweets), but it's vague about scope and differentiation. It doesn't specify what kind of search (e.g., public, recent, filtered) or how it differs from sibling tools like twitter_get_user_tweets or twitter_get_user_replies, which also retrieve 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention context (e.g., for general searches vs. user-specific queries), prerequisites like authentication, or exclusions. With siblings like twitter_get_user_tweets for user timelines, the lack of differentiation leaves usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0twitter_get_user_repliestwitter_get_user_tweetstwitter_post_tweettwitter_refresh_tokentwitter_reply_to_tweettwitter_search_tweetsScored across 6 tools
Each tool has a clearly distinct purpose: getting user replies vs. tweets, posting vs. replying, searching, and token refresh. No overlap exists that would cause misselection, as the descriptions specify unique actions and targets.
All tools follow a consistent 'twitter_verb_noun' pattern with snake_case, such as twitter_get_user_replies and twitter_post_tweet. This predictability makes it easy for agents to understand and select tools based on naming conventions.
With 6 tools, the count is reasonable for a Twitter API server, covering core actions like posting, replying, searching, and user data retrieval. It might be slightly under-scoped for a full Twitter client (e.g., missing likes or retweets), but it's well-balanced for basic operations.
The toolset covers key Twitter interactions: reading (user tweets/replies, search), writing (post, reply), and authentication (token refresh). Minor gaps exist, such as no tools for liking, retweeting, or deleting tweets, but agents can handle core workflows effectively with the provided tools.
Official MCP server for twitterapis.com. Read and write Twitter/X: search, users, tweets, DMs.
Official twitterapi.io hosted MCP: Twitter/X tweets, users, followers, trends. OAuth or API key.
Twitter/X read-only MCP server — 12 tools: search, users, tweets, followers, timelines, trends.
FastMCP server for posting formatted content to X (Twitter) — Tollbooth-monetized, DPYC-native
