Searches Xiaohongshu for the top-liked image-text note by keyword, and extracts structured data including title, content, author, image URLs, and downloads images to local storage.
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., "@xhs_searchMcp find the top-liked Xiaohongshu note for camping gear"
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.
还在手动打开小红书、输入关键词、点开筛选、寻找高赞笔记，再一张张保存图片、复制标题和正文？
把关键词交给
xhs_searchMcp就够了。它会自动完成搜索与筛选，找到“图文 · 最多点赞”的第一篇笔记，并将标题、正文、作者、链接和图片整理成可以直接交给 AI 或程序使用的结构化数据。
xhs_searchMcp 是一个基于 TypeScript、Playwright 和 MCP 的小红书图文笔记采集工具。它既可以作为 MCP Server 被 Codex、Claude Desktop 等客户端调用，也可以作为普通命令行脚本（Cli）独立运行。
只需传入一个关键词：
露营装备xhs_searchMcp 会自动执行：
打开小红书
→ 搜索关键词
→ 打开“筛选”面板
→ 选择“图文”
→ 选择“最多点赞”
→ 打开第一篇笔记
→ 提取标题、正文、作者和图片
→ 下载图片并生成 result.json主要特性：
🔥 自动寻找指定关键词下“最多点赞”的图文笔记
📝 结构化提取标题、正文、作者和笔记链接
🖼️ 提取图片原始地址，并可自动下载到本地
🤖 提供标准 MCP 工具，可直接加入 AI 工作流
⌨️ 同时提供 CLI，无需 MCP 客户端也能使用
🔐 使用独立浏览器配置，不读取或修改日常 Chrome Cookie
🧯 操作失败时返回明确错误码并保存现场截图
Related MCP server: xiaohongshu-skill
Node.js 18.18 或更高版本（推荐 Node.js 20/22）
npm
Windows、macOS 或 Linux 桌面环境
有效的小红书账号登录状态
npm install
npx playwright install chromium首次使用或登录状态失效时执行：
npm run build
npm.cmd run setup-profile程序会打开一个专用于 xhs_searchMcp 的 Chromium：
在浏览器中扫码登录小红书。
完成后回到终端按回车。
初始化过程没有扫码超时限制，可以从容完成操作。登录数据保存在项目的 browser-profile 目录中，与日常使用的 Google Chrome 完全隔离。
npm.cmd run search -- --keyword "露营装备"执行成功后，终端会输出结构化 JSON，图片和结果文件会保存在 data 目录。
可选参数：
参数 | 作用 |
| 搜索关键词，必填 |
| 只返回图片 URL，不下载图片 |
| 指定结果保存根目录 |
先完成安装、构建和浏览器初始化，然后在 MCP 客户端配置中加入：
{
"mcpServers": {
"xhs_searchMcp": {
"command": "node",
"args": ["D:xxx\\cyymcp\\dist\\index.js"],
"cwd": "D:xxx\\cyymcp"
}
}
}请将示例路径替换为你的项目绝对路径，然后重启 MCP 客户端。
调用参数：
{
"keyword": "露营装备",
"downloadImages": true,
"headless": false
}返回示例：
{
"success": true,
"keyword": "露营装备",
"title": "新手露营装备清单",
"content": "笔记正文……",
"author": "作者名称",
"noteUrl": "https://www.xiaohongshu.com/explore/...",
"imageUrls": ["https://..."],
"localImages": ["D:\\xhs-data\\01.jpg"],
"outputDir": "D:\\xhs-data\\任务目录",
"retrievedAt": "2026-08-05T01:00:00.000Z"
}执行失败时，现场截图会保存在：
screenshots/错误结果包含错误码、错误信息和截图路径，便于在小红书页面结构变化后快速定位问题。
TypeScript
Node.js
Playwright
Model Context Protocol SDK
Zod
打开小红书，按关键词搜索，筛选图文笔记并按最多点赞排序，返回第一篇普通笔记的标题、正文和图片。调用前须由部署方准备有效登录态。
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | 搜索关键词 | |
| headless | No | 是否使用无头浏览器 | |
| outputDir | No | 结果保存根目录，默认使用项目 data 目录 | |
| downloadImages | No | 是否下载笔记图片 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral details: the search is filtered to image-text notes, results are sorted by likes, and only the first 'normal' note is returned (excluding ads or sponsored content). It also mentions the login dependency. However, it does not explicitly state whether the operation is read-only or if it will download images, though these are implicitly covered by the schema parameters.
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 exactly two sentences, front-loaded with the action and outcome, and includes the essential prerequisite in the second sentence. There is no redundant or filler content; every word contributes meaning.
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 provides a clear overview of the tool's behavior and output (title, body, images), and its prerequisite. However, without an output schema, it does not specify the exact structure of the returned data (e.g., whether images are URLs or local paths) or how errors are handled. Despite these omissions, the core context is sufficient for an agent to invoke the tool for a typical search request.
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 already describes all four parameters completely (keyword, headless, outputDir, downloadImages) with descriptions and defaults, so schema coverage is 100%. The tool description adds no additional meaning beyond the schema, such as how the keyword is used for filtering or the relationship between parameters and the output. It meets the baseline for schema-documented parameters but does not exceed it.
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 function: it opens Xiaohongshu, searches by a keyword, filters image-text notes, sorts by most likes, and returns the first ordinary note's title, body, and images. The verb and resource are specific and the scope is well-defined, distinguishing it from generic search tools.
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 specifies a critical prerequisite: a valid login state must be prepared by the deployer before calling. It also implies the tool is used for retrieving top-liked image-text notes for a given keyword, though it does not explicitly state exclusions or alternatives (no siblings exist). This guidance is sufficient for typical use.
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.0search_xhs_hot_noteScored across 1 tool
With only a single tool, there is no risk of confusing it with another, so the selection is unambiguous. The tool description clearly states its purpose and required conditions.
The tool name 'search_xhs_hot_note' uses a clear verb_noun structure, with 'search' as the action and 'xhs_hot_note' as the target. Since it is the only tool, naming consistency is naturally maintained.
Having exactly one tool for a search service is too few, as it does not provide any redundancy or alternative variations for the user's search needs. The rubric specifically notes that one tool for the apparent scope is a score of 2.
The tool offers a very narrow capability—returning a single hot note for a keyword search—leaving no support for multiple results, different content types, or additional search parameters. This significant lack of coverage means agents will encounter dead ends when requiring fuller search functionality.
MCP server: AI-agent access to Chinese social & trend signals — Douyin, Weibo, Xiaohongshu/RedNote,
MCP server aggregating hot-search boards from 8 Chinese platforms (Weibo, Zhihu, Bilibili, Douyin).
Social media MCP server: your Instagram, TikTok, YouTube, LinkedIn and Threads history for your AI.
MCP server for Qwen Image 3 AI image generation