Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

xiaohongshu_note

Fetch a public Xiaohongshu note's normalized details—title, text, media, author, and interaction counts—from an explore URL carrying its xsec_token.

Instructions

Anonymous Xiaohongshu note detail. Returns one public Xiaohongshu note normalized from the site's server-rendered page state: note id, type, title, description text (including hashtags), topic tags, image URLs, an optional stable video URL with duration, publish time, author card, and public interaction counters. Pass url with the note_url returned by /xiaohongshu/explore. The URL must be an xiaohongshu.com /explore/ or /discovery/item/ link carrying its xsec_token; a note id alone is not accessible anonymously, and a stale token returns not-found, so re-run /xiaohongshu/explore to mint a fresh one. Comments are not included because the anonymous page state does not carry them.

Input Schema

NameRequiredDescriptionDefault
urlNoNote URL carrying xsec_token, normally the note_url returned by /xiaohongshu/explore. Pass url, or both note_id and xsec_token.
note_idNo24-character hex note id from an explore card (requires xsec_token)
xsec_tokenNoShort-lived feed-issued token that accompanies note_id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.18

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so: it discloses the anonymous/no-auth access model, the mandatory xsec_token dependency, the stale-token -> not-found behavior, and that no request mutates state. It also explains an important negative behavior ('Comments are not included because the anonymous page state does not carry them'), preventing a pointless retry.

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?

Front-loaded with purpose and access mode before the longer field enumeration, and every sentence adds information (fields, URL constraint, token lifecycle, comments exclusion). The return-field list is somewhat lengthy, but it substitutes for the absent output schema, so it earns most of its space.

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?

There is no output schema and no annotations, yet the description covers purpose, input constraints, failure modes, retry path, and the full shape of the returned record. An agent has everything needed to call this correctly on the first attempt.

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 parameter descriptions already establish the baseline. The description still adds real value beyond the schema: the accepted URL shapes (/explore/<id> and /discovery/item/<id>), the requirement that the link carry its xsec_token, and the relationship that url alone is sufficient while note_id needs an accompanying token.

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+resource ('Anonymous Xiaohongshu note detail') and immediately enumerates exactly what one note record contains: id, type, title, description with hashtags, tags, images, optional video with duration, publish time, author card, counters. It is clearly distinct from the sibling xiaohongshu_note_comments, which it explicitly excludes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It names the exact upstream call ('Pass url with the note_url returned by /xiaohongshu/explore') and gives the fallback remedy for the main failure mode ('a stale token returns not-found, so re-run /xiaohongshu/explore to mint a fresh one'). It also states a boundary condition: 'a note id alone is not accessible anonymously.'

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

Deploy Server

Other Tools