SocialDataX 小红书 Xiaohongshu XHS RedNote MCP

xhs_get_note_detail_by_note_id

Read-only

根据 note_id 获取单篇小红书笔记详情。返回的 note_url 非 null 时，在任何使用场景都必须原样保留完整 URL，包括 xsec_token 等 query 参数；例如最终回答、展示、引用、存储、输出或传递；不得用 note_id 重新拼接链接；note_url 为 null 时不要用 note_id 合成公开链接。

Input Schema

TableJSON Schema

Name	Required	Description	Default
`note_id`	Yes	note_id 是小红书笔记 ID。已有完整 note_id 时原样使用；否则可从笔记搜索、笔记详情、评论、标签页笔记列表或用户发帖列表结果复制；不得截断、缩写、脱敏、补全、格式化、重组，也不得只传前缀。

Output Schema

TableJSON Schema

Name	Required	Description
`title`	Yes	笔记标题
`video`	Yes	视频摘要信息；无可用视频摘要时为 null
`author`	Yes	作者信息；详情页不返回小红书号
`points`	Yes	本次成功调用的积分消耗与调用完成时的账户积分余额。
`content`	Yes	笔记正文
`note_id`	Yes	note_id 是小红书笔记 ID。已有完整 note_id 时原样使用；否则可从笔记搜索、笔记详情、评论、标签页笔记列表或用户发帖列表结果复制；不得截断、缩写、脱敏、补全、格式化、重组，也不得只传前缀。
`note_url`	Yes	note_url 是可打开笔记内容所需的完整 URL。任何使用该返回链接的场景都必须原样保留完整 URL，包括 xsec_token 等 query 参数；例如最终回答、展示、引用、存储、输出或传递；不得修改、截断、脱敏、规范化、重组，也不得用 note_id 重新拼接链接。无法提供可用链接时为 null；note_url 为 null 时不要用 note_id 合成公开链接。
`note_type`	Yes	笔记类型；当前公开值固定为 image 或 video
`like_count`	Yes	点赞数
`topic_tags`	Yes	笔记详情中的话题标签；无话题时为空数组
`image_items`	Yes	图片结构化明细；每项都表示一张图片，Live 图会在对应项携带 live_photo 摘要
`ip_location`	Yes	笔记发布时的 IP 属地；没有 IP 属地时为空字符串
`share_count`	Yes	分享数
`update_time`	Yes	更新时间，秒级 Unix 时间戳；没有有效更新时间时为 null
`publish_time`	Yes	发布时间，秒级 Unix 时间戳
`collect_count`	Yes	收藏数
`comment_count`	Yes	评论数
`cover_image_url`	Yes	统一封面图
`mentioned_users`	Yes	笔记正文中 @ 到的用户列表；无 @ 时为空数组

TDQS

A3.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds a crucial behavioral rule beyond the readOnly/openWorld annotations: when note_url is non-null it must be preserved verbatim including query parameters, and when null no public URL should be synthesized from note_id. This is actionable, specific, and not inferable from the schema.

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 with no filler: the first states the operation, the second states the critical URL-handling constraint. Important information is front-loaded and every clause earns its place.

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?

For a simple one-parameter read tool with an output schema, the description plus schema covers most needs. However, it is incomplete as a selection aid because it does not differentiate the tool from the sibling xhs_pgy_get_note_detail_by_note_id, and it lacks any mention of when a URL-based alternative would be preferred.

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%, and the note_id parameter is already described in detail in the schema. The tool description only repeats that it uses note_id and adds no parameter-level meaning beyond the schema, so the baseline 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 opens with a specific verb and resource: '根据 note_id 获取单篇小红书笔记详情' (get single Xiaohongshu note detail by note_id), which clearly identifies what the tool does and the identifier it keys on. This naturally distinguishes it from the sibling note_url-based tools.

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 given about when to choose this tool over alternatives. It does not mention xhs_get_note_detail_by_note_url for URL inputs, nor does it explain the difference from xhs_pgy_get_note_detail_by_note_id, so an agent receives no routing help beyond the tool name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All SocialDataX 小红书 Xiaohongshu XHS RedNote MCP tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation3/5

Most tools are clearly separated by resource and action, but there are many near-duplicate pairs that differ only by ID vs URL input, such as xhs_get_note_detail_by_note_id and xhs_get_note_detail_by_note_url. The pgy note detail tools and standard note detail tools also overlap in purpose, though descriptions note the commercial-data distinction. Overall, an agent can disambiguate with care, but misselection risk is non-trivial.

Naming Consistency4/5

The dominant pattern is xhs_<verb>_<resource>_by_<identifier>, which is predictable and readable. Minor deviations exist: socialdatax_get_points_balance uses a different prefix, xhs_get_note_sub_comments_by_comment_id omits the required note_id from the name, and xhs_get_video_speech_text_job lacks a by_ parameter suffix. These are small inconsistencies rather than chaotic naming.

Tool Count3/5

24 tools is on the heavy side and within the borderline range of 16-25. The count is inflated by ID/URL duplication and separate pgy variants, though the underlying domain (notes, comments, users, products, search, hot lists, video speech, points) is broad. Each tool has a plausible use, but the surface feels larger than necessary.

Completeness4/5

The toolset covers the main read-only Xiaohongshu workflows: note details, comments and sub-comments, user profiles and posted notes, topic notes, product details/reviews, search, hot list, video speech text submission/query, and points balance. Minor gaps exist, such as no direct sub-comments-by-URL tool and product reviews only supported via sku_id, but these are workable through existing flows. No obvious dead ends for typical retrieval use cases.

Resources

Need Help?