Which integrations are available for this server?

Provides tools for searching Xiaohongshu (Little Red Book) notes, retrieving note details and comments, and managing login sessions. Provides tools for searching Zhihu questions and articles, retrieving question details and answers, and managing login sessions.

How do I use Stride28 Search MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Stride28 Search MCP search Xiaohongshu for RAG interview questions" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Stride28 Search MCP

by BrunonXU

Overview Schema Source Related Servers Discussions Admin

Python

Local

这是 Stride28 智能学习平台的搜索模块，独立抽出来作为 MCP 工具。

演示

Kiro + MCP 搜索

WorkBuddy + MCP 自动化（即将推出）

一键爬取小红书/知乎内容 → 接入腾讯文档/飞书文档自动整理 → 配合 Claw 实现每日自动化拉取、分类归档、摘要生成。

Related MCP server: RedNote MCP

使用场景

跟 AI 助手说：

"帮我搜小红书上关于 RAG 的面试题"
"看看那篇笔记的详细内容和评论"
"去知乎搜搜 Agent 开发相关的讨论"
"只搜小红书的视频笔记"
"获取知乎这个问题的完整回答，不要截断"

AI 会自动调用对应的 MCP tool。首次使用时会弹出浏览器让你完成登录。

安装

Python 3.10+

# uv（推荐）
uv tool install stride28-search-mcp

# 或 pipx
pipx install stride28-search-mcp

安装浏览器：

stride28-search-mcp install-browser

配置

在 MCP 客户端配置中添加：

{
  "mcpServers": {
    "stride28-search": {
      "command": "stride28-search-mcp",
      "disabled": false
    }
  }
}

建议为不同客户端显式设置不同的 STRIDE28_SEARCH_MCP_PROFILE，不要共用默认 profile。否则 Kiro、Work Buddy、本地手测会复用同一份 Chromium 持久化目录，导致“没扫码却像是已经登录”的假象。

Kiro 示例：

{
  "mcpServers": {
    "stride28-search": {
      "command": "stride28-search-mcp",
      "env": {
        "STRIDE28_SEARCH_MCP_PROFILE": "kiro",
        "STRIDE28_XHS_HEADLESS": "false",
        "STRIDE28_ZHIHU_HEADLESS": "true"
      },
      "disabled": false
    }
  }
}

Work Buddy 示例（实验性）：

{
  "mcpServers": {
    "stride28-search": {
      "command": "uvx",
      "args": ["stride28-search-mcp"],
      "env": {
        "STRIDE28_SEARCH_MCP_PROFILE": "workbuddy",
        "STRIDE28_XHS_HEADLESS": "false",
        "STRIDE28_ZHIHU_HEADLESS": "true"
      },
      "disabled": false
    }
  }
}

uvx + WorkBuddy + 小红书搜索 当前只作为实验性路径保留，不作为发版前必过项。默认推荐已安装包的 stdio 配置。

{
  "mcpServers": {
    "stride28-search": {
      "command": "uvx",
      "args": ["stride28-search-mcp"],
      "disabled": false
    }
  }
}

兼容：Kiro · Cursor · Claude Code · VS Code + Copilot · 任何支持 MCP stdio transport 的客户端

Tool	平台	说明
`login_xiaohongshu`	小红书	扫码登录，Cookie 持久化
`search_xiaohongshu`	小红书	关键词搜索，支持图文/视频过滤
`get_note_detail`	小红书	笔记详情 + 评论翻页 + 发布时间
`login_zhihu`	知乎	手动登录
`reset_xiaohongshu_login`	小红书	清空当前 profile 的登录态
`search_zhihu`	知乎	关键词搜索（问答/专栏/视频）
`get_zhihu_question`	知乎	Top N 回答，内容长度可配置
`reset_zhihu_login`	知乎	清空当前 profile 的登录态

search_xiaohongshu

参数	类型	默认值	说明
`query`	string	必填	搜索关键词
`limit`	int	10	返回条数；推荐 `10-20`，主要影响返回多少条，不会额外触发评论翻页
`note_type`	string	`"all"`	`"all"` / `"normal"` / `"video"`

get_note_detail

参数	类型	默认值	说明
`note_id`	string	必填	笔记 ID
`xsec_token`	string	`""`	安全 token
`max_comments`	int	10	推荐 `10-20`；超过 `20` 属于更深评论抓取。服务端会将大于 `50` 的值按 `50` 处理，以控制单次详情请求强度

search_zhihu

