zhihu-scraper-mcp

by luyanhexay

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.1.0
Disambiguation5/5
Each of the 6 tools has a unique, non-overlapping purpose: four discovery endpoints (questions/articles/users/topics) and two retrieval endpoints (full text/comments). The overlap-prone tool is get_fulltext, which gracefully handles multiple URL types through explicit, well-documented auto-detection rather than ambiguity. The distinct search_* endpoints use the resource type (question/article/user/topic) as an unambiguous differentiator.
Naming Consistency5/5
All tools consistently follow a lowercase snake_case verb_noun convention. The 'search_' prefix uniformly denotes list-returning queries, while 'get_' denotes content retrieval with a specific identifier, which is a clear and conventional semantic split. No mixing of casing styles or verb forms exists, creating a predictable, learnable API.
Tool Count5/5
Six tools is a well-scoped number for this domain: each tool serves a distinct, non-overlapping function, avoiding both under-powered overloading and needless fragmentation. The search endpoints could theoretically be merged, but keeping them separate preserves type-specific return schemas (e.g., questions include answer count, articles include author/abstract) without parameter bloat. Similarly, get_fulltext's auto-detection responsibly consolidates several potential get_* tools into one ergonomic interface.
Completeness4/5
For a read-only scraper, the surface is well-considered, covering discovery (all four primary Zhihu entities), full-content retrieval, and comment trees, which addresses the core use cases end-to-end. Minor gaps exist, such as no dedicated structured user profile endpoint or trending/hot-topic access, but these fall outside the stated purpose. Overall, the 4 search + 2 fetch design is coherent and fully functional for its intended role.
Average 4.1/5 across 6 of 6 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations, the description must disclose behavioral traits. It states the output includes nested comments, likes, author, and time, but does not mention any side effects, limitations, or error handling. There is no mention of potential rate limits or partial results, leaving ambiguity about the tool's behavior.
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 sentence that efficiently conveys the tool's purpose and output contents without unnecessary detail. It is well-structured and easy to understand.
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 provides some context by listing the included data (nested comments, likes, author, time), but it does not clarify the impact of the 'max' parameter on the 'complete tree' claim, nor does it explain the output structure or error behavior. This leaves some gaps in understanding the tool's full context.
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 schema provides descriptions for all three parameters, but the tool description itself does not add meaning. It claims to return a 'complete comment tree', yet the 'max' parameter limits the number of root comments, creating a potential contradiction and leaving parameter behavior unclear beyond the schema.
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 function: it retrieves the complete comment tree under any Zhihu content, including nested sub-comments, like counts, author, and time. This uses a specific verb '获取' and specifies the resource and scope, making the purpose unambiguous.
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?
The description provides no guidance on when to use this tool versus alternatives such as search_questions or search_articles. It only describes what it does without indicating appropriate use cases or when not to use it.
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?
没有注释，描述承担全部披露责任。描述了返回内容，并提示关键词过长可能导致空结果，这是行为特征。但未提及是否存在认证、速率限制等潜在问题，也未明确声明为只读操作（虽然搜索通常无副作用）。
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?
描述只有一句话，信息集中，直接点出目的、返回内容和关键使用提示，没有任何冗余。
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?
工具简单，两个参数均已在模式中说明，无输出模式但描述已列出返回字段，足够让代理理解调用预期。但缺少返回值排序或分页等细节，不过对于搜索工具尚可。
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?
输入模式对参数的描述覆盖率100%，描述额外补充了关键词使用建议（≤3词），这是模式本身未提供的实用语义，有助于代理正确调用。
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?
描述明确指定了动词'搜索'和资源'知乎文章（专栏）'，并列出返回内容（标题、作者、摘要、URL），与兄弟工具（search_questions、search_users等）在类型上明显区分。
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?
描述提供了具体的何时使用建议（关键词精简≤3词），但没有明确说明与兄弟工具的适用场景区分，例如何时应该用search_questions而非此工具。不过对于搜索类工具，关键词长度提示已经是有效指导。
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?
无注释，描述提示关键词过长易返回空，提供了行为预期，但未说明权限、速率限制或结果排序等深层行为，仅基本覆盖。
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?
两句话，简洁无冗余，第一句直接说明功能，第二句补充使用场景和注意事项，结构合理。
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?
对于搜索工具，描述了返回内容和入口用途，且schema定义了参数，无输出schema但描述已涵盖主要返回字段，上下文基本完整，但未提及分页或最大条数限制。
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覆盖100%但描述额外补充了关键词精简（≤3词）的实用建议，超出schema本身的信息，对agent选择参数有增值。
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?
描述明确说明'按关键词搜索知乎问题'，动词（搜索）+资源（问题）具体，并列出返回字段（标题、描述、回答数等），与兄弟工具（search_articles等）区分明显。
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?
描述指出'适合需要精确问题列表'并作为后续get_fulltext/get_comments的入口，提供了使用场景，但未明确何时不使用此工具或与其他搜索工具的对比排除。
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 the full burden. It discloses an important behavioral quirk: overly long keywords may return empty results. However, it does not describe return format, pagination, or any side effects, though the verb 'search' implies read-only. This adds some transparency but not comprehensive disclosure.
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 two short sentences, with the core purpose stated first and the usage tip second. Every word earns its place, and there is no redundancy 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?
For a simple search tool with two parameters and no output schema, the description is reasonably complete. It states the purpose and a practical constraint. Given sibling tools provide context, it does not need to over-explain. However, it lacks explicit mention of what the return data looks like, though this is not critical for a search endpoint.
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 already covers both parameters with descriptions (query: required keyword, max: max results default 10), so schema coverage is 100%. The description adds value by advising to keep keywords ≤3 words, which directly informs how to use the 'query' parameter, going beyond the schema's basic semantics.
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 '按关键词搜索知乎话题' (search Zhihu topics by keyword), with a specific verb (search) and resource (Zhihu topics). This distinguishes it from sibling tools like search_questions and search_articles, which target different content types.
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 for searching topics, and the keyword-length tip ('关键词精简，≤3 词，过长易返回空') gives practical usage guidance. However, it does not explicitly mention when to use this tool over alternatives or any exclusion criteria, so it falls short of a 5.
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 provided, the description carries the burden of behavioral disclosure. It adds a valuable note about keyword length affecting results, but it does not mention other behaviors such as rate limits, authentication, or pagination. For a simple read-only search, this is reasonable, but not exhaustive.
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, compact sentence that states the purpose and key return fields upfront, followed by a practical tip. No unnecessary words or repetition.
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 two-parameter search tool without an output schema, the description sufficiently outlines what is returned (nickname, bio, followers, URL) and provides a usage tip. While pagination or sort order are not discussed, they are not critical for this simple operation.
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% with descriptions for both parameters. The description adds an extra semantic hint about the 'query' parameter (keep it concise), which is beyond the schema's generic description. This adds value, so a score of 4 is warranted.
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 Zhihu users by keyword and lists the returned fields (nickname, bio, followers, homepage URL). It distinctly names the resource (users) and differentiates from sibling tools like search_questions and search_articles by specifying the entity type.
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 actionable guidance on keyword length (≤3 words, too long often returns empty), which helps the agent set expectations. It implies usage context (for finding users) but does not explicitly state when not to use it or mention alternatives; however, the tool name and description make the primary use case unambiguous.
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 the burden of behavioral disclosure. It reveals the output is Markdown, explains question URLs return merged fulltext of all answers, and discloses an important URL-format/risk-control nuance. Minor omission: the schema mentions '想法' (plans/ideas) URLs, but the description only lists answer/article/question, creating slight ambiguity.
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 concise and front-loaded; each sentence contributes: purpose, behavior, and a critical URL-format warning. No filler or duplicated schema content.
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 single-parameter tool with no output schema and no annotations, the description is fairly complete. It covers input types, processing behavior, output format, and a usage caveat. It could be more complete by explicitly mentioning 想法-URL handling and any error/rate-limit behavior, but the key decision-impacting context is present.
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 already describes 'url' as covering Zhihu content URL types, so baseline is 3. The description adds meaningful beyond-schema detail: auto-detection of content type, exact behavior for different URL forms, and which answer URL format is recommended to avoid HTTP-blocking, adding enough value to rate above baseline.
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?
Description clearly states the tool retrieves the full Markdown body of a Zhihu answer/article/question, with specific verb '获取' and resource '知乎回答/文章/问题'. It differentiates from sibling search and comment tools by focusing on full-text retrieval rather than discovery or comment fetching.
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?
Provides explicit usage context: '传入 URL 即可' and auto-detects content type, with a precise URL format caveat for answers to avoid risk-control issues. It does not explicitly name alternatives like search tools or get_comments, but the purpose is clear enough that when to use it is implied.
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:

[![zhihu-scraper-mcp MCP server](https://glama.ai/mcp/servers/luyanhexay/zhihu-scraper-mcp/badges/card.svg)](https://glama.ai/mcp/servers/luyanhexay/zhihu-scraper-mcp)

Score Badge

Copy to your README.md:

[![zhihu-scraper-mcp MCP server](https://glama.ai/mcp/servers/luyanhexay/zhihu-scraper-mcp/badges/score.svg)](https://glama.ai/mcp/servers/luyanhexay/zhihu-scraper-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/luyanhexay/zhihu-scraper-mcp'

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