Provides tools to search and retrieve information about books, movies, TV shows, and group topics from Douban, including details, reviews, and browsing capabilities.
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 search for the movie Inception"
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.
一个基于 Model Context Protocol (MCP) 的豆瓣数据服务，提供图书、电影、电视剧和小组话题相关查询能力，适合接入 Claude Desktop、Cherry Studio、5ire、MCP Inspector 等支持 stdio 的 MCP 客户端。
本项目面向“工具调用”场景，而不是完整的豆瓣网页封装。当前重点是提供以下几类能力：
图书搜索与图书长评列表
电影 / 电视剧搜索
电影 / 电视剧详情
电影 / 电视剧长评列表
豆瓣小组话题列表与话题详情
在本地默认浏览器中打开豆瓣图书页面
Related MCP server: mcp-server-weread
当前服务实际注册的 MCP tools 如下：
Tool | 说明 |
| 按关键词或 ISBN 搜索图书 |
| 获取图书长评列表 |
| 搜索电影或电视剧 |
| 获取电影详情 |
| 获取电视剧详情 |
| 获取电影长评列表 |
| 获取电视剧长评列表 |
| 在默认浏览器打开图书详情页 |
| 获取小组话题列表 |
| 获取小组话题详情 |
search-book按关键词或 ISBN 搜索图书。q 和 isbn 至少需要提供一个。
参数：
参数 | 类型 | 必填 | 说明 |
|
| 否 | 图书搜索关键词，例如 |
|
| 否 | ISBN 编号，例如 |
返回特点：
返回 Markdown 表格
包含出版时间、书名、作者、评分、豆瓣 ID、ISBN
list-book-reviews获取指定图书的长评列表。
参数：
参数 | 类型 | 必填 | 说明 |
|
| 是 | 豆瓣图书 ID |
返回特点：
返回 Markdown 表格
包含标题、评分、摘要、评论 ID
search-movie搜索电影或电视剧。结果中会同时返回结构化文本摘要和完整 raw_json，便于 LLM 二次解析。
参数：
参数 | 类型 | 必填 | 说明 |
|
| 是 | 电影或电视剧关键词，例如 |
返回特点：
每个结果包含 title、type、year、rating、subtitle、id、uri
末尾附带 raw_json
搜索结果可能同时包含电影和电视剧
get-movie-detail获取电影详情。
参数：
参数 | 类型 | 必填 | 说明 |
|
| 是 | 豆瓣电影 ID，例如 |
返回特点：
返回结构化文本
包含标题、原名、年份、类型、评分、类型标签、国家/地区、语言、上映日期、片长、导演、演员、别名、简介
末尾附带完整 raw_json
get-tv-detail获取电视剧详情。
参数：
参数 | 类型 | 必填 | 说明 |
|
| 是 | 豆瓣电视剧 ID，例如 |
返回特点：
输出结构与 get-movie-detail 一致
末尾附带完整 raw_json
list-movie-reviews获取电影长评列表。
参数：
参数 | 类型 | 必填 | 说明 |
|
| 是 | 豆瓣电影 ID |
返回特点：
返回 Markdown 表格
包含标题、评分、摘要、评论 ID
list-tv-reviews获取电视剧长评列表。
参数：
参数 | 类型 | 必填 | 说明 |
|
| 是 | 豆瓣电视剧 ID |
返回特点：
返回 Markdown 表格
包含标题、评分、摘要、评论 ID
browse在本机默认浏览器中打开图书详情页。
参数：
参数 | 类型 | 必填 | 说明 |
|
| 是 | 豆瓣图书 ID |
说明：
这是本地动作，不返回网页内容
适合在桌面环境中配合 MCP 客户端使用
list-group-topics获取豆瓣小组话题列表，支持按小组、标签、日期过滤。
参数：
参数 | 类型 | 必填 | 说明 |
|
| 否 | 豆瓣小组 ID，默认值为 |
|
| 否 | 标签过滤，例如 |
|
| 否 | 起始日期，格式 |
返回特点：
返回话题列表
适合配合 get-group-topic-detail 继续获取单个话题正文
get-group-topic-detail获取单个豆瓣小组话题详情。
参数：
参数 | 类型 | 必填 | 说明 |
|
| 是 | 豆瓣话题 ID |
返回特点：
返回话题详细内容
包含正文、摘要及相关元数据
为了兼顾“人读”和“模型读”，当前工具输出主要分为两类：
表格型输出：主要用于评论列表和图书搜索，适合直接展示
结构化文本输出：主要用于电影 / 电视剧搜索与详情，字段稳定，并保留 raw_json
如果你在上层 Agent 中需要更可靠地抽取字段，优先使用带 raw_json 的工具输出。
Node.js 18+
支持 stdio 的 MCP 客户端
能访问豆瓣接口的网络环境
部分接口依赖豆瓣 Cookie。未提供有效 Cookie 时，部分请求可能失败、返回不完整，或触发风控。
当前通过环境变量 COOKIE 注入，例如：
export COOKIE='bid=...; ck=...; dbcl2=...; frodotk_db=...;'{
"mcpServers": {
"douban-mcp": {
"command": "node",
"args": [
"/absolute/path/to/douban-mcp/dist/index.js"
],
"env": {
"COOKIE": "bid=...;ck=...;dbcl2=...;frodotk_db=..."
}
}
}
}npm install
npm run build
npm start常用命令：
命令 | 说明 |
| 编译 TypeScript 并生成 |
| 监听编译 |
| 启动 MCP 服务 |
仓库当前包含一个基于 MCP 客户端直连的集成测试脚本：
node tests/mcp-tools.mjs注意：
package.json 里仍保留了 npm test -> jest
当前仓库未看到对应的 Jest 测试配置，实际验证建议优先运行上面的集成脚本
豆瓣接口并非公开稳定官方 MCP 接口，返回结构可能变化
依赖 Cookie 和当前可用网络环境
browse 需要桌面环境，不适合纯无头服务器
README 中列出的能力以当前代码为准，若接口升级请同步更新文档
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.
get movie detail
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | douban movie id, e.g. "1291546" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to state whether the operation is read-only, what data is returned, or any side effects. The description is simply a restatement of the name with no behavioral detail.
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 under-specified rather than genuinely concise. 'get movie detail' contains no useful information that isn't already in the tool name, 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?
The tool is a simple get-by-id operation, but the description is completely inadequate. It does not explain what 'detail' includes, what the return value looks like, or how to handle errors. Given there is no output schema, the description should carry responsibility for explaining the response, and it does nothing.
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 provides full coverage for the single parameter 'id' with a clear description ('douban movie id'). The description adds nothing beyond the schema, but the baseline for high schema coverage is 3, and the schema sufficiently explains the parameter.
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 movie detail' is a tautology that simply restates the tool name. It provides no additional specificity about what kind of detail, what resource is accessed, or how it differs from siblings beyond the name itself.
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 gives no guidance on when to use this tool versus alternatives like search-movie or get-tv-detail. There is no mention of 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 tv detail
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | douban tv id, e.g. "2995166" |
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 reveals nothing about side effects, return format, or safety, making the tool a black box. A minimal description for a read-only operation would at least imply a safe retrieval, but this does not.
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 it is under-specified rather than concise. A good concise description would pack in the tool's purpose, but 'get tv detail' is tautological and provides no value beyond the tool name.
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?
With only one parameter and no output schema, the tool is relatively simple, but the description still fails to specify what 'detail' means or what the agent should expect. The schema covers the input, but the description leaves the purpose and result ambiguous.
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 single 'id' parameter as a Douban TV ID with an example, covering 100% of parameter semantics. The tool description itself adds no parameter information beyond the schema, making the baseline of 3 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 'get tv detail' merely restates the tool name, providing no specific verb+resource beyond the name itself. It fails to distinguish this from sibling tools like 'get-movie-detail' or 'search-movie'.
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 does not mention any context, prerequisites, or exclusions, leaving the agent without information to choose it correctly.
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.
v0.3.0browseget-group-topic-detailget-movie-detailget-tv-detaillist-book-reviewslist-group-topicslist-movie-reviewslist-tv-reviewssearch-booksearch-movieScored across 10 tools
Each tool targets a distinct resource and action: books, movies, TV, or group topics. Even though search-movie covers both movies and TV, the separate detail tools clarify the scope. No two tools appear to do the same thing.
Most tools follow a consistent verb_noun pattern with hyphen-separated words (search-*, list-*, get-*). The exception is 'browse', which is a bare verb without a named resource, and search-movie implies only movies though it also covers TV. Overall, the pattern is readable and mostly uniform.
With 10 tools, the count is well within the typical range for a domain-specific server. It covers multiple resource types without being bloated, and each tool serves a clear purpose.
The set covers search, list, and detail operations for movies/TV and group topics, but lacks a dedicated get-book-detail tool; instead, 'browse' opens a browser, which is a workaround. There are also no mutation operations, but that may be acceptable for a public data server. Missing a get-book-detail is a notable gap.
MCP server for Russian books search, details, and recommendation candidates.
MCP server aggregating hot-search boards from 8 Chinese platforms (Weibo, Zhihu, Bilibili, Douyin).
MCP server for China Railway 12306 ticket availability: schedules and seats by Chinese station name.
MCP server for accessing curated awesome list documentation
