SocialDataX 小红书 Xiaohongshu XHS RedNote MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.5
Disambiguation5/5
Each tool targets a distinct resource or action (note detail, comments, user info, search, etc.), and variants for URL vs ID are clearly differentiated. No two tools have overlapping purposes.
Naming Consistency5/5
All tools follow the 'xhs_verb_noun' pattern in snake_case consistently. Verbs like 'submit', 'get', 'search' are used uniformly, and nouns clearly describe the resource.
Tool Count5/5
14 tools cover a broad but focused set of operations for interacting with Xiaohongshu data. The count is well-scoped without being excessive or insufficient.
Completeness5/5
The server covers all major read operations: note detail, search, hot list, comments (main and sub), user info, user posts, and video speech text. There are no obvious gaps for its intended analysis purpose.
Average 4.1/5 across 14 of 14 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 12 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 2 times in the last 30 days.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation with potentially changing results. The description adds no behavioral context beyond these annotations, but does not contradict them. With annotations present, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence in Chinese, conveying the purpose with zero waste. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, presence of an output schema (not shown), and annotations, the description is sufficient for a straightforward fetch tool. It could mention that the output is a list, but the output schema likely covers this. Completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema covers 100%. The description is not required to explain parameters. A baseline of 4 is justified as no information is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 search hot list). It is specific and distinguishes from sibling tools, which focus on notes, users, or comments. However, it lacks any additional context about the tool's scope or output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention use cases, prerequisites, or exclusions, leaving the agent to infer its role among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds an important behavioral rule: the returned note_url must be preserved exactly with all query parameters, and not reconstructed from note_id. This goes beyond annotation defaults and prevents misuse. However, it does not mention pagination behavior or result count limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences: the first states the purpose concisely, the second provides a critical usage instruction. It is efficient with no redundancy. However, the second sentence is somewhat lengthy and could be broken into bullet points for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema (5 params with full descriptions) and output schema existence, the description compensates by adding the URL preservation rule. It lacks a high-level summary of the return structure (list of notes with fields), but the output schema likely covers that. Pagination is handled in schema via page_token parameter description. Overall, it is fairly complete for a read-only search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 5 parameters. The description adds no additional parameter information beyond what is already in the schema, so it meets the baseline without adding extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '按关键词搜索相关小红书笔记' (search related Xiaohongshu notes by keyword), which is a specific verb+resource. It distinguishes from sibling tools like xhs_get_note_detail or xhs_get_search_hot_list. However, the description overshadows the purpose with a detailed instruction about URL handling, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., xhs_get_search_hot_list for trending, xhs_get_user_posted_notes for user-specific notes). There is no mention of when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
注释已提供 readOnlyHint 和 openWorldHint，描述未额外披露行为特性。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
一句话简洁明了，动词在前。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
结合注释和参数描述，基本完整，但未说明返回信息的具体范围。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
参数描述覆盖100%，且参数描述详细，但工具描述本身未增加语义。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
明确指定动作'获取'和资源'用户信息'，且通过输入指定 user_id，与通过 profile_url 获取的兄弟工具区分开。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
描述明确指出使用场景为提供 user_id，虽然没有明确说不适合其他场景，但输入参数描述补充了使用建议。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds no further behavioral context. It does not mention any additional traits beyond what annotations provide, and there is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose with no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 existing output schema, the description is adequate. It does not cover edge cases, but the annotations and schema provide sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter description thoroughly listing supported input formats. The tool description does not add meaningful information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('获取'), resource ('用户信息'), and the input methods (profile link, short link, share text). It effectively distinguishes this tool from its sibling 'xhs_get_user_info_by_user_id' by specifying the input type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a profile URL is available, but it does not explicitly state when to use this tool versus alternatives like 'xhs_get_user_info_by_user_id'. No exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the async nature (submission, waiting, polling hint) and the return of job_id and next action. However, it does not mention required permissions, idempotency, or side effects (e.g., whether repeated submissions create duplicate tasks).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no wasted words. It front-loads the key action and includes essential post-submission behavior. Could be slightly improved by separating input and output details, but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 and sibling tools for retrieval, the description provides sufficient context for a submission tool: it explains the input, the waiting period, and what to do next. It does not need to detail return values as the output schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the only parameter note_id, and the schema already provides extensive detail (24-char hex, must be exact). The tool description adds no further semantic meaning beyond what the schema offers, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: submit a video note speech-to-text task using note_id. It distinguishes from sibling tool xhs_submit_video_speech_text_by_note_url by specifying the input is note_id, not URL. The description also explains the behavior after submission (wait up to 210s, return job_id and next action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is for submitting a new transcription task, and after waiting briefly, the agent should use the returned job_id and next query action. However, it does not explicitly state when not to use this tool (e.g., for checking status) or mention alternatives like xhs_get_video_speech_text_job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the asynchronous nature ('最多短等 210 秒'), the return of a job_id upon timeout, and a subsequent query action. This goes beyond the name to explain the tool's non-immediate behavior, though it doesn't cover error conditions or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with two clauses, no wasted words. It front-loads the main purpose and efficiently adds the timeout behavior. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, an output schema, and a straightforward async pattern, the description provides sufficient context: what the tool does, input needed, and the asynchronous result handling. It does not cover error scenarios, but the output schema likely handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with a clear description for 'note_url'. The tool description does not add additional parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: '提交小红书视频笔记口播转文字任务' (submit a Xiaohongshu video note speech-to-text task). It also specifies the input via the tool name (note_url) and the asynchronous behavior (wait up to 210 seconds, return job_id). This distinguishes it from sibling tools like xhs_get_video_speech_text_job or xhs_submit_video_speech_text_by_note_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage flow (submit, wait, then query if incomplete) but does not explicitly state when to use this tool over alternatives, such as xhs_submit_video_speech_text_by_note_id. It hints at the next step ('返回 job_id 和下一步查询动作') but lacks explicit guidance on prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint and openWorldHint. The description adds crucial behavioral context: preserving the full URL with xsec_token and not constructing URLs from note_id. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. Front-loaded purpose in first sentence, followed by specific instructions. Could be slightly more concise but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with an output schema, the description covers usage constraints (URL preservation). No missing elements for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a detailed parameter description. The main description adds value by instructing to preserve the URL as-is, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 '笔记详情' (note detail), specifying input types (note link, short link, or sharing text). It distinguishes from the sibling tool 'xhs_get_note_detail_by_note_id' which uses note_id instead of URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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. It implies usage when a URL is available, but lacks when-not or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that the operation does not trigger reprocessing and explains the wait_seconds parameter's behavior (long polling vs one-shot), enhancing behavioral understanding beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese covering purpose and key behavioral note. It is concise and front-loaded, but lacks structured formatting (e.g., bullet points) that could improve readability for complex scenarios.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 100% schema coverage and an output schema present, the description adequately covers the tool's purpose, parameters, and core behavior. However, it omits details like expected status values or response format, though the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters fully described in the input schema. The description restates that wait_seconds enables long polling but does not add novel meaning beyond what the schema already provides, hence a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the status of a video speech-to-text job, specifying the resource ('小红书视频口播转文字任务状态') and action ('查询'). It distinguishes itself from submission siblings like 'xhs_submit_video_speech_text_by_note_url' by focusing on status retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by mentioning optional long polling ('可选长轮询当前 job') and noting that it does not trigger reprocessing ('不触发重处理'). This guides usage, though it does not explicitly state when to use this tool over siblings; however, the sibling list contrasts submission tools effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds important behavioral context about the opaque pagination token (binding, non-modifiable), which is beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. First sentence states purpose, second explains pagination. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 and full parameter descriptions, the description covers the core purpose and token behavior. It does not mention pagination limits or error cases, but these are not critical for a list tool with output schema. Overall complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter descriptions are already detailed in the schema. The description does not add new meaning beyond what is in the schema; it only repeats token rules. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('获取二级评论' i.e., get sub-comments) and resource ('note_id 和一级评论 comment_id'). It unambiguously distinguishes from sibling tools that retrieve top-level comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains pagination token usage in detail, but does not explicitly state when to use this tool versus the top-level comment tools (e.g., 'first get top-level comments, then use this for replies'). The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral detail beyond annotations, especially regarding the opaque pagination token's binding to user, note, sort, and link, and the prohibition on modifying or reusing it. This is valuable for correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then explains pagination. Every sentence is useful, though slightly verbose. It could be more concise but remains clear and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 adequately covers the tool's purpose and parameters. It does not explain error handling or rate limits, but for a fetch tool with readOnlyHint and openWorldHint, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions already. The description repeats some info but adds context for pagination usage. It does not add substantial new semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '根据 note_id 获取单篇小红书笔记的一级评论', specifying the verb '获取' and resource '一级评论' for a single note. It distinguishes from siblings like xhs_get_note_sub_comments_by_comment_id which handles sub-comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by focusing on top-level comments and explaining pagination with page_token. It does not explicitly list when to avoid this tool, but the context and sibling tools make differentiation clear. The pagination usage is well-explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true and openWorldHint=true, indicating a safe read operation. The description adds context about page_token binding rules and the fact that first-level comments cannot be reused across sorts, which goes beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single paragraph but covers core purpose, sorting, pagination, and token rules efficiently. It front-loads the main function. Every sentence adds value; no fluff. Could be slightly more structured with bullet points, but still good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations, full schema coverage, and an output schema (implied), the description covers essential behavioral aspects. It explains pagination mechanics thoroughly. The only minor gap is explicit mention of the output format, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining supported URL formats for note_url, enum options for sort_type, and detailed constraints for page_token (e.g., not modifying, not using across sorts). This enriches the parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves first-level comments of a Xiaohongshu note using the note URL, short link, or share text. It distinguishes from sibling tools like `xhs_get_note_comments_by_note_id` (which uses note ID) and `xhs_get_note_sub_comments_by_comment_id` (sub-comments). The verb '获取' and resource '一级评论' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions for pagination (page_token handling, not modifiable, bound to user/note/sort) and sorting options. Does not explicitly state when to prefer this tool over the note_id variant, but the sibling list provides context. The guidelines are thorough for the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds actionable behavioral detail about note_url handling, which is beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences: one for purpose, one for critical usage rule. No redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with output schema present, the description is complete. It covers purpose, input constraint, post-usage rule, and is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description already fully covers the note_id parameter (100% coverage). The tool description does not add new semantic meaning about the parameter beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: fetching single note details by note_id. It distinguishes from sibling tools like xhs_get_note_detail_by_note_url by specifying the input identifier type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on handling the returned note_url, including preservation and when not to synthesize. While it doesn't explicitly compare with all siblings, the context implies appropriate use cases based on note_id vs URL.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds essential behavioral details on token binding and modification restrictions beyond annotations' readOnlyHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet comprehensive; every sentence adds value, especially detailed token rules.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers pagination behavior and parameter usage; output schema exists, so return info not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have extensive descriptions adding context: user_id source, token handling rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states '获取用户已发布笔记列表' (get user's posted notes list) by user_id, distinguishing from sibling using profile_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed instructions on pagination token usage, but does not explicitly state when to use this vs sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description details critical behavior: the next_page_token is opaque and bound to the current user/note/comment chain, cannot be reused across chains, and must be passed verbatim. This greatly helps the agent avoid misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first for purpose, second for token rules. No fluff, front-loaded, and every sentence is essential. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input, output (implied list), and token handling. Output schema exists, so return values need no explanation. Sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining token behavior (page_token) and gives a caution for profile_url (not note link). This extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a user's posted notes list using a profile URL, short link, or share text. It specifies the exact input types, distinguishing it from sibling tools like xhs_get_user_posted_notes_by_user_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use by specifying input (profile URL vs. user ID for siblings). However, it does not explicitly state when not to use or mention alternatives, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![xiaohongshu-xhs-rednote-mcp MCP server](https://glama.ai/mcp/servers/DevinChen2014/xiaohongshu-xhs-rednote-mcp/badges/card.svg)](https://glama.ai/mcp/servers/DevinChen2014/xiaohongshu-xhs-rednote-mcp)

Score Badge

Copy to your README.md:

[![xiaohongshu-xhs-rednote-mcp MCP server](https://glama.ai/mcp/servers/DevinChen2014/xiaohongshu-xhs-rednote-mcp/badges/score.svg)](https://glama.ai/mcp/servers/DevinChen2014/xiaohongshu-xhs-rednote-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DevinChen2014/xiaohongshu-xhs-rednote-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server