参数	类型	默认值	说明
`query`	string	必填	搜索关键词
`limit`	int	10	推荐 `5-10`；主要影响返回多少条解析结果

get_zhihu_question

参数	类型	默认值	说明
`question_id`	string	必填	问题 ID
`limit`	int	5	推荐 `3-5`；主要影响返回多少条回答
`max_content_length`	int	10000	最大字符数，`0` = 不截断；这是输出长度控制，不是风控参数

参数建议

下面这些建议值主要是为了让 MCP 的行为更克制、更可解释，不是因为搜索结果数本身会直接暴露“使用 AI”。

search_xiaohongshu.limit
- 默认 10
- 推荐 10-20
- 主要影响单页结果里返回多少条，不会像评论翻页那样明显增加交互强度
get_note_detail.max_comments
- 默认 10
- 推荐 10-20
- 20-50 视为更深评论抓取
- 服务端硬上限 50
search_zhihu.limit
- 默认 10
- 推荐 5-10
get_zhihu_question.limit
- 默认 5
- 推荐 3-5
get_zhihu_question.max_content_length
- 默认 10000
- 用于控制输出长度和 token 成本，不属于风控核心参数

所有错误返回统一 JSON，包含 retryable 字段供 agent 判断是否重试。

错误码	含义	可重试	怎么办
`login_required`	未登录	✗	调用 login tool
`login_timeout`	登录超时	✓	重新登录
`search_timeout`	搜索超时	✓	稍后重试
`search_blocked`	搜索结果异常为空	✗	检查无头模式、风控或重新登录
`risk_cooldown_active`	风控冷却中	✗	等待冷却结束或清空状态后重测
`browser_init_failed`	浏览器启动失败	✗	`stride28-search-mcp install-browser`
`browser_crashed`	浏览器崩溃	✗	重启 MCP Server
`captcha_detected`	验证码拦截	✗	等待后重试
`unknown_error`	未知错误	✗	查看日志

变量	默认值	说明
`STRIDE28_SEARCH_MCP_HOME`	`~/.stride28-search-mcp`	数据目录
`STRIDE28_SEARCH_MCP_PROFILE`	`""`	浏览器 profile 名；为空时走兼容模式，共享默认目录，不推荐
`STRIDE28_XHS_HEADLESS`	`false`	小红书非登录工具默认有头，优先降低风控
`STRIDE28_ZHIHU_HEADLESS`	`true`	知乎默认无头
`STRIDE28_SEARCH_MCP_HEADLESS`	`true`	兼容旧版本的全局 fallback，不再是主推荐配置
`STRIDE28_RATE_LIMIT_SECONDS`	`5.0`	请求最小间隔（秒）
`STRIDE28_XHS_RISK_COOLDOWN_SECONDS`	`900`	小红书命中风控后的冷却时长（秒）

小红书状态机

未登录：search_xiaohongshu / get_note_detail 返回 login_required
已登录：允许搜索和详情读取
搜索被拦截：返回 search_blocked
风控冷却中：返回 risk_cooldown_active，默认冷却 15 分钟

首次测试建议

先确认环境：

stride28-search-mcp doctor

如果你要回到“新用户第一次安装”的状态：

stride28-search-mcp clear-state xhs
stride28-search-mcp clear-state zhihu

或一次清空全部：

stride28-search-mcp clear-state all

推荐测试顺序：

为当前客户端设置独立 STRIDE28_SEARCH_MCP_PROFILE
运行 stride28-search-mcp doctor，确认 profile、浏览器目录、cookie 库路径、小红书/知乎 headless 设置、风控冷却状态正确
先调用 login_xiaohongshu，不扫码时不应返回成功
再调用 search_xiaohongshu，未登录时必须返回 login_required
完成登录后再次搜索，若仍空结果会明确返回 search_blocked 或 captcha_detected
get_note_detail 默认只返回较少评论；如需更深评论翻页，请显式提高 max_comments
知乎同理，先 login_zhihu 再 search_zhihu

测试策略

日常回归优先跑离线测试：认证状态机、快照回放、限流/熔断测试
真实平台只保留 1 个低频人工 canary 账号
canary 每次只做 1 次登录验证 + 1 次搜索 + 1 次详情验证
不建议拿多个小号做批量压测，也不要做连续自动回归

开发

详见 ARCHITECTURE.md

License

MIT

Available Tools

8 tools

get_note_detailA

获取小红书笔记的完整详情，包括正文、评论、图片、互动数据。需要提供 note_id 和 xsec_token（从搜索结果中获取）。需要先登录（login_xiaohongshu）。默认仅返回较少评论；如需更深评论翻页，请显式提高 max_comments。

