Allows publishing and searching notes on Xiaohongshu (小红书), including login with QR code, posting图文 notes with title, content, images, and tags, and searching feeds.
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., "@xhs-mcp-light 发一篇小红书：标题'周末探店'，内容'咖啡店'，图片1.jpg"
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.
一个文件。四个工具。让你的 AI 直接发小红书。
中文 MCP 生态最轻量的小红书发布工具 — 200 行代码，不依赖重型框架，Claude / Cursor / Copilot 直接操控小红书。
一个 单文件（server.py）的 Model Context Protocol (MCP) Server，让你的 AI 助手直接发小红书：
✅ 扫码一次，长期免登（Chrome profile 持久化）
✅ 发布图文笔记：标题 + 正文 + 多图（最多 9 张）+ 话题标签
✅ 搜索笔记
✅ 检查登录状态
竞品对比：
xhs-mcp-light (本项目) | luyike221/xiaohongshu-mcp-python | |
文件数 | 1 | ~10,000 |
子项目 | 0 | 6 |
核心依赖 | 4 | 30+ |
安装到跑通 | 3 分钟 | 30 分钟+ |
MCP 传输 | stdio（Claude Code 原生） | HTTP（需额外起服务） |
Related MCP server: xiaohongshu-skill
# 安装 uv（如果没有）
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"
# 克隆项目
git clone https://github.com/luyike221/xhs-mcp-light.git
cd xhs-mcp-light
# 安装依赖（3 个包）
uv sync
# 安装 Chromium 浏览器（首次，约 150MB）
uv run playwright install chromium在 Claude Code 设置文件（~/.claude/settings.json）中添加：
{
"mcpServers": {
"xhs-publisher": {
"command": "uv",
"args": ["run", "python", "server.py"],
"cwd": "D:/Claudecoda学习/xhs-mcp-light"
}
}
}其他 AI 工具（Cursor、Copilot、Codex）的配置见 MCP 官方文档。
重启 Claude Code，然后说：
"帮我登录小红书"
Claude 会调用 xhs_login → 弹出浏览器窗口 → 用小红书 App 扫码 → 完成。一次扫码，永久有效。
"帮我发一篇小红书：标题'我的 AI 帮我发了这篇笔记'，内容写……，图片用桌面上的 test.jpg"
工具 | 说明 | 必填参数 |
| 打开浏览器扫码登录 | 无 |
| 检查登录状态 | 无 |
| 发布图文笔记 |
|
| 搜索笔记 |
|
"发一篇小红书：标题'成都周末探店'，正文分享一家藏在巷子里的咖啡馆，图片用桌面的 cafe1.jpg、cafe2.jpg，标签加 成都探店、咖啡馆、周末去哪"
Claude 自动翻译成工具调用，完成发布。
xhs_publish_note(
title="成都周末探店",
content="藏在巷子里的惊喜...",
images=["C:/Users/xxx/Desktop/cafe1.jpg", "C:/Users/xxx/Desktop/cafe2.jpg"],
tags=["成都探店", "咖啡馆", "周末去哪"]
)Claude Code ──MCP stdio──▶ server.py ──Playwright──▶ Chrome ──▶ 小红书网页版
│
登录态保存在
xhs-browser-data/不碰小红书 API（不逆向、不抓包）——模拟真人操作浏览器
Playwright persistent context 保存 Chrome profile——一次扫码，长期免登
stdio 传输——不需要起 HTTP 服务，Claude Code 直接启动子进程
xhs-mcp-light/
├── server.py # 全部代码（233 行）
├── pyproject.toml # 依赖声明
├── .env.example # 配置模板
├── xhs-browser-data/ # Chrome profile（自动生成，含登录态）
├── assets/ # 图片资源
└── README.mdQ: 会被封号吗？ A: 本项目模拟真人浏览器操作（有 UI 交互、有随机延迟），发布频率正常就不会。禁止用于批量灌水、刷量、违规营销。
Q: 支持视频吗？ A: V1.0 图文优先。视频、定时发布、草稿箱管理在 Roadmap 中。
Q: Windows 图片路径怎么写？
A: 用正斜杠："C:/Users/xxx/Pictures/a.jpg"，或双反斜杠。不要用单反斜杠（JSON 会把它当转义符）。
Q: Mac / Linux 能用吗？ A: 可以。安装方式一致，路径用 Unix 格式即可。
Q: 一个账号能发多少？ A: 小红书日发上限约 10-15 篇。正常使用不受影响。
视频发布
定时发布
草稿箱管理
数据看板（阅读/点赞/评论）
多账号管理
如果这个项目对你有用，请我喝杯咖啡 ☕
企业批量发布 · 多平台适配（小红书/抖音/闲鱼/公众号）· 私有化部署 · 定制开发
📧 微信：见赞助码备注 | 📧 Email：portelamicheli636@gmail.com
已有客户案例：跨境电商批量种草、MCN 机构多账号分发、个人博主自动化运营。欢迎咨询。
如果这个项目对你有帮助，点个 ⭐ Star 让更多人看到。每个 Star 都是对中文 MCP 生态的一票。
Made with ❤️ by MangoOS × 第三自习室 · 2026
检查当前登录状态。 返回 logged_in=True 表示可以发布笔记。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the return value but does not mention if the tool has side effects (likely read-only) or other behavioral traits. The description is accurate but lacks extra context.
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, very concise, and front-loaded with the main 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?
Given the tool's simplicity (no parameters, one return field mentioned), the description is mostly complete. Output schema exists which may provide additional detail, but the description covers the key point. Slight room to mention logged_in=False implications.
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, baseline is 4. The description adds meaning beyond the input schema by interpreting the return value (logged_in=True means can publish), which is helpful for the agent.
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 checks login status and relates it to publishing notes. It distinguishes from sibling tools like xhs_login (for logging in) and xhs_publish_note (for publishing).
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 the tool should be used before publishing notes by stating that logged_in=True means publish is possible. However, it does not explicitly state when to use or not use alternatives.
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 |
|---|---|---|---|
| headless | No | 是否无头模式。登录必须为 false（需要扫码） |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behaviors: opens browser window, requires QR code scanning, persists login state to local storage. It does not cover failure scenarios but provides sufficient transparency for a login 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?
Three sentences, no unnecessary words. First sentence states the core action, second clarifies when to use, third explains behavior persistence. 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?
Given existence of output schema (not shown but present), the description covers all essential aspects: purpose, first-time usage, persistence, and parameter constraint. No gaps for a simple login 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?
Schema description coverage is 100% (headless parameter explained in input schema). The main description adds no extra meaning beyond the parameter's own description, so baseline score of 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 the tool opens browser window, scans QR code to log in to Xiaohongshu. It distinguishes from sibling tools (check_login, publish_note, search_feeds) by focusing on the login action. The phrase '首次使用必须调用' adds specificity.
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?
Explicitly mentions '首次使用必须调用' (must be called on first use) and that after login, state is saved locally so subsequent calls are unnecessary. The parameter description adds constraint that headless must be false for login. However, no exclusions or alternative tools are mentioned.
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 |
|---|---|---|---|
| tags | No | 话题标签，如 ["美食", "旅行", "摄影"]。自动去掉 # 号。默认无标签 | |
| title | Yes | 标题，最多20个中文字符（超出自动截断） | |
| images | Yes | 图片路径列表。本地绝对路径或 HTTP URL，最多9张 Windows 示例: ["C:/Users/xxx/Pictures/a.jpg", "C:/Users/xxx/Pictures/b.png"] | |
| content | Yes | 正文内容（纯文本，不含 # 标签） |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only says 'publish a note', omitting side effects, authentication needs, rate limits, or error conditions. The parameter descriptions cover input rules but not runtime behavior.
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, short sentence with no filler. It is appropriately concise and front-loaded with the core action.
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 having an output schema and fully described parameters, the description lacks context on authentication, error responses, or typical usage flow. For a mutation tool, this is insufficient for an agent to use it reliably.
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 detailed parameter descriptions (e.g., title truncation, image examples). The tool description itself adds no extra parameter semantics, meeting but not exceeding 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 clearly states the action '发布' (publish) and the resource '小红书图文笔记' (Xiaohongshu graphic-text note). It distinguishes itself from sibling tools which are about login and search, not publishing.
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 usage guidance is provided. The description does not mention when to use this tool, prerequisites (e.g., being logged in), or alternatives among siblings. Agents have no context for appropriate invocation.
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 |
|---|---|---|---|
| keyword | Yes | 搜索关键词 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full load. It only mentions 'brief information' but does not disclose authentication needs, rate limits, error behavior, or response structure beyond the summary. Given the presence of a login sibling, requiring authentication is likely but unstated.
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, front-loaded with the action and resource. It contains no superfluous words, though it could include more detail 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?
Given the tool has only one parameter and an output schema exists, the description is minimal. It does not mention prerequisites (e.g., login), the nature of 'brief information', or how results are paginated/structured, leaving gaps in completeness.
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 description for the only parameter 'keyword'. The tool description adds no extra meaning beyond what the schema already provides, so a baseline 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 tool searches for Xiaohongshu notes with a verb 'search' and resource 'notes', and adds 'brief information' to indicate the output scope. It distinguishes from sibling tools which are login and publish functions.
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 or any prerequisites (e.g., login required). The sibling tools are functionally distinct, but the description lacks explicit usage context.
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. Dates show when Glama detected each change.
v1.0.0xhs_check_loginxhs_loginxhs_publish_notexhs_search_feedsEach tool serves a distinct purpose: checking login status, logging in, publishing a note, and searching feeds. There is no overlap; even login and check_login are clearly separated by action.
All tools use the 'xhs_' prefix and snake_case, with a verb_noun pattern for most (check_login, publish_note, search_feeds). The odd one out is 'xhs_login', which is a single verb, but the pattern is still clear and consistent.
With 4 tools, the set is compact and well-scoped for a lightweight server focused on core operations: authentication, publication, and search. Each tool earns its place without unnecessary bloat.
The set covers login, publish, and search, but lacks tools for managing published notes (e.g., update, delete, list) or handling media uploads. For a 'light' server, it's acceptable but has notable gaps for a full note lifecycle.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Hailuo (MiniMax) AI video generation
MCP server for Qwen Image 3 AI image generation
MCP server: AI-agent access to Chinese social & trend signals — Douyin, Weibo, Xiaohongshu/RedNote,
MCP server for AI dialogue using various LLM models via AceDataCloud
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tomerose/xhs-mcp-light'
If you have feedback or need assistance with the MCP directory API, please join our Discord server