Provides tools for searching, browsing, and publishing notes on Xiaohongshu (Little Red Book), including login via QR code and checking login status.
Click on "Deploy 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., "@xiaohongshu-mcp search for hiking trails in Sichuan"
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 工具 | 说明 |
🔍 搜索笔记 |
| 搜索小红书笔记，返回标题+链接 |
📖 获取笔记 |
| 查看笔记详情、正文、评论 |
📤 发布笔记 |
| 发布图文笔记 |
🔑 扫码登录 |
| 获取二维码，手机扫码登录 |
✅ 检查登录 |
| 检查当前登录状态 |
Related MCP server: Redbook-Search-Comment-MCP2.0
# 1. 安装
pip install xhs-mcp-tool
playwright install chromium
# 2. 启动
python -m xiaohongshu_mcp.server
# 3. 配置到你的 MCP 客户端# 启动后运行：
xhs_login_qrcode() # 获取二维码 → 小红书 App 扫码
xhs_check_login() # 确认已登录docker build -t xhs-mcp .
docker run -d -p 6789:6789 -v $HOME/.xiaohongshu_mcp:/data xhs-mcp版本 | 价格 | 适用 |
🌟 个人版 | 免费 (AGPL-3.0) | 个人开发者 |
💼 商业版 | ¥499 | 单项目商用 |
🏢 企业版 | ¥2999 | 无限项目 + 优先支持 |
xiaohongshu-mcp/
├── xiaohongshu_mcp/
│ ├── __init__.py
│ ├── server.py # FastMCP 入口 + 工具定义
│ └── core.py # Playwright 控制器
├── data/ # 存储目录（cookies、二维码）
├── pyproject.toml
└── README.mdDouyin-mcp — 抖音私信 MCP
WeChat-mcp — 微信消息 MCP
如果这个项目对你有帮助，欢迎 Star 支持！
检查当前小红书登录状态
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, yet the description does not specify what the output indicates (e.g., returns a boolean or object with login state). Minimal behavioral 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?
Single, efficient sentence with no wasted words. Front-loaded and to the point.
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?
Output schema exists (not shown) so return value explanation is unnecessary, but the description lacks usage context and behavioral details, making it slightly 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?
With 0 parameters and 100% schema coverage (empty schema), the description adds no param info, but none is needed. Baseline 4 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 (check) and resource (login status), distinguishing it from sibling tools like xhs_login_qrcode.
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. Could mention to verify login before actions requiring authentication, but it's absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
评论小红书笔记
Args: url: 笔记链接 text: 评论内容
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only states the basic action, omitting details like authentication needs, side effects, or rate limits. Output schema exists but is not described.
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?
Description is very concise, with one line and an Args block. No unnecessary text, though structure could be improved (e.g., bullet points).
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 simple parameters and an output schema, the description lacks context on when to use, error handling, or requirement for login. Sibling tool xhs_check_login suggests auth is important but not mentioned here.
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 has 0% description coverage; description adds Chinese labels ('笔记链接', '评论内容') which provide basic meaning beyond property names. However, no further details like format 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?
Description clearly states the tool's action: '评论小红书笔记' (comment on Xiaohongshu note), which is a specific verb+resource. It is distinct from sibling tools like xhs_like (like) and xhs_publish (publish).
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. Does not mention prerequisites (e.g., login status) or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取小红书笔记详情及评论
Args: url: 笔记链接 (https://www.xiaohongshu.com/explore/{note_id})
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states a read operation but does not mention any side effects, auth requirements, rate limits, or error handling, leaving significant gaps for an agent.
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 short with the purpose stated first, followed by parameter details. It is efficient without unnecessary fluff, though the Args format could be slightly more streamlined.
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 presence of an output schema, the description does not need to detail return values. It adequately explains the parameter but does not mention expected output structure (e.g., that it includes both note details and comments). This is minimally sufficient but leaves some uncertainty.
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 0% description coverage, but the tool description compensates by explicitly providing the URL format and an example, adding meaning that the schema alone lacks. This helps the agent correctly construct the parameter.
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 fetches note details and comments from Xiaohongshu, using the verb '获取' (get) and specifying the resource. It is unambiguous but does not differentiate from sibling tools like xhs_search or xhs_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?
The description provides a concrete parameter example with URL format, aiding correct invocation. However, it lacks guidance on when to use this tool versus alternatives, such as when the user wants a specific note versus searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
点赞/取消点赞小红书笔记
Args: url: 笔记链接
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action without disclosing whether login is required, idempotency, or side effects. Lacks behavioral detail.
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 very short and front-loaded with the main action. It is concise, but the lack of detail on toggle behavior slightly reduces effectiveness.
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 tool with one parameter and an output schema, the description covers basic functionality. However, it lacks usage context and behavioral details, making it only 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 description coverage is 0%. The description adds '笔记链接' (note link), clarifying the parameter's purpose. However, it does not specify expected format or constraints, providing minimal added value.
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 '点赞/取消点赞' (like/unlike) and the resource '小红书笔记' (Xiaohongshu notes), distinguishing it from sibling tools like comment or publish. However, it does not explicitly clarify the toggle nature.
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. For example, it does not explain when to use like vs unlike, or prerequisites like login.
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 |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior. It only says 'get QR code', leaving unclear if it returns a URL or image, and no mention of side effects (e.g., creating a session) or rate limits.
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, 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 no parameters and an output schema exists, but the description lacks context about the login flow (e.g., that this should be followed by polling xhs_check_login). 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?
No parameters, so baseline is 4. The description adds value by clarifying the tool's purpose beyond the empty 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 the action ('get') and the resource ('Xiaohongshu login QR code'), distinguishing it from siblings like xhs_check_login which checks login status.
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., to initiate login) or that xhs_check_login should follow. No mention of prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
发布小红书图文笔记（需登录创作者平台）
Args: title: 笔记标题（不超过20字） content: 笔记正文（不超过1000字） images: 图片本地路径列表
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| content | Yes | ||
| images | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the requirement to be logged into the creator platform, which is a key behavioral constraint. There are no annotations to contradict, and the description adds context about the operation without being misleading.
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 three key sentences plus the Args section. No redundant information; every part contributes to understanding the tool.
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 description covers input parameters and a critical prerequisite. Although it does not detail return values, an output schema exists, so that is not required. It is sufficient for a standard publish 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?
Parameter descriptions add significant value beyond the schema: title must be ≤20 characters, content ≤1000 characters, and images must be local paths. This compensates for the 0% schema description 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 verb '发布' (publish) and the specific resource '小红书图文笔记' (Xiaohongshu image-text note). It distinguishes from sibling tools like xhs_comment or xhs_search, which have different purposes.
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 the prerequisite of login to the creator platform, which gives context. However, it does not provide explicit guidance on when to use this tool versus alternatives, nor does it exclude any conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索小红书笔记
Args: keyword: 搜索关键词 limit: 返回结果数量（默认10，最大30）
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the tool requires authentication, is read-only, has rate limits, or any side effects. The limit parameter's max is stated, but overall behavioral context is lacking.
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 concise (a single line plus Args list) and front-loaded with the main purpose. However, it mixes English and Chinese, and the Args section could be more structured (e.g., using bullet points). Overall, it is efficiently worded.
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 an output schema exists, return values need not be described, but the description omits important context like authentication requirements, pagination, sorting order, and error handling. For a search tool, such details are significant.
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 0%, so the description compensates by explaining 'keyword' as search term and 'limit' as result count with default and maximum. However, it adds no additional format or constraints beyond what the schema already specifies (type and default).
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 Xiaohongshu notes, which is a specific verb and resource. It distinguishes from siblings like xhs_get_note (specific note retrieval) and xhs_comment (commenting). However, it could be more explicit about the scope (e.g., full-text search vs. title search).
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 only implies usage for keyword-based search but provides no explicit guidance on when to use this tool vs. alternatives like xhs_get_note or xhs_user_profile. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取小红书用户主页信息
Args: user_id: 用户ID
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only states the basic function without disclosing behavioral traits such as authentication needs, rate limits, or data scope.
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 very short, but it could be more informative while remaining concise. It is not overly verbose but lacks substance.
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, the description lacks behavioral context, usage guidance, and parameter details, making it insufficient for a complete 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 description merely repeats the parameter name and type in an Args section, adding no meaning beyond the input schema (which has 0% 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 verb '获取' (get) and the resource '小红书用户主页信息' (Xiaohongshu user profile info), distinguishing it from sibling tools like xhs_get_note.
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, nor any prerequisites or context for usage.
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.
v0.1.0xhs_check_loginxhs_commentxhs_get_notexhs_likexhs_login_qrcodexhs_publishxhs_searchxhs_user_profileScored across 8 tools
All tools have clearly distinct purposes: login checks, QR code login, note retrieval, commenting, liking, publishing, searching, and user profile. There is no functional overlap between any two tools.
While all tools share the 'xhs_' prefix, the naming patterns vary: some are verb-only (e.g., xhs_comment, xhs_like), some verb_noun (e.g., xhs_check_login, xhs_get_note), and some noun_noun (e.g., xhs_login_qrcode, xhs_user_profile). This inconsistency may confuse agents slightly.
With 8 tools, the server covers essential operations for interacting with Xiaohongshu without being overwhelming. Each tool serves a distinct purpose and contributes to a coherent workflow.
The tool set covers core actions like login, note retrieval, commenting, liking, publishing, searching, and profile access. Minor gaps exist, such as missing update/delete operations for notes and follow/unfollow actions, but the set is functional for common tasks.
搜索笔记、浏览首页推荐、查看笔记内容与评论，并发表你的评论。直接在工作流中与小红书内容互动，高效跟进话题。
XHS hot search/suggestions、note/product search/details、PGY、comments/replies、users/posts、transcript
MCP server: AI-agent access to Chinese social & trend signals — Douyin, Weibo, Xiaohongshu/RedNote,
Connect AI to your flomo notes. Search, create, edit notes and manage tags via MCP.