ParametersJSON Schema

Name	Required	Description	Default
`note_id`	Yes
`xsec_token`	No
`max_comments`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

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 need for login, the default comment limit, and the function of max_comments for pagination. It also reveals that xsec_token is obtained from search results, implying an interdependent workflow. It does not cover error cases or rate limits, but overall provides sufficient behavioral context.

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 paragraph (60 characters) that front-loads the purpose, then prerequisites, then behavioral details. Every sentence adds value without repetition or filler.

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 existence of an output schema, the description adequately covers what the tool does, required/optional inputs, prerequisite login, and comment pagination. It does not mention error conditions or missing xsec_token behavior, but overall provides enough context for an agent to use correctly.

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 has 0% description coverage, so description must compensate. It adds meaning: note_id is the note ID, xsec_token comes from search results, and max_comments controls comment depth with a default of 10. This is valuable beyond schema, especially for xsec_token which has no schema documentation.

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 complete details of a Xiaohongshu note, specifying verb '获取' and resource '笔记详情', and lists content types (text, comments, images, interaction data). This distinguishes it from sibling tools like search or login functions.

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 explicit prerequisites: login required (login_xiaohongshu) and that note_id/xsec_token come from search results. It also explains default comment count and how to get more. However, it does not explicitly state when not to use or list alternatives, though no direct alternatives exist among siblings.

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

get_zhihu_questionA

获取知乎问题的详情和 top N 回答。当前需要先登录（login_zhihu）。需要提供 question_id（从搜索结果的 xsec_token 字段获取）。

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`question_id`	Yes
`max_content_length`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

The description discloses the prerequisite of logging in and the need for a specific parameter (question_id from xsec_token). It implies read-only behavior ('获取' means fetch), but does not mention rate limits, error handling, or other constraints. Annotations are absent, so the description carries full burden, which it partially meets.

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, using two sentences: the first states the purpose, the second provides prerequisites. Each sentence adds value without 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?

While the description effectively conveys the main purpose and prerequisites, it omits explanations for the limit and max_content_length parameters. Given the tool has three parameters and no schema descriptions, the description is not fully complete. An output schema exists but doesn't alleviate the need for parameter clarification.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning only for the question_id parameter, explaining it comes from search results. It does not explain the limit or max_content_length parameters. With 0% schema description coverage, the description should compensate but fails to cover two out of three parameters.

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 explicitly states the tool fetches details and top N answers of a Zhihu question, using clear verb and resource. It distinguishes from sibling tools like search_zhihu (searching) and login_zhihu (authentication) by implying this tool is used after searching and logging in.

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 clear context: login is required first, and the question_id comes from search results. This implicitly guides when to use the tool (after login and search) but does not explicitly mention alternatives or scenarios where it should not be used.

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

login_xiaohongshuA

登录小红书账号。调用后会弹出浏览器窗口，需要用户使用小红书 App 手动扫码完成登录。扫码后耗时约 10-30 秒完成登录流程，总超时 5 分钟。登录成功后，后续搜索调用将使用新的登录态。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description effectively discloses key behaviors: browser popup, manual QR scan, time estimate (10-30 sec), timeout (5 min), and effect on future searches. No mention of error handling or session persistence, but core behavior is well covered.

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?

Three sentences, no redundancy. Each sentence adds unique value: action, process, timing, and outcome. Efficient and front-loaded.

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?

The description covers the login flow comprehensively given no parameters and an output schema. It explains the user interaction and consequences. Slightly lacking detail on return value (handled by output schema) and preconditions, but minor.

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 input schema has zero parameters with 100% coverage, so baseline 4 applies. The description adds no parameter documentation but none is needed; it focuses on behavioral context.

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 '登录小红书账号' (login to Xiaohongshu account), a specific verb and resource. It distinguishes from siblings like login_zhihu (different platform) and reset_xiaohongshu_login (different action). Detailed process (browser popup, QR scan) adds precision.

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 before searches ('后续搜索调用将使用新的登录态') but does not explicitly state when to use or not use this tool vs alternatives. No prerequisites (e.g., app required) mentioned. Sibling reset_xiaohongshu_login is present but not contrasted.

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

login_zhihuA

登录知乎账号。调用后会弹出浏览器窗口，需要手动登录。登录成功后，search_zhihu 和 get_zhihu_question 都会复用登录态。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

