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., "@X-MCP search for tweets about open source"
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.
一个基于 Node.js 的 X/Twitter MCP Server，提供用户资料查询、推文搜索、推文详情获取、单条媒体下载、批量媒体下载等能力。
当前工具集：
x_get_user_profile
x_get_tweets
x_search_tweets
x_get_tweet_detail
x_download_media
x_download_all_media
通过 X Web GraphQL 接口获取用户资料和时间线
支持按关键词搜索推文
支持下载推文中的图片、视频、GIF
支持本地批量下载 /media 时间线中的媒体
兼容 stdio 方式挂载到 MCP Host
Related MCP server: x-mcp
Node.js 20+
npm 10+
可访问 x.com
一个可用的 X 登录态 Cookie
建议环境：
Node.js 22 LTS
如本机访问 X 需要代理，配置 HTTP_PROXY / HTTPS_PROXY
src/: TypeScript 源码
dist/: 构建产物
downloads/: 下载的媒体文件
cookies.txt: Netscape 格式 Cookie 文件
.env.example: 环境变量示例
注意：
downloads/
cookies.txt
cookies.txt.bak-*
.env
这些文件都已经加入 .gitignore，不会上传到远端仓库。
npm install项目支持两种方式提供登录态，优先级如下：
环境变量 X_COOKIE
项目根目录下的 cookies.txt
复制示例文件：
cp .env.example .env把浏览器里的 Cookie 粘进去：
X_COOKIE=auth_token=xxx; ct0=xxx; ...cookies.txt把浏览器导出的 Netscape Cookie 文件保存为项目根目录的 cookies.txt。
代码会自动读取：
auth_token
ct0
这两个字段缺一不可。
支持的环境变量如下：
X_COOKIE=auth_token=xxx; ct0=xxx; ...
X_BEARER_TOKEN=
DOWNLOAD_DIR=./downloads
HTTP_TIMEOUT=30000
REQUEST_DELAY=2000
DEBUG=true
HTTP_PROXY=http://127.0.0.1:7897
HTTPS_PROXY=http://127.0.0.1:7897
NODE_USE_ENV_PROXY=1说明：
X_COOKIE: 必填，除非你使用 cookies.txt
X_BEARER_TOKEN: 可选，当前默认走 X Web 接口
DOWNLOAD_DIR: 下载目录，默认 ./downloads
HTTP_TIMEOUT: 请求超时，毫秒
REQUEST_DELAY: 拉取时间线时的请求间隔
DEBUG: 打开调试日志
HTTP_PROXY / HTTPS_PROXY: 访问 X 所需代理
NODE_USE_ENV_PROXY=1: 让 Node fetch 使用代理环境变量
直接以 TypeScript 运行：
npm run dev等价命令：
npx tsx src/index.ts启动成功后会在标准错误输出看到：
X Scraper MCP Server 已启动 (stdio 模式)构建：
npm run build构建后用 Node 启动：
npm run start等价命令：
node dist/index.js注意：
这是 stdio MCP Server，不会监听 HTTP 端口
正常用法是由 MCP Host 拉起该进程
npm install
npm run build确认构建产物存在：
ls dist/index.js常见路径：
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\\Claude\\claude_desktop_config.json
如果文件不存在，可以手动创建。
把下面这段加入 claude_desktop_config.json：
{
"mcpServers": {
"x-mcp": {
"command": "node",
"args": [
"/absolute/path/to/x-mcp/dist/index.js"
],
"env": {
"X_COOKIE": "auth_token=xxx; ct0=xxx; ...",
"HTTP_PROXY": "http://127.0.0.1:7897",
"HTTPS_PROXY": "http://127.0.0.1:7897",
"NODE_USE_ENV_PROXY": "1"
}
}
}
}说明：
command 建议直接用 node
args 指向本项目的 dist/index.js
如果你不想把 Cookie 放进配置文件，可以删除 X_COOKIE，改为在项目根目录放 cookies.txt
如果本机访问 x.com 需要代理，把 HTTP_PROXY / HTTPS_PROXY / NODE_USE_ENV_PROXY 一起带上
重启后，Claude Desktop 会自动拉起这个本地 MCP Server。
如果接入正常，终端手动运行时会看到：
X Scraper MCP Server 已启动 (stdio 模式)Codex 这边用的是 ~/.codex/config.toml。
npm install
npm run build打开：
~/.codex/config.toml加入下面这段：
[mcp_servers.x-mcp]
command = "node"
args = ["/absolute/path/to/x-mcp/dist/index.js"]
[mcp_servers.x-mcp.env]
X_COOKIE = "auth_token=xxx; ct0=xxx; ..."
HTTP_PROXY = "http://127.0.0.1:7897"
HTTPS_PROXY = "http://127.0.0.1:7897"
NODE_USE_ENV_PROXY = "1"如果你的 Node 版本支持 --use-env-proxy，也可以把 args 改成：
args = ["--use-env-proxy", "/absolute/path/to/x-mcp/dist/index.js"]如果你不想在配置文件里写 Cookie，也可以删掉 X_COOKIE，改为在项目根目录提供 cookies.txt。
如果本机 codex 命令可用，也可以直接执行：
codex mcp add x-mcp -- node /absolute/path/to/x-mcp/dist/index.js执行完后，再去 ~/.codex/config.toml 里补环境变量。
重启后新的会话里就能看到 x-mcp 工具。
如果 Claude 或 Codex 挂载后不可用，优先检查：
是否先执行了 npm run build
dist/index.js 路径是否写对
X_COOKIE 或 cookies.txt 是否有效
本机是否需要代理访问 x.com
是否重启了 Claude Desktop 或 Codex
安装依赖：
npm install开发模式启动：
npm run dev构建：
npm run build生产启动：
npm run start下载某账号 /media 时间线前 50 个媒体文件：
npx tsx src/download-user-media.ts example_user 50检查 /media 时间线分页结构：
npx tsx src/inspect-user-media.ts example_userx_get_user_profile获取用户资料。
参数：
username: 用户名，不带 @
x_get_tweets获取用户最新推文。
参数：
username
count
include_retweets
x_search_tweets搜索推文。
参数：
query
count
x_get_tweet_detail获取单条推文详情。
参数：
tweet_url
x_download_media下载单条推文中的媒体。
参数：
tweet_url
media_type: all / photo / video / gif
x_download_all_media扫描最近若干条推文并下载其中媒体。
参数：
username
count
media_type
HTTP 404: Query not foundX Web GraphQL 的 queryId 会变化。当前实现已经加入动态发现机制，但如果再次失效，需要重新检查前端 bundle 中的最新操作 ID。
检查：
MCP Host 配置里的 command / args 是否正确
dist/index.js 是否存在
是否先执行了 npm run build
启动命令是否能在终端单独运行
检查：
Cookie 是否有效
本机代理是否可访问 x.com
是否设置了 HTTP_PROXY / HTTPS_PROXY
ct0 和 auth_token 是否都存在
手工启动：
npm run dev如果需要代理：
HTTP_PROXY=http://127.0.0.1:7897 \
HTTPS_PROXY=http://127.0.0.1:7897 \
NODE_USE_ENV_PROXY=1 \
npm run dev推荐远端：
git remote add origin https://github.com/mhqamx/X-MCP.git如果已存在远端则更新：
git remote set-url origin https://github.com/mhqamx/X-MCP.git批量下载某博主最新推文中的所有图片和视频
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | 扫描最近多少条推文，默认50 | |
| username | Yes | 用户名（不含@） | |
| media_type | No | 下载类型 | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description must disclose behavior. It states 'batch download' but does not explain whether this is destructive, whether it requires authentication, what happens if no media is found, or how results are returned. The description provides minimal transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the core action. However, it could be slightly expanded to mention key parameters or scope without becoming 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?
For a tool with 3 parameters, no output schema, and no annotations, the description is insufficient. It does not explain the batch size (default 50), the media type filter, or the output format. A user cannot fully understand the tool's behavior from the description alone.
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?
All three parameters are documented in the input schema with descriptions and defaults. The description adds no additional meaning beyond what the schema already provides. Baseline score of 3 is appropriate since the schema covers the parameters adequately.
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's purpose: batch download all images and videos from a blogger's latest tweets. It uses a specific verb ('批量下载' batch download) and resource ('博主最新推文中的所有图片和视频' all images and videos from blogger's latest tweets). This distinguishes it from sibling tools like x_download_media (single media) and x_get_tweets (text only).
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. For example, it does not mention that x_download_media should be used for a single tweet's media, or that x_get_tweets is for text. The description lacks any context about prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
下载指定推文中的图片和视频到本地
| Name | Required | Description | Default |
|---|---|---|---|
| tweet_url | Yes | 推文链接，如 https://x.com/user/status/123456 | |
| media_type | No | 下载类型: "all"全部, "photo"仅图片, "video"仅视频, "gif"仅动图 | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states basic action; does not disclose file handling, overwrite behavior, auth needs, rate limits, or what happens if media is missing.
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 accurately conveys the tool's purpose with zero wasted words. Efficient and 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?
No output schema and minimal description; fails to explain return values, errors, or side effects. For a download tool, more detail on output (e.g., file paths, success/failure) is needed.
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 adequate descriptions for both parameters. Description adds no additional meaning beyond the schema; 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?
Description clearly states download of images/videos from a specified tweet to local (verb+resource+target). However, it does not explicitly differentiate from sibling x_download_all_media, which might handle bulk downloads.
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 like x_download_all_media or x_get_tweet_detail. Lacks context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取单条推文的详细信息，包括完整文本、媒体链接、互动数据
| Name | Required | Description | Default |
|---|---|---|---|
| tweet_url | Yes | 推文链接，如 https://x.com/user/status/123456 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not explicitly state that it is a read-only operation or any security/rate-limit details. However, it adds some detail about content (text, media, interactions).
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, concise, front-loaded with purpose. 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?
Tool has one param, no output schema, no annotations. Description covers main purpose but '互动数据' (interaction data) is vague; could specify metrics. Mostly complete for low complexity.
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 the single parameter tweet_url having a description. The tool description does not add additional meaning beyond 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?
Description clearly states verb '获取' (get) and resource '单条推文的详细信息' (detailed info of a single tweet). It distinguishes from siblings like x_get_tweets (multiple tweets) and x_get_user_profile (user profile).
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 vs alternatives. Context implies it's for a single tweet, but no when-not-to-use or alternative names given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取指定用户的最新推文列表
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | 获取数量，默认20 | |
| username | Yes | 用户名（不含@） | |
| include_retweets | No | 是否包含转推 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'get latest tweets' which implies read-only but does not state it explicitly. No disclosure of rate limits, authentication, or potential side effects. The description carries the full burden here and falls short.
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 conveying the core purpose with no redundancy or extra words. Efficiently 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?
For a simple read tool with three fully described parameters and no output schema, the description is minimally adequate. It lacks behavioral details like return format or pagination, but given the simplicity, it does not severely hinder 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?
Schema coverage is 100% with each parameter described. The tool description adds no extra 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 it retrieves the latest tweets for a specified user, using a specific verb and resource. It distinguishes from siblings like detail, profile, and search tools, though not explicitly. The purpose is unambiguous.
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. The intended use is implied by the purpose, but there is no mention of when not to use it or which sibling tool is preferred for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取 X 平台用户的基本信息（头像、简介、粉丝数等）
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | 用户名（不含@），如 example_user |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only gives high-level output examples, omitting auth requirements, rate limits, error handling, or read-only nature. Lacks detail for a mutation-free read 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 sentence that is front-loaded with the core purpose. It is concise and free of filler, though it could benefit from slight structuring (e.g., list of fields).
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 (single parameter, no output schema), the description is adequate but lacks completeness regarding return value details and edge cases like private accounts.
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 a clear parameter description. The tool description adds no additional parameter semantics beyond the schema, so baseline 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 'get' and resource 'user profile', and lists example data fields (avatar, bio, follower count). It distinguishes from sibling tools focused on tweets and media.
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 implies usage for retrieving user profile data, but provides no explicit guidance on when to use versus alternatives like x_get_tweets or x_search_tweets. No exclusions or context for non-existent users.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按关键词搜索推文，支持 X 高级搜索语法
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | 结果数量，默认20 | |
| query | Yes | 搜索关键词，支持高级语法如 "from:example_user keyword"、"min_faves:1000" 等 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It only states search capability without mentioning side effects, authentication needs, rate limits, or whether results are read-only. This is insufficient for safe invocation.
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 that immediately conveys the tool's purpose, with no wasted words. It is optimally concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return values (e.g., format, pagination). It does not, making it incomplete for an agent to fully understand the tool's behavior, though schema coverage compensates partially.
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% with both parameters described. The description adds little beyond the schema, which already provides examples and defaults. 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 action (search) and resource (tweets), and mentions support for advanced search syntax. However, it does not explicitly distinguish from the sibling tool x_get_tweets, which may serve a similar purpose.
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. The description lacks when-not-to-use scenarios or prerequisites, leaving the agent without contextual decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct action: user profile, tweet listing, tweet detail, search, media download from user, and media download from tweet. No overlap in functionality.
All tools follow the consistent 'x_' prefix and snake_case verb_noun pattern (e.g., x_get_tweets, x_download_media), making them predictable.
Six tools is well-scoped for a social media read/media-download server – not too few nor too many.
Covers core read operations (profile, tweets, search, tweet detail) and media download, but lacks write operations like posting, liking, or retweeting, which are common in such APIs.
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.
FastMCP server for posting formatted content to X (Twitter) — Tollbooth-monetized, DPYC-native
The official MCP Server for the Mux API
Search, label, and manage your X (Twitter) bookmarks from any MCP client via Tweetsmash
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mhqamx/X-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
