Stride28 Search MCP

by BrunonXU

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.1
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.
Average 4.1/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on April 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Stride28-search-mcp MCP server](https://glama.ai/mcp/servers/BrunonXU/Stride28-search-mcp/badges/card.svg)](https://glama.ai/mcp/servers/BrunonXU/Stride28-search-mcp)

Score Badge

Copy to your README.md:

[![Stride28-search-mcp MCP server](https://glama.ai/mcp/servers/BrunonXU/Stride28-search-mcp/badges/score.svg)](https://glama.ai/mcp/servers/BrunonXU/Stride28-search-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BrunonXU/Stride28-search-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server