The description discloses the key behavioral trait of opening a browser window and requiring manual intervention. It also mentions that other tools reuse the login state, indicating statefulness. No annotations exist to contradict this.

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 with two sentences. It front-loads the purpose and then provides the critical behavioral detail. Every sentence adds value with no redundancy.

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?

The description covers the essential: purpose, behavior (popup, manual login), and impact on other tools. It lacks mention of error handling or failure scenarios, but given the simplicity of the tool (no params), it is mostly complete.

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?

There are no parameters in the input schema, and the description does not need to add parameter details. It implicitly communicates that no arguments are required, which is sufficient given the empty schema and 100% coverage.

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 'login' and the resource 'Zhihu account'. It distinguishes from sibling tools like login_xiaohongshu and reset_zhihu_login by specifying the platform and behavior.

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 explicitly mentions that calling this tool will open a browser window requiring manual login, and that successful login enables other tools. It does not explicitly state when not to use it, but the context of being a prerequisite for other Zhihu tools implies appropriate usage.

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

reset_xiaohongshu_loginA

清空当前 profile 下的小红书浏览器状态目录，用于重新走首次登录流程。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided. The description mentions clearing the state directory, which is a destructive action, but lacks details on side effects (e.g., losing cookies, impact on other profiles) or warnings about consequences.

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?

Single sentence, front-loaded with action and resource, no unnecessary text.

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 zero-parameter tool with an output schema, the description is nearly complete. Could optionally mention the return value or success indication, but not required.

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?

No parameters exist, schema coverage is 100%. The description adds meaning by clarifying what state is cleared (browser state directory for Xiaohongshu).

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 uses specific verb '清空' (clear) and resource '小红书浏览器状态目录', and distinguishes from sibling tools like login_xiaohongshu and reset_zhihu_login.

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 states it is used to re-run the first login process (用于重新走首次登录流程), implying usage context, but does not explicitly state when not to use it or provide alternatives.

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

reset_zhihu_loginA

清空当前 profile 下的知乎浏览器状态目录，用于重新走首次登录流程。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses the destructive nature ('清空') but does not mention prerequisites, side effects, or whether authentication is needed. Barely adequate.

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?

A single, front-loaded sentence that conveys action and purpose with zero waste. Highly concise.

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?

The tool is simple with no parameters and an output schema exists. The description explains the action but does not mention return values or post-conditions. Adequate for a low-complexity tool.

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?

There are no parameters (0 params, 100% schema coverage). The description adds no parameter info since none exist. Baseline for zero-param tools is 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's action ('清空当前 profile 下的知乎浏览器状态目录') and its purpose ('用于重新走首次登录流程'). It distinguishes from siblings like 'login_zhihu' and 'reset_xiaohongshu_login'.

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 implies when to use (when resetting login state) but does not explicitly state when not to use or mention alternatives. Context from sibling tools provides some guidance.

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

search_xiaohongshuA

搜索小红书笔记内容。返回标题、URL、作者、点赞数等信息。limit 建议 10-20 条。需要先登录（login_xiaohongshu），未登录时返回 login_required 错误。

ParametersJSON Schema

Name	Required	Default
`limit`	No
`query`	Yes
`note_type`	No	all

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/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 login requirement and login_required error, and mentions returned fields. However, it does not state whether the operation is read-only, any rate limits, pagination, or other side effects. Adequate but not comprehensive.

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?

Three sentences, front-loaded with purpose and return info, then usage guidance. No redundant words. Highly efficient.

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?

The description covers basic purpose, return fields, and login requirement, but misses explanations for all parameters and possible behaviors like pagination or sorting. Given an output schema exists (not shown), it's acceptable but could be more thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description only adds a limit suggestion. It does not explain the query or note_type parameters, nor their expected formats or values. The description fails to compensate for the lack of schema descriptions.

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 searches Xiaohongshu notes and lists returned fields (title, URL, author, likes). It distinguishes from sibling tools like get_note_detail (which gets a single note) and search_zhihu (different platform).

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 explicitly recommends limit 10-20 and states the login prerequisite (login_xiaohongshu) and error behavior when not logged in. It lacks explicit when-not-to-use or alternatives, but still provides clear context.

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

search_zhihuA

搜索知乎内容（问答、专栏、视频）。当前需要先登录（login_zhihu），未登录时返回 login_required 错误。返回标题、URL、类型、赞数、作者等信息。

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

Discloses requirement for authentication and specific error response. No annotations provided, so description carries burden. Describes return fields (title, URL, type, likes, author). Could mention pagination or sorting, but adequate for basic transparency.

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 states purpose and scope, second covers prerequisite and return info. No filler, front-loaded.

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?

