Provides tools for searching and browsing Douban content including books, movies, TV shows, and group discussions. Enables retrieving reviews, searching by ISBN or keywords, and accessing group topic details.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Douban MCP Server search for the book 'The Three-Body Problem'"
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.
这个 MCP 服务器提供了与豆瓣内容交互的功能，包括图书、电影、电视剧和小组讨论等。
书籍：搜索、查看图书评论
电影、电视剧：搜索、查看评论
小组讨论：列出话题、查看话题详情
Related MCP server: Stride28 Search MCP
search-book
从豆瓣搜索图书信息
输入参数:
isbn (字符串, 可选): 图书的 ISBN 编号
q (字符串, 可选): 图书标题的搜索关键词
list-book-reviews
获取豆瓣图书评论
输入参数:
id (字符串): 豆瓣图书 ID
search-movie
从豆瓣搜索电影、电视剧信息
输入参数:
q (字符串): 电影、电视剧标题的搜索关键词
list-movie-reviews
获取豆瓣电影评论
输入参数:
id (字符串): 豆瓣电影 ID
list-tv-reviews
获取豆瓣电视剧评论
输入参数:
id (字符串): 豆瓣电视剧 ID
browse
在默认浏览器中打开图书详情页
输入参数:
id (字符串): 豆瓣图书 ID
list-group-topics
列出豆瓣小组话题
输入参数:
id (字符串, 可选): 豆瓣小组 ID (默认为 '732764')
tags (字符串数组, 可选): 按标签筛选话题
from_date (字符串, 可选): 按日期筛选话题 (格式: "YYYY-MM-DD")
get-group-topic-detail
获取特定话题的详情
输入参数:
id (字符串): 豆瓣话题 ID
克隆仓库
安装依赖: npm install
构建服务器: npm run build
启动服务器: npm start
要将此服务器与桌面应用集成，请将以下内容添加到应用的服务器配置中，部分API需要用到COOKIE，请自行获取。:
{
"mcpServers": {
"douban-mcp": {
"command": "node",
"args": [
"{文件的绝对路径}/dist/index.js"
],
"env": {
"COOKIE": "bid=;ck=;dbcl2=;frodotk_db=;" // 从网站获取 cookie 值
}
}
}
}构建: npm run build
监视模式: npm run dev
启动: npm start
测试: npm test
@modelcontextprotocol/sdk: MCP SDK
dayjs: 日期库
json2md: JSON 转 Markdown 转换器
turndown: HTML 转 Markdown 转换器
zod: TypeScript 优先的模式验证
本项目采用 MIT 许可证。
open default browser and browse douban book detail
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | douban book id, e.g. "1234567890" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it opens a browser, but it does not explain the return value, whether it blocks, or any side effects beyond launching the browser. With no annotations, the description carries the full burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loaded with the action 'open'. It is highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description is minimally adequate, but it lacks information about what the tool returns or does after opening the browser. No output schema exists, so this information should be in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single 'id' parameter as a Douban book ID. The description adds no additional semantic detail, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it opens the default browser to browse a Douban book detail page, which is a specific action and resource. It distinguishes from sibling tools that search or fetch data, though 'browse' is somewhat generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like search-book or get-movie-detail. It does not mention use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get group topic detail
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | douban group topic id, e.g. "1234567890" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. However, it only states 'get group topic detail' without revealing any behavioral traits such as side effects, error handling, authorization needs, rate limits, or return format. This is a complete absence of behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than genuine conciseness. It merely repeats the tool name and provides no valuable information, so it does not earn its place in the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and the existence of sibling tools that could be confused with this one, the description is incomplete. It fails to explain what a group topic detail includes, how it relates to list-group-topics, or any edge cases, leaving significant gaps in a simple tool context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single 'id' parameter with a description and example, giving 100% coverage. The tool description adds no additional meaning to the parameter, so it meets the baseline of 3 as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'get group topic detail' is simply the tool name with spaces, restating the name without adding any semantic content. It is tautological, similar to the 'Process' example, and does not provide a clear, informative purpose beyond what the name already implies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list-group-topics or get-movie-detail. The description gives no context about use cases, prerequisites, or situations to avoid, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list book reviews
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | douban book id, e.g. "1234567890" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only says 'list book reviews' and does not mention read-only nature, pagination, authentication, or any other behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified rather than concise. It provides zero value beyond the tool name and does not earn its place as a useful explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one parameter and no output schema, the description is still inadequate. It lacks any context about the return format, sorting, or scope of reviews listed, and there are no annotations to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'id' parameter has a description). The tool description adds no additional meaning, but the schema already documents the parameter, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'list book reviews' is essentially a tautology of the tool name, restating it without adding any specificity. It fails to distinguish from siblings like list-movie-reviews or list-tv-reviews beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context about selecting book reviews vs. other review types or search capabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list group topics
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | douban group id | |
| tags | No | tags, e.g. ["python"] | |
| from_date | No | from date, e.g. "2024-01-01" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The verb 'list' implies a read operation, but no behavioral traits are disclosed (e.g., pagination, authentication, response format). This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely under-specified, not concise. It repeats the tool name without adding informative content, so it fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 optional parameters, no output schema, and no annotations, the description is inadequate. It doesn't explain what group topics are, how filters like tags or from_date work, or what the response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all three parameters have descriptions). The tool description adds no extra parameter detail, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'list group topics' is a tautology that simply restates the tool name. It does not provide a specific verb+resource that clarifies scope or distinguishes it from sibling tools like 'get-group-topic-detail'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context, prerequisites, or exclusionary statements are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list movie reviews
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | douban movie id, e.g. "1234567890" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries full responsibility for behavioral disclosure. 'List' implies a read-only operation, but it does not disclose pagination, ordering, response format, error behavior, or whether the id parameter must correspond to an existing movie.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but it is under-specified rather than concise. It merely repeats the tool name and omits any valuable context, so its brevity is not a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple one-parameter input, there is no output schema and no mention of return values, ordering, or limits. The description leaves the agent guessing about what data a 'movie review' listing actually contains, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter, 'id', is documented as 'douban movie id' with an example. The tool description does not add parameter-level meaning, but the schema already provides adequate semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'list movie reviews' is a verb+resource statement, but it exactly restates the tool name, adding no new specificity. It does not explain what constitutes a review, scope, or how it differs from similarly named tools like list-tv-reviews or get-movie-detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites (e.g., needing a movie id), no exclusions, and no comparison to sibling tools like search-movie or get-movie-detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list tv reviews
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | douban tv id, e.g. "1234567890" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description provides no behavioral details such as read-only nature, pagination, sorting, authentication requirements, or what the response contains. It merely restates the function name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It repeats the tool name without adding any extra information, making it tautological.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description should explain what reviews are listed, the expected input, and perhaps return format. It fails to do so, offering only a bare phrase that provides no practical guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single required 'id' parameter with an example, so the baseline for parameter semantics is 3. The tool description adds no information about how to use 'id' beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'list tv reviews' clearly states a verb ('list') and a resource ('tv reviews'), and the word 'tv' distinguishes it from sibling tools like list-movie-reviews and list-book-reviews. However, it's minimal and doesn't add any scope or context beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as list-movie-reviews or get-tv-detail. The description doesn't mention any prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search books from douban, either by ISBN or by query
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | query string, e.g. "python" | |
| isbn | No | ISBN number, e.g. "9787501524044" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior. It only states the search action and criteria, omitting key details such as return format, authentication needs, rate limits, or that at least one parameter should be provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the essential purpose and usage modes without any redundant wording. It is an exemplary model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is too thin to fully prepare an agent. It does not describe what the search returns (e.g., list, details), pagination, or other behavioral nuances, making it incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes each parameter with 100% coverage, so the baseline is 3. The description adds value by specifying 'either by ISBN or by query,' implying mutual exclusivity and that at least one is expected, which goes beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (search) on a specific resource (books from douban) and highlights two search modes (ISBN or query). This distinguishes it from sibling search tools like search-movie, which target a different resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it evident this tool is for searching books, differentiating it from movie and TV tools. However, it does not explicitly mention alternatives or when not to use this tool, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search movies or tvs from douban by query
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | query string, e.g. "python" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only states the basic action. It does not disclose behavioral traits such as output format, pagination, or safety considerations (e.g., read-only nature).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It is front-loaded with the verb and resource, capturing the essence efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (one parameter, no output schema), the description is adequate but lacks details on return values or behavior, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the 'q' parameter with an example, and the description's 'by query' adds no additional semantic value. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (search), resource (movies or TVs), and source (Douban), distinguishing it from sibling tools like search-book and get-movie-detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description merely states the function without mentioning exclusions or context such as 'use for finding movies by query, not for details'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0browse2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseget-group-topic-detail2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falselist-book-reviews2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falselist-group-topics2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falselist-movie-reviews2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falselist-tv-reviews2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsesearch-book2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsesearch-movie2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falsebrowseget-group-topic-detaillist-book-reviewslist-group-topicslist-movie-reviewslist-tv-reviewssearch-booksearch-movieScored across 8 tools
Most tools have distinct purposes targeting different Douban resources (books, movies/TVs, groups), but 'search-book' and 'search-movie' could be confused as both handle search operations across media types. The descriptions clarify that 'search-book' is for books only (by ISBN or query) while 'search-movie' covers movies and TVs, but the naming overlap might cause initial ambiguity.
The naming follows a consistent verb_noun pattern (e.g., 'list-book-reviews', 'search-book') with clear, descriptive names. The only minor deviation is 'browse', which uses a single verb without a noun, but this is acceptable as it describes a distinct browser action. Overall, the pattern is highly readable and predictable.
With 8 tools, the server is well-scoped for interacting with Douban's key features (books, movies/TVs, groups). Each tool earns its place by covering essential operations like searching, listing reviews, and browsing details, without being overly broad or too limited for the domain.
The server covers basic search and listing operations for books, movies/TVs, and groups, but has notable gaps in CRUD/lifecycle coverage. For example, there are no tools for creating, updating, or deleting reviews or topics, which limits agent workflows. However, the provided tools allow for core browsing and information retrieval tasks.
Search Chinese books with Douban ratings, AI book guides and curated toplists. Free, no API key.
Search and read public social data from Chinese and global platforms, pay per call.
Search books, authors and series, get recommendations, and manage your own reading shelves.
Search books and authors, fetch editions, browse subjects, and resolve cover images.