Xiaohongshu (小红书 / XHS, RedNote) Insights MCP
Server Details
Xiaohongshu / RedNote search, details, comments, creator profiles, and creator note lists.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.8/5 across 9 of 9 tools scored.
Each tool has a distinct purpose, and pairs that perform the same operation on different identifiers (e.g., note_id vs. note_url) are clearly disambiguated by the input parameter. No overlap or ambiguity exists.
All tools follow a consistent snake_case pattern: 'xhs_verb_noun_by_inputtype'. The naming convention is uniform and predictable, making it easy to infer tool functionality from the name.
Nine tools is an appropriate count for a focused domain like Xiaohongshu insights. Each tool serves a clear role, and the set is neither bloated nor sparse.
The tool surface covers core read operations: note details, comments, user info, user posts, and search. Minor gaps exist (e.g., no pagination for comments or second-level replies), but these are acceptable for an insights-oriented server.
Available Tools
9 toolsxhs_get_note_comments_by_note_idARead-onlyInspect
根据 note_id 获取单篇小红书笔记的一级评论。
| Name | Required | Description | Default |
|---|---|---|---|
| note_id | Yes | 小红书笔记 ID。搜索结果中的 note_id 可直接传入 | |
| page_token | No | 分页令牌。首次请求留空；继续翻页时传入上一次返回的 next_page_token |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页一级评论列表 |
| comment_count | Yes | 整篇笔记的总评论数，含一级评论与回复；不是当前页 items 数量 |
| next_page_token | Yes | 下一页分页令牌；为空表示没有更多结果 |
| top_level_comment_count | Yes | 整篇笔记的一级评论总数，不含回复；不是当前页 items 数量。当前数据源未提供时为 null |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation with potentially incomplete data. The description adds value by specifying it retrieves '一级评论' (first-level comments), clarifying the scope of returned data beyond what annotations provide, though it doesn't detail pagination behavior 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?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving comments), high schema coverage (100%), annotations covering safety and data completeness, and the presence of an output schema (which handles return values), the description is complete enough. It effectively complements structured fields without redundancy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for both parameters (note_id and page_token). The description mentions 'note_id' but doesn't add semantic details beyond the schema, such as format examples or usage nuances. Baseline 3 is appropriate as the schema handles most 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 specific action ('获取' - get/retrieve) and resource ('小红书笔记的一级评论' - first-level comments of a Xiaohongshu note), distinguishing it from siblings like xhs_get_note_detail (note details) and xhs_search_notes (search notes). It explicitly mentions the key identifier 'note_id' for targeting.
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 usage context by specifying '根据 note_id' (based on note_id) and '单篇' (single note), suggesting it's for retrieving comments of a specific note rather than searching or batch operations. However, it doesn't explicitly state when to use this versus alternatives like xhs_get_note_comments_by_note_url or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
xhs_get_note_comments_by_note_urlARead-onlyInspect
根据 note_url 获取单篇小红书笔记的一级评论。
| Name | Required | Description | Default |
|---|---|---|---|
| note_url | Yes | 小红书笔记链接、短链接或分享文案。支持以下形式：1) 小红书笔记长链接；2) xhslink.com 短链接；3) 包含上述任一链接的完整分享文案。 | |
| page_token | No | 分页令牌。首次请求留空；继续翻页时传入上一次返回的 next_page_token |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页一级评论列表 |
| comment_count | Yes | 整篇笔记的总评论数，含一级评论与回复；不是当前页 items 数量 |
| next_page_token | Yes | 下一页分页令牌；为空表示没有更多结果 |
| top_level_comment_count | Yes | 整篇笔记的一级评论总数，不含回复；不是当前页 items 数量。当前数据源未提供时为 null |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe read operations with potentially incomplete data. The description adds valuable behavioral context by specifying '单篇小红书笔记' (single Xiaohongshu note) and '一级评论' (first-level comments), clarifying scope and pagination behavior (implied through page_token parameter). It doesn't contradict annotations and provides useful operational details beyond the structured hints.
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 Chinese sentence that directly states the tool's purpose without any wasted words. It's appropriately front-loaded with the core functionality and uses precise terminology. Every element of the description earns its place by clearly communicating the essential operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, pagination), rich annotations (readOnlyHint, openWorldHint), 100% schema coverage, and existence of an output schema, the description provides adequate context. It specifies the scope (single note, first-level comments) which complements the structured data. The main gap is lack of explicit sibling tool differentiation, but overall completeness is good for this tool profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (note_url, page_token) fully documented in the schema. The description doesn't add any parameter semantics beyond what's already in the schema descriptions, which thoroughly explain note_url formats and page_token usage. Baseline score of 3 is appropriate since the schema carries the full parameter documentation burden.
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 purpose: '根据 note_url 获取单篇小红书笔记的一级评论' (Get first-level comments for a single Xiaohongshu note based on note_url). It specifies the verb '获取' (get) and resource '一级评论' (first-level comments), and distinguishes it from sibling tools by focusing on note_url input rather than note_id. However, it doesn't explicitly differentiate from xhs_get_note_comments_by_note_id beyond the parameter difference.
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 usage context by specifying '根据 note_url' (based on note_url), suggesting this tool should be used when you have a note URL rather than a note ID. However, it doesn't explicitly state when to use this versus xhs_get_note_comments_by_note_id, nor does it provide any exclusion criteria or mention alternatives like xhs_get_note_detail for note metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
xhs_get_note_detail_by_note_idARead-onlyInspect
根据 note_id 获取单篇小红书笔记详情。
| Name | Required | Description | Default |
|---|---|---|---|
| note_id | Yes | 小红书笔记 ID。搜索结果中的 note_id 可直接传入 |
Output Schema
| Name | Required | Description |
|---|---|---|
| title | Yes | 笔记标题 |
| video | Yes | 视频摘要信息；无可用视频摘要时为 null |
| author | Yes | 作者信息；详情页不返回小红书号 |
| content | Yes | 笔记正文 |
| note_id | Yes | 笔记 ID |
| note_type | Yes | 笔记类型；当前公开值固定为 image 或 video |
| like_count | Yes | 点赞数 |
| topic_tags | Yes | 笔记详情中的话题标签；无话题时为空数组 |
| image_items | Yes | 图片结构化明细；每项都表示一张图片，Live 图会在对应项携带 live_photo 摘要 |
| share_count | Yes | 分享数 |
| update_time | Yes | 更新时间，秒级 Unix 时间戳；上游未提供时为 null |
| publish_time | Yes | 发布时间，秒级 Unix 时间戳 |
| collect_count | Yes | 收藏数 |
| comment_count | Yes | 评论数 |
| cover_image_url | Yes | 统一封面图 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description is consistent with readOnlyHint and openWorldHint but adds no new behavioral traits 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, front-loaded with action and resource.
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?
Simple tool with good annotations and output schema; description plus structured data fully specify usage.
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%, and description adds practical guidance: note_id can be taken directly from search results.
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 action (获取单篇笔记详情) and resource (by note_id), distinguishing it from siblings that use URL or user ID.
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?
Implied usage (when you have note_id) but no explicit when-not or alternatives. Sibling names are provided contextually.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
xhs_get_note_detail_by_note_urlARead-onlyInspect
根据 note_url 获取单篇小红书笔记详情。
| Name | Required | Description | Default |
|---|---|---|---|
| note_url | Yes | 小红书笔记链接、短链接或分享文案。支持以下形式：1) 带 xsec_token 的小红书笔记长链接；2) xhslink.com 短链接；3) 包含上述任一链接的完整分享文案。直链需自带 xsec_token；短链接或分享文案解析后的最终链接也必须包含 xsec_token。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| title | Yes | 笔记标题 |
| video | Yes | 视频摘要信息；无可用视频摘要时为 null |
| author | Yes | 作者信息；详情页不返回小红书号 |
| content | Yes | 笔记正文 |
| note_id | Yes | 笔记 ID |
| note_type | Yes | 笔记类型；当前公开值固定为 image 或 video |
| like_count | Yes | 点赞数 |
| topic_tags | Yes | 笔记详情中的话题标签；无话题时为空数组 |
| image_items | Yes | 图片结构化明细；每项都表示一张图片，Live 图会在对应项携带 live_photo 摘要 |
| share_count | Yes | 分享数 |
| update_time | Yes | 更新时间，秒级 Unix 时间戳；上游未提供时为 null |
| publish_time | Yes | 发布时间，秒级 Unix 时间戳 |
| collect_count | Yes | 收藏数 |
| comment_count | Yes | 评论数 |
| cover_image_url | Yes | 统一封面图 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds no behavioral context beyond what annotations provide, such as handling of invalid URLs or rate limits, but does not contradict annotations.
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?
A single sentence efficiently conveys the core purpose, but could be slightly more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-detail tool with one well-documented parameter and annotations, the description is adequate but does not mention output details or error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed parameter description. The tool description does not add further meaning, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '获取' (get) and resource '单篇小红书笔记详情' (detail of a single XHS note) and method 'by note_url', distinguishing it from siblings like xhs_get_note_detail_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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a note_url is available, but does not explicitly guide when to use this tool versus alternatives like the note_id version, nor does it provide exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
xhs_get_user_info_by_profile_urlARead-onlyInspect
根据 profile_url 获取单个小红书用户信息。
| Name | Required | Description | Default |
|---|---|---|---|
| profile_url | Yes | 小红书主页链接、短链接或分享文案。支持以下形式：1) xiaohongshu.com/user/profile/... 主页长链；2) xhslink.com 短链接；3) 包含上述任一链接的完整分享文案。解析后的最终链接必须是用户主页链接。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| bio | Yes | 用户个人简介（biography）；当前不可用时为空字符串 |
| name | Yes | 用户名称 |
| red_id | Yes | 用户公开小红书号；当前不可用时为空字符串 |
| user_id | Yes | 用户 user_id |
| verified | Yes | 是否已认证 |
| avatar_url | Yes | 用户头像链接；当前不可用时为 null |
| profile_url | Yes | 用户主页链接；当前不可用时为 null |
| follower_count | Yes | 粉丝数 |
| following_count | Yes | 关注数 |
| posted_note_count | Yes | 已发布笔记数 |
| received_like_count | Yes | 用户内容累计收到的点赞数 |
| verification_category | Yes | 认证类目/行业类目；当前不可用时为空字符串 |
| received_collect_count | Yes | 用户内容累计被收藏数 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only nature is covered. The description adds no further behavioral details (e.g., data freshness, rate limits). This is adequate but not enhancing 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Front-loads the core purpose. Ideally concise.
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 need not detail return values. It covers the essential function. Could mention it's read-only, but annotations already do. Slightly above average due to output schema coverage.
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?
Input schema has 100% coverage, with detailed description of profile_url. The tool description does not add new parameter insights, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '获取单个小红书用户信息' (get single Xiaohongshu user info) using a profile_url. The verb '获取' and resource '用户信息' are specific, and it distinguishes from siblings that use user_id or note-related 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?
No explicit guidance on when to use this tool versus alternatives like xhs_get_user_info_by_user_id. The description is straightforward, but it lacks context on when to prefer this URL-based approach over ID-based or note retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
xhs_get_user_info_by_user_idARead-onlyInspect
根据 user_id 获取单个小红书用户信息。
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | 小红书用户 user_id。可直接传其他结果中的 author.user_id 或用户信息工具返回的 user_id |
Output Schema
| Name | Required | Description |
|---|---|---|
| bio | Yes | 用户个人简介（biography）；当前不可用时为空字符串 |
| name | Yes | 用户名称 |
| red_id | Yes | 用户公开小红书号；当前不可用时为空字符串 |
| user_id | Yes | 用户 user_id |
| verified | Yes | 是否已认证 |
| avatar_url | Yes | 用户头像链接；当前不可用时为 null |
| profile_url | Yes | 用户主页链接；当前不可用时为 null |
| follower_count | Yes | 粉丝数 |
| following_count | Yes | 关注数 |
| posted_note_count | Yes | 已发布笔记数 |
| received_like_count | Yes | 用户内容累计收到的点赞数 |
| verification_category | Yes | 认证类目/行业类目；当前不可用时为空字符串 |
| received_collect_count | Yes | 用户内容累计被收藏数 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description does not need to repeat. It adds no extra behavioral context, but is consistent with annotations, earning a neutral score.
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?
A single, front-loaded sentence with no wasted words. Efficiently conveys the purpose.
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, rich annotations, and presence of an output schema, the minimal description is sufficient. It clearly states the tool's function without missing critical context.
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%, and the description adds no additional meaning beyond what the schema already provides for the user_id 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 verb 'get' and resource 'user info', specifying the identifier 'by user_id'. It distinguishes itself from the sibling tool 'xhs_get_user_info_by_profile_url' which uses a different identifier.
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 (use when you have a user_id) but does not explicitly mention when not to use it or compare to alternatives. The schema further clarifies the source of user_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
xhs_get_user_posted_notes_by_profile_urlBRead-onlyInspect
根据 profile_url 获取用户已发布笔记列表。
| Name | Required | Description | Default |
|---|---|---|---|
| page_token | No | 分页令牌。首次请求留空；继续翻页时传入上一次返回的 next_page_token | |
| profile_url | Yes | 小红书主页链接、短链接或分享文案。支持以下形式：1) xiaohongshu.com/user/profile/... 主页长链；2) xhslink.com 短链接；3) 包含上述任一链接的完整分享文案。解析后的最终链接必须是用户主页链接。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页用户发帖摘要列表 |
| next_page_token | Yes | 下一页分页令牌；为空表示没有更多结果 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds no behavioral details beyond what is already known (e.g., no mention of pagination or rate limits), so it adds minimal value.
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 with no wasted words. It sacrifices some detail for brevity but remains clear.
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?
An output schema exists, so return values are documented elsewhere. However, the description omits mention of pagination (despite a page_token parameter), which would be helpful context for the agent.
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% and the schema already provides detailed descriptions for both parameters. The description does not add any additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (获取) and resource (用户已发布笔记列表) and specifies the input method (by profile_url). It effectively distinguishes 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a profile URL is available, but it does not explicitly state when to use this tool vs alternatives (e.g., by_user_id), nor does it provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
xhs_get_user_posted_notes_by_user_idARead-onlyInspect
根据 user_id 获取用户已发布笔记列表。
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | 小红书用户 user_id。可直接传其他结果中的 author.user_id 或用户信息工具返回的 user_id | |
| page_token | No | 分页令牌。首次请求留空；继续翻页时传入上一次返回的 next_page_token |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页用户发帖摘要列表 |
| next_page_token | Yes | 下一页分页令牌；为空表示没有更多结果 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds no additional behavioral context beyond stating the function. Since annotations cover the safety profile, a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the purpose. Every word is necessary and there is no 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 simple list-fetching tool with pagination, the description is sufficient. The schema covers pagination via page_token, and output schema exists. Minor gap: does not explicitly mention that results are paginated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description does not add any extra meaning beyond what the schema already provides. Baseline 3 is correct.
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 resource '用户已发布笔记列表' (list of posted notes) with input key '根据 user_id' (based on user_id). It distinguishes from sibling tool xhs_get_user_posted_notes_by_profile_url which uses a profile URL instead.
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 that this tool should be used when a user_id is available, as the sibling tool using profile URL exists. However, it does not explicitly state when to use this vs alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
xhs_search_notesBRead-onlyInspect
按关键词搜索相关小红书笔记。
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 搜索结果页码，从 1 开始；继续获取更多结果时使用相同 keyword 和 sort_type，并将 page 设为上一次返回的 next_page；items 为空且 next_page 为 null 表示没有下一页 | |
| keyword | Yes | 小红书搜索关键词 | |
| sort_type | No | 搜索结果排序方式，可选：general（综合，默认）、time_descending（最新）、popularity_descending（热度） | general |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | 搜索结果中的笔记列表，已过滤非笔记卡片与不可公开笔记；当前页过滤后可能为空数组 |
| next_page | Yes | 下一次可尝试请求的搜索页码；仅当 next_page 为 null 时表示没有下一页；非空时表示继续搜索应传入的 page，items 为空时不要单独据此判断结束 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true, covering safety and data scope. The description doesn't contradict these but adds minimal behavioral context beyond the search action. It doesn't disclose details like pagination behavior (implied by 'page' parameter), rate limits, or authentication needs, relying on annotations for core traits.
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 in Chinese: '按关键词搜索相关小红书笔记.' It is front-loaded with the core action, has zero wasted words, and is appropriately sized for a simple search tool. Every part of the sentence contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search with sorting and pagination), rich annotations (readOnlyHint, openWorldHint), and the presence of an output schema, the description is reasonably complete. It states the core action, and structured fields handle parameters, safety, and return values. However, it could benefit from more context on usage versus siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for all parameters (keyword, page, sort_type). The description adds no additional meaning beyond the schema, such as explaining search semantics or result formats. With high schema coverage, the baseline score of 3 is appropriate as the schema carries the parameter burden.
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 purpose: '按关键词搜索相关小红书笔记' (Search for related Xiaohongshu notes by keyword). It specifies the verb (search) and resource (Xiaohongshu notes), but doesn't explicitly differentiate from sibling tools like xhs_get_note_detail (which retrieves details of a specific note). The purpose is clear but lacks sibling distinction.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like xhs_get_note_detail for specific note retrieval or explain scenarios where searching is preferred over direct lookup. Usage is implied by the action but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!