Crawlora MCP

rednote_note

Read-only

Fetch one public Rednote note's normalized detail by rendering the note page in a warm anonymous browser and reading its server-rendered noteDetailMap. Returns note_id, type, title, description text, topic tags, image URLs, an optional video URL with duration, publish time, a public author card, and like/collect/comment/share counters. Pass a rednote.com /discovery/item/ or /explore/ note URL, or just the 24-character note_id; no account, login, or xsec_token is required (a token is accepted but not needed). A login modal may be drawn over the page but the note state is still populated; a removed note returns 404 and no warm browser page yields 503.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "URL": "<URL>",
      "NoteID": "<NoteID>"
    },
    "name": "rednote_note"
  }
}

Input Schema

Name	Required	Description	Default
`URL`	Yes	Rednote note URL (/discovery/item/<id> or /explore/<id>; xsec_token optional). Pass url or note_id.
`NoteID`	Yes	24-character hex note id (alternative to url)

Output Schema

Name	Required	Description	Default
`data`	Yes	The tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 28, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Discloses mechanism (warm anonymous browser rendering server-rendered noteDetailMap), a known quirk (login modal drawn over page but state still populated), and explicit failure modes (removed note → 404, no warm browser page → 503). This is far beyond the readOnly/openWorld annotations and directly informs retry/error handling.

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, then inputs, then behavioral caveats — a sensible order with no filler sentences. The return-field enumeration is somewhat list-heavy, though it doubles as a scoping statement.

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?

Rendering mechanism, auth requirements, and 404/503 error semantics make the definition self-sufficient for a scraping-backed fetch tool; the return-field list is partly redundant with the existing output schema. Nothing critical for correct invocation is missing.

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 real meaning by specifying accepted URL path shapes, the 24-character hex id format, and that xsec_token is optional. One wrinkle: the description frames URL and note_id as alternatives while the schema marks both as required, which an agent may notice.

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?

States a specific verb (fetch) and resource (one public Rednote note's normalized detail) and pins the scope to a single note via URL or 24-char id. It does not name or differentiate against nearby siblings such as rednote_explore, rednote_note_comments, or xiaohongshu_note, so it is clear but not sibling-aware.

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?

Gives concrete input routing ('Pass a ... /discovery/item/<id> or /explore/<id> note URL, or just the 24-character note_id') and removes a likely blocker by stating no account, login, or xsec_token is required. It stops short of naming when to prefer a search/explore/comments sibling instead.

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

All Crawlora MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?