Allows interaction with Xiaohongshu (Little Red Book), providing tools for searching notes, fetching recommended feeds and note details, publishing image-text posts, and liking/favoriting 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., "@xiaohongshu-mcp 帮我搜一下小红书上的露营攻略，取前三条"
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.
小红书 MCP Server（浏览器自动化实现）。扫码登录后，AI 助手可直接搜索笔记、获取推荐/详情、发布图文、点赞收藏。
借鉴 xpzouying/xiaohongshu-mcp 的实现思路（__INITIAL_STATE__ 数据提取、人性化延迟模拟、发布成功验证），采用 Node.js + puppeteer-core 实现，复用本机 Chrome/Edge，无需下载浏览器，npx 一行接入。
在你的 MCP 客户端配置文件（如 ~/.siact/mcps/xiaohongshu.json）中添加：
{
"mcpServers": {
"xiaohongshu": {
"command": "npx",
"args": ["-y", "@the-thing/xiaohongshu-mcp@latest"]
}
}
}要求：Node.js 18+，本机装有 Google Chrome 或 Microsoft Edge（自动探测，也可用环境变量 PUPPETEER_EXECUTABLE_PATH 指定）。
Related MCP server: XHS MCP
工具 | 说明 | 必填参数 |
| 扫码登录小红书（首次使用），登录态自动保存 | 无 |
| 检查登录状态，返回当前账号昵称 | 无 |
| 退出登录，清除本地登录态 | 无 |
| 按关键词搜索笔记 | keyword, limit? |
| 获取首页推荐列表 | limit? |
| 获取笔记详情（正文/图片/互动/评论） | feedId, xsecToken |
| 发布图文笔记（本地图片或 URL） | title, content, images |
| 点赞/取消点赞（自动检测状态防重复） | feedId, xsecToken |
| 收藏/取消收藏（自动检测状态防重复） | feedId, xsecToken |
搜索/推荐结果会返回
id与xsecToken，二者组合才能访问详情页（小红书安全机制），详情/点赞/收藏均需传入。
帮我搜索小红书上的"咖啡探店"笔记，取 5 条
→ xhs_search_feeds(keyword="咖啡探店", limit=5)
看一下第一条笔记的详细内容和评论
→ xhs_get_feed_detail(feedId=..., xsecToken=...)
帮我把这张图配一段文案发到小红书：C:\pics\coffee.jpg
→ xhs_publish_note(title="...", content="...", images=["C:\\pics\\coffee.jpg"])变量 | 说明 |
| 指定 Chrome/Edge 可执行文件路径（默认自动探测） |
| 登录态 cookies 文件路径（默认 |
| 浏览器 profile 目录（默认临时目录，登录态由 cookies 管理） |
|
|
| 代理地址（如 |
git clone <repo>
cd xiaohongshu-mcp
npm install
npm start # 启动 MCP server（stdio）
node client.js # 联调：列出工具并调用 xhs_check_login本项目仅用于学习与研究，使用者应遵守小红书平台规则，控制操作频率，账号风险自负。
检查小红书登录状态：验证本地保存的登录态是否有效，已登录时返回当前账号昵称并刷新登录态。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 discloses that the tool validates the local login state and, when logged in, returns the nickname and refreshes the login state. This explicitly reveals a side effect (refreshing the login state), which is valuable. It does not mention failure behavior or edge cases, but for a simple tool this is reasonable.
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, front-loaded with the main action ('检查小红书登录状态'), followed by concise details about validation and the success response. Every phrase adds meaningful information, with no redundant or verbose language.
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 tool is simple with no parameters and no output schema, but the description does not specify what happens when the login state is invalid or what the exact return value structure is. It mentions returning the nickname when logged in but omits the failure case. This leaves the agent with some ambiguity about the tool's full behavior, 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?
The input schema has zero parameters, so the description does not need to explain parameters. The baseline for no parameters is 4, and the description adds no parameter semantics because there are none to add. The tool's behavior is fully described without requiring parameter details.
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 uses a specific verb ('检查' = check) and a clear resource (小红书登录状态 = Xiaohongshu login status). It explicitly states the tool's function: validating locally saved login state and returning the account nickname if valid, which distinguishes it from sibling tools like xhs_login and xhs_logout.
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 makes the tool's purpose clear, implying it should be used to verify login status before other operations. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The usage context is implied but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
为笔记收藏或取消收藏：智能检测当前状态，已处于目标状态时自动跳过。需要笔记 ID 与 xsecToken。
| Name | Required | Description | Default |
|---|---|---|---|
| feedId | Yes | 笔记 ID | |
| xsecToken | Yes | 访问令牌 | |
| unfavorite | No | true 为取消收藏，默认 false（收藏） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It usefully discloses the idempotent behavior ('已处于目标状态时自动跳过') and the token requirement. However, it omits other behavioral aspects such as reversibility, potential side effects, and return value, which would be valuable for an agent to know.
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 leads with the primary verb and resource. It includes only essential information—the action, the smart-skip behavior, and the required inputs—with no redundant content. Excellent structure and economy of 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 low complexity (3 scalar parameters, no output schema, no nested objects), the description covers the core purpose, behavioral nuance, and required inputs. However, since there is no output schema, it would benefit from mentioning return values or error conditions, which are currently absent. This is a minor gap, so a score of 4 is appropriate.
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 schema already provides descriptions for all three parameters (100% coverage), including the default for unfavorite. The description only reiterates that feedId and xsecToken are required, which is already in the schema. No additional semantic insight is provided, so the baseline 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?
The description clearly states the action: '为笔记收藏或取消收藏' (favorite or unfavorite a note), identifying both the verb and the resource. It also mentions '智能检测当前状态' which distinguishes its behavior from simpler toggle tools and from the sibling like_feed. This is specific and avoids ambiguity.
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 does not explicitly state when to use this tool versus alternatives like like_feed, nor does it mention exclusions. The intended use is implied by the tool's name and description, but there is no direct comparison or 'when not to use' guidance, leaving the agent to infer from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取小红书笔记详情：返回笔记标题、正文、图片列表、作者信息、互动数据与前若干条评论。需要笔记 ID 与 xsecToken（两者缺一不可，从搜索/推荐结果获取）。
| Name | Required | Description | Default |
|---|---|---|---|
| feedId | Yes | 笔记 ID（从 xhs_search_feeds 或 xhs_get_recommend_feeds 结果获取） | |
| xsecToken | Yes | 访问令牌 xsecToken（从搜索/推荐结果获取） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It states what data is returned and that both ID and token are required. However, it does not mention whether authentication is needed (relevant given sibling xhs_login), the exact limit of comments ('前若干条' is vague), or any error/rate-limit 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 one concise sentence that leads with the purpose, lists the returned fields, and states the prerequisite. 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?
For a detail-fetch tool with two parameters, the description gives a good overview of the return payload and prerequisites. However, it lacks an output schema and does not specify authentication requirements or comment count boundary, leaving some 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 schema already provides 100% coverage for both parameters, so the baseline is 3. The description reinforces that both are mandatory ('两者缺一不可') and points to their origin (search/recommend results), adding marginal value over the 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 tool's function: '获取小红书笔记详情' (get note details), and enumerates the returned data (title, body, images, author info, interaction data, comments). This distinguishes it from sibling tools like search, recommend, publish, like, and favorite.
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 specifies the required inputs for use: '需要笔记 ID 与 xsecToken（两者缺一不可，从搜索/推荐结果获取）', indicating that this tool is for fetching details after obtaining a note ID via search or recommendation. It clearly implies the context of use, though it does not explicitly mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取小红书首页推荐笔记列表（返回笔记 ID、xsecToken、标题、作者、互动数据）。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 返回条数上限，默认 10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention authentication requirements (despite sibling login tools), potential rate limits, or any side effects. The description only lists return data, leaving crucial operational context 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, compact sentence that front-loads the main action and resource, then lists the return fields. It is efficient, with no redundant text or unnecessary detail.
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-only tool with one optional parameter, the description adequately covers purpose and return fields. However, it omits prerequisites like login and potential error scenarios, which could leave an agent unprepared despite the overall clarity.
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 sole parameter 'limit' is fully described in the schema (max count, default 10), so the description adds no extra parameter-specific meaning. Schema coverage is 100%, meaning the description does not need to compensate for missing parameter documentation.
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 retrieves the list of recommended notes from the Xiaohongshu homepage and enumerates the returned fields (ID, xsecToken, title, author, interaction data). This is a specific verb+resource operation that distinguishes it from siblings like xhs_search_feeds and xhs_get_feed_detail.
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 is for browsing homepage recommendations but does not explicitly say when to use it over alternatives or any exclusions. The sibling context suggests it is used when a user wants recommended feeds, but no concrete guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
为笔记点赞或取消点赞：智能检测当前状态，已处于目标状态时自动跳过。需要笔记 ID 与 xsecToken。
| Name | Required | Description | Default |
|---|---|---|---|
| feedId | Yes | 笔记 ID | |
| unlike | No | true 为取消点赞，默认 false（点赞） | |
| xsecToken | Yes | 访问令牌 |
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 discloses a key behavior: '智能检测当前状态，已处于目标状态时自动跳过' (intelligently detects current state, skips if already in target state), indicating idempotency. However, it does not describe error conditions, return values, or permission requirements beyond the needed token, leaving some behavioral gaps.
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 and follows with the key behavioral nuance and prerequisites. Every clause earns its place with no filler or 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?
This is a simple mutation tool with no output schema and no annotations. The description adequately covers what it does, the idempotency behavior, and required inputs. However, it omits return value/feedback and error handling scenarios (e.g., invalid token, non-existent feed), which are important for an agent to fully understand the outcome. Given the tool's simplicity, it is acceptable but not complete.
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 provides 100% coverage with descriptions for all three parameters. The description only repeats the requirement for feedId and xsecToken, adding no extra meaning to the 'unlike' parameter or the relationship between parameters. Since schema coverage is high, the baseline is 3, and the description does not elevate 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 action: '为笔记点赞或取消点赞' (like or unlike a note), identifying both the verb and the resource. It also adds a distinctive behavior of auto-detecting current state and skipping if already in the target state. However, it does not explicitly differentiate itself from the sibling tool 'xhs_favorite_feed', 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?
The description mentions a prerequisite ('需要笔记 ID 与 xsecToken' – requires note ID and xsecToken), which implies basic usage context. It does not provide explicit when-to-use vs alternatives or exclusions, such as 'use this for liking, use xhs_favorite_feed for favoriting'. This is adequate but lacks clear alternative guidance.
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 | |||
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 transparently describes the browser window, QR code, waiting for scanning, and automatic saving of login state, giving a clear picture of the interactive process. It does not cover timeouts or failure scenarios, but the core behavior is well disclosed.
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 front-loads the action ('登录小红书') and efficiently explains the entire process in a concise, structured way. Every phrase contributes meaning with no 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?
For a zero-parameter interactive login tool, the description covers the main flow and persistence of login state. However, it does not specify the return value or whether the function blocks until scanning, which could be gaps given the absence of an output schema. Still, it's sufficiently complete for the tool's simplicity.
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 zero parameters, and schema coverage is 100% (vacuously). According to the baseline rule for 0 parameters, a score of 4 is appropriate; the description does not need to explain any parameters since there are none.
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: logging into Xiaohongshu by opening a browser, displaying a QR code, waiting for scanning, and saving login state. It explicitly distinguishes from siblings like xhs_check_login and xhs_logout, making the purpose unmistakable.
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 use for initial login and notes that login state is persisted for future use, but it does not explicitly compare with xhs_check_login or explain when not to use. There is no explicit when/when-not guidance, only implied context from the login flow.
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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects itself. It states that local login state is cleared, implying a state-modifying action. However, it does not clarify whether a server-side session is invalidated or whether the action is reversible, leaving some behavioral ambiguity.
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, straightforward sentence that front-loads the main action ('退出登录') and then explains the effect. There is no filler or redundant information.
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 zero-parameter logout tool with no output schema, the description adequately covers the action and its local effect. It omits return value expectations, but the simplicity of the tool makes this omission acceptable.
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 zero parameters, and the empty schema matches this. The description adds no parameter-specific details, but there is nothing to document. Baseline of 4 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?
The description clearly specifies the action '退出登录' (logout) and the affected resource '小红书登录态' (Xiaohongshu login state). It distinguishes itself from sibling tools like xhs_login and xhs_check_login by stating it clears the local login state.
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 purpose is immediately clear: use this tool to log out and clear local login state. While it doesn't explicitly mention alternatives or when-not-to-use, the context is unambiguous given the sibling tool names, making the intended use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
发布图文笔记到小红书：需要标题（最多 20 字）、正文、至少 1 张图片（本地绝对路径或 HTTP 图片链接），可选话题标签。发布前需已登录。
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | 话题标签列表（可选），如 ["美食", "旅行"] | |
| title | Yes | 笔记标题（最多 20 字） | |
| images | Yes | 图片路径列表：本地绝对路径或 HTTP(S) 链接，至少 1 张 | |
| content | Yes | 笔记正文 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of transparency. It discloses the login requirement and input constraints (image format and count), which is useful. However, it does not mention post-publish behavior, error conditions, or side effects, leaving some gaps for a mutation tool without annotation support.
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 that front-loads the primary action and resource, then lists requirements and prerequisites in a clear, ordered manner. Every element earns its place with no redundancy or fluff.
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?
With 4 fully documented parameters and no output schema, the description adequately covers prerequisites and key input constraints. It lacks explicit mention of success/failure feedback or error handling, but these are not critical for a straightforward publish action.
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 baseline is 3. The description largely echoes the schema details (title max 20 characters, at least one image, local/HTTP paths, optional tags) without adding new semantic meaning beyond what the schema already provides.
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 ('图文笔记到小红书' – image-text note to Xiaohongshu), distinguishing it from sibling tools that handle login, search, like, and favorite operations. The verb+resource combination is specific and 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?
The description explicitly states the prerequisite of being logged in ('发布前需已登录') and enumerates required inputs (title, content, at least one image, optional tags). It does not explicitly name alternatives, but the publish action is clearly distinct from sibling tools, providing sufficient usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索小红书笔记：按关键词搜索，返回笔记列表（含笔记 ID、xsecToken、标题、作者、互动数据）。返回的 id + xsecToken 可用于 xhs_get_feed_detail / xhs_like_feed / xhs_favorite_feed。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 返回条数上限，默认 10 | |
| keyword | Yes | 搜索关键词，如"美食"、"旅行攻略" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output structure and downstream usability of the returned IDs, which is useful. However, it does not mention whether login is required, error behavior, sorting/pagination, or rate limits, leaving notable gaps in behavioral transparency.
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 two concise sentences, front-loaded with the primary action and followed by useful output details. Every sentence earns its place, with no redundancy or fluff.
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 no output schema and no annotations, the description provides essential information about what is returned and how to use the results. However, it omits authentication requirements, pagination/ordering behavior, and potential error scenarios, so it is not fully complete for a robust agent interaction.
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%: both keyword and limit have descriptions. The description adds minimal parameter-level meaning beyond the schema (it restates keyword-based search), so a baseline of 3 is appropriate without additional enrichment.
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 states '搜索小红书笔记' (search Xiaohongshu notes) with a specific verb and resource, and lists the exact returned fields (ID, xsecToken, title, author, interaction data). This clearly distinguishes it from sibling tools like xhs_get_recommend_feeds or xhs_get_feed_detail by emphasizing keyword-based 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 provides clear context for when to use this tool (keyword search) and even explains how the returned id+xsecToken can be used with related tools. However, it does not explicitly mention alternatives or exclusions (e.g., 'use xhs_get_recommend_feeds for browsing'), but the purpose is clear enough for an agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clear, distinct purpose: authentication (login/check/logout), feed retrieval (search vs recommend), detail fetch, publishing, and engagement (like vs favorite). No two tools appear to do the same thing.
All tools follow a consistent xhs_verb_noun pattern in snake_case, such as xhs_search_feeds, xhs_get_feed_detail, and xhs_publish_note. This makes the tool set highly predictable.
9 tools is well within the ideal range for a client MCP server. Each tool serves a distinct and necessary function for interacting with the platform.
Core workflows are covered: authentication, search, recommend, detail, publish, like, and favorite. Notable gaps include comment creation, user follow, and note update/delete, but these are not critical for basic read/write interactions.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
搜索笔记、浏览首页推荐、查看笔记内容与评论，并发表你的评论。直接在工作流中与小红书内容互动，高效跟进话题。
XHS note/product search/detail, suggestions, comments/replies; PGY 20pts success, failures uncharged
Xiaohongshu, Douyin, YouTube, TikTok and X links as LLM-ready text
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/JessYan0913/xiaohongshu-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
