Skip to main content
Glama
deenesjakoruzh
luyanhexay

zhihu-scraper-mcp

by luyanhexay
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

知乎 Scraper MCP Server

MCP クライアントに知乎の本文全文、完全なコメントツリー、タイプ別検索の読み取り機能を提供する MCP Server です。

これは zhihu-toolkit CLI（zhihu コマンド）の薄いラッパーです。各ツールは CLI の --json インターフェースを呼び出し、結果を簡潔な構造にトリミングしてから返すため、アバター/HTML/冗長なタイムスタンプなどのフィールドでモデルのコンテキストが圧迫されるのを防ぎます。

3つの機能に特化しています：回答/記事の全文、完全なコメントツリー、タイプ別の正確な検索——正確なリストが必要で、本文やコメントを取得したいシーンに適しています。

機能概要

ツール

役割

search_questions

キーワードで質問を検索（タイトル/説明/回答数/閲覧数/フォロー数/URL）

search_articles

キーワードで記事（コラム）を検索

search_users

キーワードでユーザーを検索

search_topics

キーワードでトピックを検索

get_fulltext

URL を受け取り、回答/記事の完全な本文（Markdown）を返します。質問 URL の場合は、その下の全回答を結合した全文を返します

get_comments

任意のコンテンツの完全なコメントツリー（ネストされた子コメント、いいね、作者、時刻を含む）を返します

Related MCP server: zhihu-mcp

環境要件

  • Python 3.12+

  • uv

  • 知乎のログイン状態（Cookie）。zhihu auth paste でインポートします。本 Server は認証情報を管理・保存しません。

クイックスタート

詳細は INSTALL.md（Claude Code / Agent の自己インストール向け）を参照してください。ツールの詳細なパラメータと使用上の推奨事項は USAGE.md を参照してください。

ワンライナー版：

git clone https://github.com/luyanhexay/zhihu-scraper-mcp.git
cd zhihu-scraper-mcp
uv sync --locked
.venv/bin/zhihu auth paste     # 粘贴浏览器 DevTools 复制的 cURL，Ctrl+D 结束

次に Claude Code に登録します（<ABS> をこのリポジトリの絶対パスに置き換えてください）：

claude mcp add zhihu-scraper -- <ABS>/.venv/bin/zhihu-scraper-mcp

認証情報とプライバシー

  • 認証情報は zhihu CLI によって ~/.zhihu-cli/ に保存されます。このリポジトリ内にはありません。

  • このリポジトリには Cookie は一切含まれません。.gitignore は cookies.json などのファイルも追加で無視し、誤ってコミットされるのを防ぎます。

  • このリポジトリを配布してもあなたの知乎アカウントが漏洩することはありません。利用者は各自のログイン状態を自分でインポートする必要があります。

既知の問題

  • 個別回答の HTML エンドポイントは、知乎のリスクコントロール（__zse_ck）によってしばしばブロックされます。get_fulltext は自動的に「質問 API から該当する回答を抽出する」パスにフォールバックするため、可能な限り /question/<id>/answer/<id> を含む完全な回答 URL を渡してください。

  • 検索キーワードは簡潔に（≤3 語）。長すぎると空の結果が返りやすくなります。

  • リスクコントロールが発動した場合は、まずブラウザで検証を完了してから、zhihu auth paste を実行し直してログイン状態を更新してください。

謝辞

License

MIT

Available Tools

6 tools
get_commentsB

获取任意知乎内容（回答/文章/问题）下的完整评论树，含嵌套子评论、点赞数、作者与时间。

ParametersJSON Schema
NameRequiredDescriptionDefault
maxNo最多抓取的根评论数，默认 20
urlYes知乎内容 URL（必填）
sortNo排序方式，默认 likeslikes

TDQS

B3.2/5.0
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.

get_fulltextA

获取一篇知乎回答/文章/问题的完整正文（Markdown）。传入 URL 即可，自动识别类型：回答与文章返回单篇全文；问题 URL 返回其下全部回答的合并全文。回答请用含 /question//answer/ 的完整 URL（裸 /answer/ 的 HTML 端点可能被风控）。

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes知乎内容 URL（回答/文章/问题/想法）

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

search_articlesA

按关键词搜索知乎文章（专栏），返回标题、作者、摘要与 URL。关键词精简（≤3 词，过长易返回空）。

ParametersJSON Schema
NameRequiredDescriptionDefault
maxNo最多返回条数，默认 10
queryYes搜索关键词（必填）

TDQS

A4.2/5.0
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.

search_questionsA

按关键词搜索知乎问题，返回问题标题、描述、回答数、浏览量、关注数与 URL。关键词精简（≤3 词，过长易返回空）。适合需要精确问题列表，或作为后续 get_fulltext / get_comments 抓正文、评论的入口。

ParametersJSON Schema
NameRequiredDescriptionDefault
maxNo最多返回条数，默认 10
queryYes搜索关键词（必填）

TDQS

A4.2/5.0
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.

search_topicsA

按关键词搜索知乎话题。关键词精简（≤3 词，过长易返回空）。

ParametersJSON Schema
NameRequiredDescriptionDefault
maxNo最多返回条数，默认 10
queryYes搜索关键词（必填）

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

search_usersA

按关键词搜索知乎用户，返回昵称、简介、粉丝数与主页 URL。关键词精简（≤3 词，过长易返回空）。

ParametersJSON Schema
NameRequiredDescriptionDefault
maxNo最多返回条数，默认 10
queryYes搜索关键词（必填）

TDQS

A4.2/5.0
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.

Tool Schema Changelog

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

  1. 6 tool updatesv0.1.0
    • First observedget_comments
    • First observedget_fulltext
    • First observedsearch_articles
    • First observedsearch_questions
    • First observedsearch_topics
    • First observedsearch_users
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/5.0

Scored across 6 tools

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.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Zhihu MCP Server

    chemany
    F
    license
    Not graded
    quality
    D
    maintenance
    A simple HTTP API server that allows users to publish articles, create answers, manage columns, and upload images on Zhihu (a Chinese Q&A platform) through straightforward REST API endpoints.
    8
    -

  • zhihu-mcp

    alizeeblack-code
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to search, read, and analyze Zhihu content including questions, answers, comments, and user activities through the MCP protocol.
    5
    MIT

  • ZhihuMCP

    WloBy-Labs
    F
    license
    A
    quality
    B
    maintenance
    Read-focused MCP server for Zhihu, enabling retrieval of pins, articles, comments, and replies, with optional limited write tools for drafting and editing answers.
    10
    1
    -

  • zotero-cli-agent

    semantic-craft
    A
    license
    Not graded
    quality
    C
    maintenance
    A lightweight, context-efficient CLI and optional stdio MCP server for semantic search, browsing, and writing to your Zotero library.
    BSD 3-Clause