Describes return fields and prerequisite, but lacks details on pagination, sorting, complete error scenarios, and output schema (though output schema exists). Moderately complete for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage. The description does not explain the 'limit' parameter or its default value. Only 'query' is implied. Parameter semantics are insufficient.

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?

Clearly states the verb '搜索' (search), resource '知乎内容' (Zhihu content), and scope '问答、专栏、视频' (Q&A, columns, videos). This distinguishes it from sibling tools such as search_xiaohongshu.

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?

Explicitly mentions prerequisite of logging in via login_zhihu and error behavior if not logged in. Also states what information is returned. However, it does not compare to alternatives like get_note_detail or get_zhihu_question.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv0.2.1Jun 26, 2026
- First observedget_note_detail
- First observedget_zhihu_question
- First observedlogin_xiaohongshu
- First observedlogin_zhihu
- First observedreset_xiaohongshu_login
- First observedreset_zhihu_login
- First observedsearch_xiaohongshu
- First observedsearch_zhihu

Deploy Server

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

TDQS

A4.3/5.0

Scored 2026-06-26 09:16 across 8 tools

Disambiguation5/5

Each tool targets a specific platform and action, with no overlap. The tools are clearly separated by platform (xiaohongshu vs zhihu) and operation (search, get detail, login, reset), making it easy for an agent to select the correct tool.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using underscore_case. The naming is systematic per platform: search_<platform>, get_<resource>, login_<platform>, reset_<platform>_login. Minor variation (get_note_detail vs get_zhihu_question) does not cause confusion.

Tool Count5/5

With 8 tools covering two platforms, the count is well-scoped. Each tool serves a distinct purpose, and there are no redundant or missing essential operations. The tool set is neither too sparse nor too heavy.

Completeness5/5

The set covers the full lifecycle for searching and retrieving content from both platforms: login, search, get detail, and reset login. There are no obvious gaps for the intended use case of searching and reading content. The tools work together seamlessly.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

blbl147-xhs-mcpOAuth
ai.smithery
搜索笔记、浏览首页推荐、查看笔记内容与评论，并发表你的评论。直接在工作流中与小红书内容互动，高效跟进话题。
Social Media Note Taking Content Management Systems
2
SocialDataX 小红书 Xiaohongshu XHS RedNote MCP A
com.52choujiang
XHS note/product search/detail, suggestions, comments/replies; PGY 20pts success, failures uncharged
Social Media Search Research & Data
253
SocialListeningAPIOAuth
com.sociallisteningapi
Search public social posts and web results from AI assistants.
Social Media Search
1
SearchPipe A
tech.searchpipe
Real-time web search for AI agents: ranked results, source URLs, and optional AI answers.
Search Browser Automation Agent Orchestration
11

Related MCP Servers

RedNote MCP
Web Scraping Browser Automation Search
MilesCool
A
license
B
quality
F
maintenance
Enables users to search and retrieve content from Xiaohongshu (Red Book) platform with smart search capabilities and rich data extraction including note content, author information, and images.
Updated a year ago (2025-06-26 10:37 UTC)
1
52 npm
28
MIT
RedNote MCP
iFurySt
A
license
Not graded
quality
D
maintenance
Enables searching and accessing Xiaohongshu (RedNote) content via natural language, with cookie-based authentication for note retrieval and keyword search.
Updated a year ago (2025-05-11 12:30 UTC)
52 npm
1,107
MIT
xiaohongshu-mcp
Social Media Search Content Management Systems
Lozzi1910
A
license
A
quality
F
maintenance
Enables AI assistants to search, browse, and publish notes on Xiaohongshu (Little Red Book) via MCP tools.
Updated 3 months ago (2026-06-04 04:49 UTC)
8
AGPL 3.0
rednote-crawler
Browser Automation Web Scraping Social Media
yangsijie666
F
license
Not graded
quality
D
maintenance
Enables AI assistants to search and collect data from Xiaohongshu/REDnote, including notes, comments, and user info, with dual-layer anti-detection and persistent login.
Updated 7 months ago (2026-02-28 10:34 UTC)
17
-

演示

Kiro + MCP 搜索

WorkBuddy + MCP 自动化（即将推出）

使用场景

安装

配置

search_xiaohongshu

get_note_detail

search_zhihu

get_zhihu_question

推荐使用方式

参数建议

小红书状态机

首次测试建议

测试策略

开发

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers