Click on "Install 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., "@mcp-server-fanqie 帮我搜索修仙小说"
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.
一个为番茄小说（FanQie Novel）提供 MCP（Model Context Protocol）服务的工具，支持将番茄小说的书籍、目录、章节内容等数据提供给支持 MCP 协议的大语言模型客户端，如 Claude Desktop、Cursor。
🔍 搜索功能 - 支持搜索小说、听书、漫画、短剧
📖 书籍信息 - 获取书籍详情、完整目录、简化目录
📄 内容获取 - 获取章节内容，支持多种内容类型
💬 评论功能 - 获取书籍评论，支持分页
📱 设备管理 - 支持 Android 和 iOS 设备池管理
🎯 多平台支持 - 支持获取 iOS 平台特定内容
Related MCP server: xhs-mcp
搜索番茄小说平台上的书籍、听书、漫画或短剧。
参数：
key (必需): 搜索关键词
tab_type (可选): 内容类型
3 - 小说（默认）
2 - 听书
8 - 漫画
11 - 短剧
offset (可选): 分页偏移量，默认为 0
示例：
搜索"修仙"关键词的小说
搜索"历史"关键词的漫画获取指定书籍的详细信息，包括书名、作者、简介、封面等元数据。
参数：
book_id (必需): 书籍 ID
返回信息：
书名、作者、译者
简介、封面
分类、标签
字数、评分等
获取书籍的完整章节目录列表，包括所有卷和章节信息。
参数：
book_id (必需): 书籍 ID
返回信息：
所有卷的标题和 ID
每卷下的章节列表
章节标题和 ID
获取书籍的简化目录信息，仅包含章节标题和 ID。
参数：
book_id (必需): 书籍 ID
用途：
快速获取章节列表
用于批量获取章节内容
获取指定章节的文本内容。
参数：
item_id (必需): 章节 ID
返回：
章节文本内容
统一的内容获取接口，支持多种内容类型。
参数：
tab (必需): 内容类型
novel - 小说章节
audiobook - 有声书音频
short drama - 短剧视频
comic - 漫画图片
batch - 批量获取多个章节
download - 下载整本小说
item_id (可选): 单个章节/视频/漫画 ID（小说、听书、短剧、漫画时必需）
item_ids (可选): 多个章节 ID，逗号分隔（批量时必需）
book_id (可选): 书籍 ID（批量、下载时必需）
show_html (可选): 漫画是否返回 HTML 格式（0 或 1，默认 0）
tone_id (可选): 有声书音色 ID（听书时使用，默认 0）
async (可选): 漫画异步模式（0 或 1，默认 1，建议为 1 以获得更快响应）
使用场景：
获取单个小说章节：tab=novel, item_id=章节ID
获取有声书音频：tab=audiobook, item_id=章节ID
获取漫画图片：tab=comic, item_id=章节ID
批量获取章节：tab=batch, item_ids=章节ID1,章节ID2, book_id=书籍ID
下载整本小说：tab=download, book_id=书籍ID
获取书籍、章节或其他内容的评论列表，支持分页。
参数：
book_id (必需): 书籍 ID
count (可选): 每页数量，默认 20
offset (可选): 偏移量，默认 0
查看设备池的整体状态，包括所有注册设备。
用途：
检查可用设备
监控设备健康状态
注册新的设备到设备池。
参数：
platform (可选): 平台类型
android（默认）
ios
查看指定平台的设备状态。
参数：
platform (可选): 平台类型
android（默认）
ios
获取未处理的原始章节内容，包含完整的响应数据（HTML 格式、作者的话等）。
参数：
item_id (必需): 章节 ID
用途：
需要原始 HTML 结构或完整字段时使用
使用 iOS 平台接口（8402 算法签名）获取章节内容。
参数：
item_id (必需): 章节 ID
⚠️ 该接口依赖 iOS 设备池，上游服务可能临时不可用。
注册新的 iOS 设备到设备池。
参数： 无
⚠️ 该接口依赖上游 iOS 服务，可能临时不可用。
根据任务 ID 查询漫画下载任务的进度。
参数：
task_id (必需): 任务 ID（由漫画内容接口返回）
✅ 本仓库已包含编译产物
build/，克隆或导入后无需自己编译即可直接运行。
Node.js 16.x 或更高版本（仅运行的话不需要装 TypeScript）
包已发布到 npm（@fysh925/mcp-server-fanqie），任何支持 MCP 的平台都用下面这一段配置——魔搭社区「可托管部署」、Claude Desktop、Cursor、Cherry Studio 全都适用：
{
"mcpServers": {
"fanqie-novel": {
"command": "npx",
"args": ["-y", "@fysh925/mcp-server-fanqie"]
}
}
}魔搭社区：创建 MCP 服务 → 选「可托管部署」→ 配置里粘贴上面这段。魔搭云端会用 npx 自动从 npm 拉起服务，无需你自己的服务器，也无需下载代码。
本地客户端（Claude Desktop / Cursor / Cherry Studio）：把上面这段填进对应配置文件即可。
✅ 为什么用 npx：魔搭等平台的「可托管部署」需要从公共仓库（npm）拉起服务。npx 会自动下载并运行最新版
@fysh925/mcp-server-fanqie，这是云端托管最省心、最可靠的方式。如果填本地路径（node build/index.js），魔搭云端没有你的仓库文件，会部署失败并退化成「仅本地可用」。
部署后确认：能看到 14 个工具、调用 search_books 搜书能正常返回 —— 即成功。
各客户端配置文件位置：
Claude Desktop：claude_desktop_config.json
Cursor：~/.cursor/mcp.json 或项目内 .cursor/mcp.json
Cherry Studio：设置 → MCP 服务器 → 编辑 JSON
改完配置后需完全退出并重启客户端才生效（刷新无效）。
仓库已含编译产物 build/，克隆后即可运行，无需编译：
git clone https://github.com/fysh1010/mcp-server-fanqie.git配置里用 node + 你克隆后的实际绝对路径：
{
"mcpServers": {
"fanqie-novel": {
"command": "node",
"args": ["/你的克隆路径/mcp-server-fanqie/build/index.js"]
}
}
}Windows 示例（反斜杠必须双写 \\）："args": ["C:\\Users\\你的用户名\\mcp-server-fanqie\\build\\index.js"]
macOS / Linux 示例："args": ["/Users/你的用户名/mcp-server-fanqie/build/index.js"]
⚠️ 本地绝对路径只适用于本机客户端，不要填到魔搭等云平台（云端没有这个路径）。云平台请用方式一的 npx。
src/ 源码时）git clone https://github.com/fysh1010/mcp-server-fanqie.git
cd mcp-server-fanqie
npm install
npm run build # 重新生成 build/改完源码记得
npm run build重新编译，并把src/和build/一起提交，否则托管平台运行的还是旧版本。
服务默认使用内置接口地址 http://101.35.133.34:5000。若该地址日后变更，可通过环境变量 FANQIE_API_BASE 覆盖，无需改代码：
{
"mcpServers": {
"fanqie-novel": {
"command": "npx",
"args": ["-y", "@fysh925/mcp-server-fanqie"],
"env": {
"FANQIE_API_BASE": "http://新的接口地址:端口"
}
}
}
}也可在项目根目录创建 .env 文件：FANQIE_API_BASE=http://101.35.133.34:5000
用户：
帮我搜索关于修仙的小说LLM 调用：
search_books(key="修仙", tab_type=3, offset=0)返回结果：
{
"keyword": "修仙",
"tab_type": 3,
"offset": 0,
"results": [
{
"book_id": "7233628636023098407",
"book_name": "修罗武神",
"author": "善良的蜜蜂",
"cover": "...",
"abstract": "...",
"total_words": 1000000
}
// ... 更多搜索结果
]
}用户：
帮我查看《修罗武神》的详细信息LLM 调用：
get_book_detail(book_id="7233628636023098407")返回结果：
{
"book_id": "7233628636023098407",
"detail": {
"book_name": "修罗武神",
"author": "善良的蜜蜂",
"abstract": "一个关于修仙的故事...",
"cover": "...",
"total_words": 1000000,
"rating": 8.5,
"category": "玄幻"
}
}用户：
帮我获取《修罗武神》的目录LLM 调用：
get_book_directory(book_id="7233628636023098407")返回结果：
{
"book_id": "7233628636023098407",
"directory": {
"volume_1": {
"volume_id": "xxx",
"volume_title": "第一卷",
"chapters": [
{"chapter_id": "xxx", "chapter_title": "第一章"},
{"chapter_id": "xxx", "chapter_title": "第二章"}
]
}
}
}用户：
我想读《修罗武神》的第一章LLM 调用：
get_chapter_content(item_id="7233628684760910863")返回结果：
{
"item_id": "7233628684760910863",
"content": "第一章的内容..."
}用户：
帮我获取《修罗武神》前 5 章的内容LLM 调用：
get_content(tab="batch", item_ids="章节ID1,章节ID2,章节ID3,章节ID4,章节ID5", book_id="7233628636023098407")用户：
《修罗武神》有什么热门评论？LLM 调用：
get_comments(book_id="7233628636023098407", count=10, offset=0)git clone https://github.com/fysh1010/mcp-server-fanqie.git
cd mcp-server-fanqie
npm install
npm run buildnpm run startnpm testnpm run inspectormcp-server-fanqie/
├── src/
│ ├── FanQieApi.ts # 番茄小说 API 封装类
│ ├── fontDecrypt.ts # 字体解密模块（备用）
│ └── index.ts # MCP 服务器主入口
├── build/ # 编译产物（已纳入版本控制，可直接运行）
├── package.json # 项目配置
├── tsconfig.json # TypeScript 配置
├── .gitignore # Git 忽略文件
└── README.md # 说明文档📄 补全 LICENSE 文件（MIT）
🏷️ 完善 package.json 元数据（author / repository / homepage / bugs / keywords / engines）
⭐ README 加入 Star History 星标曲线图
📦 已发布到 npm：@fysh925/mcp-server-fanqie，可用 npx -y @fysh925/mcp-server-fanqie 一键部署到魔搭等平台
🔧 更新 API 接口地址（原地址已失效）至 http://101.35.133.34:5000
⚙️ 支持通过环境变量 FANQIE_API_BASE 自定义 API 地址，接口变更时无需改动代码
✨ get_content 新增 download 整本下载类型及 async 漫画异步模式参数
➕ 补全 4 个此前未暴露的工具（接口文档共 14 个，现已全部封装为 MCP 工具）：
get_raw_content - 获取原始内容
get_ios_content - 获取 iOS 内容
register_ios_device - 注册 iOS 设备
get_manga_progress - 查询漫画下载进度
🎉 首次发布
✅ 实现搜索功能
✅ 实现书籍信息获取
✅ 实现目录和章节内容获取
✅ 实现评论功能
✅ 实现设备管理功能
✅ 支持 iOS 平台特定内容获取
欢迎提交 Issue 和 Pull Request！
本项目基于 番茄小说 API 开发
项目结构参考了社区中其他 MCP 服务器的开发实践
如果这个项目对你有帮助，欢迎点个 Star 支持一下！
注意： 本项目仅供学习和研究使用，请遵守番茄小说的使用条款和 API 使用规范。
Get detailed information about a specific book including title, author, description, cover, and other metadata
| Name | Required | Description | Default |
|---|---|---|---|
| book_id | Yes | Book ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It implies a read operation ('Get detailed information') but does not explicitly state it is read-only, idempotent, or safe. The listed fields suggest low side effects, but transparency is adequate rather than thorough.
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?
Single sentence, clearly front-loaded with the action ('Get detailed information'), and efficiently lists key data fields without redundancy.
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?
No output schema is provided, so the description must explain return values. It lists title, author, description, cover, and 'other metadata'—helpful but vague. Lacks structure (e.g., nested objects, optional fields) that an agent would need for reliable processing.
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 coverage is 100% for the single parameter book_id, so baseline is 3. The description adds no extra meaning beyond 'Book ID' from the schema; it does not specify ID format, source, or alternatives.
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 gets detailed info for a specific book, listing title, author, description, cover, and other metadata. It effectively distinguishes from siblings like get_book_directory (list) and get_chapter_content (chapter-specific).
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 explicit guidance on when to use versus alternatives (e.g., get_book_directory for listing, search_books for discovery). No prerequisites, context, or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the complete chapter directory of a book including all volumes and chapters
| Name | Required | Description | Default |
|---|---|---|---|
| book_id | Yes | Book ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose behavioral traits such as authentication requirements, read-only nature, return format, or any side effects. The phrase 'complete ... including all volumes and chapters' gives some structural hint but is insufficient.
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, well-structured sentence with no wasted words. It is front-loaded with the key action and resource.
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 description covers the basic purpose but lacks important details such as the structure of the returned directory (e.g., hierarchical vs flat), pagination, or any prerequisites. For a tool with one parameter and no output schema, it is minimally adequate but not fully complete.
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 has 100% coverage with a description for 'book_id' ("Book ID"). The description does not add any additional meaning or usage details beyond what the schema already provides, meeting the baseline but not exceeding it.
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 verb 'Get' and the resource 'complete chapter directory', and specifies it includes all volumes and chapters. However, it does not differentiate from the sibling tool 'get_simple_directory', which might offer a simpler version.
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. There is no mention of preconditions, exclusions, or comparison to sibling tools like 'get_simple_directory' or 'get_book_detail'. The usage context is purely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get content of a specific chapter. This is a simplified interface that directly returns chapter text
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes | Chapter ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions 'simplified' and 'directly returns chapter text', but lacks details on side effects, authentication requirements, rate limits, or what 'directly' implies (e.g., no preprocessing). The transparency is minimal for a read tool.
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 two concise sentences that are front-loaded with the main purpose. Every word earns its place, and there is no redundancy or fluff.
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 no annotations, no output schema, and a sibling list that includes similar tools like get_content and get_raw_content, the description is incomplete. It does not explain return format, error handling, or how it differs from alternatives, leaving gaps for the AI to infer.
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 coverage is 100% with one parameter, item_id, described as 'Chapter ID'. The description adds no additional meaning beyond the schema, so the baseline score of 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 clearly states the verb 'Get' and the resource 'content of a specific chapter', and adds 'simplified interface that directly returns chapter text'. However, it does not differentiate from sibling tools like get_content, which may also return chapter content, leading to potential confusion.
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 on when to use this tool versus alternatives such as get_content or get_raw_content. The description implies basic usage but does not specify context, prerequisites, or exclusions, leaving the AI without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comments for a book, chapter, or other content with pagination support
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of items per page | |
| offset | No | Offset for pagination | |
| book_id | Yes | Book ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions pagination support, but the schema already defines count and offset parameters for pagination. No additional behavioral traits disclosed (e.g., ordering, authentication, limits).
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?
Single sentence, no redundancy. Front-loaded with the main action. However, could be slightly more structured by separating scope and pagination.
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?
Description is minimal. No output schema, so expected return fields are not hinted. Does not clarify ordering, filtering, or whether all comments are returned. Incomplete for a tool that retrieves a list with pages.
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%, so baseline is 3. The description adds no additional meaning beyond what the schema already provides for parameters.
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 tool retrieves comments for a book, chapter, or other content. While 'other content' is vague, it is the only sibling tool focused on comments, so purpose is clear but not fully specific.
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 on when to use this tool versus alternatives. Does not mention when not to use or any conditions. Lacks any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unified content retrieval interface supporting novels, audiobooks, short dramas, comics, batch retrieval, and whole-book download
| Name | Required | Description | Default |
|---|---|---|---|
| tab | Yes | Content type: novel, audiobook, short drama, comic, batch, download | |
| async | No | Comic async mode (0 or 1, default 1). Recommended 1 for faster responses | |
| book_id | No | Book ID (required for batch retrieval and download) | |
| item_id | No | Single chapter/video/comic ID (required for novel, audiobook, short drama, comic) | |
| tone_id | No | Audiobook voice ID (used for audiobook, default 0) | |
| item_ids | No | Multiple chapter IDs separated by commas (required for batch) | |
| show_html | No | Whether to return HTML format for comics (0 or 1, default 0) |
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 says 'retrieval interface' suggesting read-only, but does not explicitly confirm safety, rate limits, or other behavioral traits. The description is minimal on behavioral details.
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, concise sentence that front-loads the core purpose ('unified content retrieval interface') and enumerates supported types. No redundant information.
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 complexity (7 parameters, 6 content types), the description is adequate but does not elaborate on how to use each type or the expected output. With no output schema, more detail would be beneficial.
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%, so the schema already documents all parameters. The description adds no additional semantic information beyond what the schema provides.
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 is a 'unified content retrieval interface' and lists the types of content it supports (novels, audiobooks, etc.), distinguishing it from sibling tools like get_chapter_content or get_book_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?
The description lacks explicit guidance on when to use this tool versus its siblings (e.g., get_chapter_content). It does not mention prerequisites or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View the overall status of the device pool including all registered devices
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. 'View' implies a non-destructive read operation, which is appropriate. However, no details on response format, potential latency, or what 'overall status' aggregates (e.g., average metrics, count of online devices).
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?
Single sentence, no fluff. Information is front-loaded but could arguably be more concise by removing 'including all registered devices' since 'overall status of the device pool' already implies that.
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 zero-parameter, no-output-schema tool, the description is minimal but sufficient for a simple status check. However, 'overall status' is vague; it could mention whether it returns aggregated data or per-device details, and whether it requires authentication.
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?
No parameters in schema, and schema description coverage is 100%. Description adds no parameter info, but none is needed. Baseline score of 4 for zero-parameter tools.
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?
Description uses verb 'View' and specifies resource 'overall status of the device pool', clearly distinguishing from sibling 'get_device_status' (which likely targets a single device). However, 'overall status' is slightly vague; could specify what metrics are included.
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 on when to use this tool vs alternatives like 'get_device_status'. The description implies it's for a high-level overview, but no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View the status of devices for a specific platform
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | Platform type: android or ios | android |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only says 'view', missing details on whether status is real-time, cached, or what triggers updates. No disclosure of side effects or permissions.
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?
Single sentence with no extraneous words. Highly concise and front-loaded.
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?
Tool has one optional parameter and no output schema. Description adequately covers purpose but does not explain the return format or data scope. Minimum viable for a simple tool.
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 coverage is 100% with parameter description. Description adds no new semantics beyond the schema, which already explains platform options.
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 views device status for a platform. It distinguishes from sibling tools like get_device_pool_status by specifying 'devices', but does not explicitly differentiate from that sibling.
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 on when to use this tool versus alternatives like get_device_pool_status or register_device. The description implies a simple query but provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get chapter content using the iOS platform interface (signed with the 8402 algorithm). Note: depends on the iOS device pool and may be temporarily unavailable
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes | Chapter ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions dependency on the iOS device pool and potential unavailability, plus the signing algorithm. With no annotations, it provides some behavioral context but lacks details on read-only nature, side effects, or error handling.
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 two concise sentences, front-loading the core purpose and adding a critical caveat. No unnecessary words or redundancy.
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 schema (one parameter, no output schema) and no annotations, the description provides moderate completeness. It covers the platform dependency and algorithm but omits details about return format, error cases, or expected behavior.
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 covers the single parameter item_id with a description of 'Chapter ID'. The tool description adds no additional semantic information beyond what the schema already provides, so it meets baseline with no extra value.
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 tool gets chapter content using the iOS platform interface with a specific algorithm. However, it does not differentiate from sibling tools like get_chapter_content or get_raw_content, which share similar purposes.
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 implies the tool is for iOS-signed content but does not explicitly state when to use it versus alternatives. The note about device pool unavailability provides some context, but no exclusions or direct comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the progress of a manga download task by its task ID (returned from the comic content interface)
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Task ID returned from the manga/comic content interface |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'query the progress' without disclosing whether the operation is read-only, idempotent, or what the response format might be. More detail on behavior (e.g., polling semantics) is needed.
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 front-loaded sentence with no wasted words. Every part is informative.
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 and no output schema, the description is adequate but could be more complete. It doesn't describe the return value structure, possible statuses, or error cases, which would help an agent interpret results.
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 covers the parameter with a description that matches the tool's description. The tool description adds context that the task_id comes from the comic content interface, but this adds minimal value. With 100% schema coverage, 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 the tool queries progress of a manga download task using a task ID. It specifies the source (comic content interface), which distinguishes it from sibling tools that retrieve content or other data.
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 implies usage when a task ID is available from the comic content interface, but it does not explicitly state when to use this tool versus alternatives like get_content or get_chapter_content. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the unprocessed raw chapter content, including the complete response data (HTML format, author notes, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes | Chapter ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It reveals content type (HTML, author notes) but omits other behaviors like idempotency, authentication, or side effects.
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?
Single, focused sentence that front-loads the purpose without extraneous words.
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?
Lacks output schema; description gives some context on return data (HTML, author notes) but is vague about structure. With many siblings, more detail on return format would improve completeness.
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?
Parameter schema has 100% coverage with basic 'Chapter ID' description. Description adds no extra meaning beyond schema, meeting baseline for high schema coverage.
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?
Clearly states it retrieves 'unprocessed raw chapter content' with HTML format and author notes, distinguishing it from likely processed siblings like get_chapter_content. However, it does not explicitly contrast with all siblings.
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?
Implies usage for raw content but provides no when-to-use or when-not-to-use guidance, nor mentions alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get simplified directory information with only chapter titles and IDs
| Name | Required | Description | Default |
|---|---|---|---|
| book_id | Yes | Book ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that the tool returns 'simplified directory information' but does not explain whether it is read-only, requires authentication, or any other behavioral aspect.
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, front-loaded sentence without any unnecessary words. It effectively communicates the tool's purpose concisely.
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?
While the description is adequate for a simple tool with one parameter, it lacks details on the output structure or how it compares to full directory tools. Given the numerous sibling tools, more completeness would improve clarity for the agent.
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 coverage is 100% with one parameter described as 'Book ID'. The description does not add any extra meaning beyond what the schema provides, 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 clearly states the verb 'Get' and resource 'simplified directory information', and explicitly mentions it includes only chapter titles and IDs, distinguishing it from sibling tools like get_book_directory.
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 implies a simplified view but provides no explicit guidance on when to use this tool versus alternatives like get_book_directory. With 13 sibling tools, more explicit usage context would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a new device to the device pool
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | Platform type: android or ios | android |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure, but it provides none. It does not mention side effects, authentication requirements, rate limits, or what happens if the device is already registered. The description adds no value beyond the basic action.
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 superfluous words, achieving high conciseness. However, it sacrifices informativeness; with more to convey, a slightly longer description would be justified.
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's simplicity (single parameter, no output schema), the description is too minimal. It captures the basic purpose but lacks details on return values, error conditions, or behavioral context needed for reliable AI invocation. The agent must infer too much.
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 covers 100% of the parameters with descriptions (e.g., 'platform: Platform type: android or ios'), so the baseline is 3. The description does not add any additional parameter context beyond what the schema already provides, but it does not reduce clarity either.
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 ('Register') and the resource ('a new device to the device pool'), providing a specific verb+resource. However, it does not distinguish itself from the sibling tool 'register_ios_device' which suggests a more specific use case. The input schema reveals it handles both 'android' and 'ios' platforms, but this is not mentioned in the description.
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 'register_ios_device'. The description lacks context about prerequisites, suitability, or exclusions. An AI agent would have no basis to decide between this tool and its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a new iOS device to the device pool. Note: depends on the upstream iOS service and may be temporarily unavailable
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It adds a useful note about dependency on upstream iOS service and potential unavailability, but does not disclose other behavioral traits such as idempotency, side effects, or error scenarios.
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?
Single sentence, front-loaded with purpose, no wasted words. Appropriate length for a tool with no parameters.
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 zero parameters and no output schema, the description covers the basic purpose and a dependency note. However, it lacks information about return values, error handling, and prerequisites, which would be valuable for an agent to correctly invoke and interpret results.
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?
There are zero parameters in the input schema, so baseline is 4. The description does not add parameter information, but none is needed since the schema is empty.
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?
Description clearly states 'Register a new iOS device to the device pool', which specifies the verb (register), resource (iOS device), and scope (device pool). However, it does not differentiate from sibling 'register_device' which may serve similar purpose for non-iOS devices.
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 usage context is provided. There is no guidance on when to use this tool versus alternatives like 'register_device', nor any prerequisites or conditions for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for books on FanQie (Tomato) Novel platform by keywords. Supports searching for novels, audiobooks, comics, and short dramas.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Search keyword to find books | |
| offset | No | Offset for pagination | |
| tab_type | No | Content type: 3=novel, 2=audiobook, 8=comic, 11=short drama |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It fails to mention pagination behavior, rate limits, authentication needs, or handling of empty results. Only mentions search capability without operational context.
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?
Two clear, front-loaded sentences with no extraneous information. Efficiently conveys the tool's purpose.
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?
No output schema and no description of return format or pagination results. For a search tool, more context about output shape is needed. Sibling tools exist but are not referenced.
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 covers all 3 parameters with descriptions (key, offset, tab_type). Description adds high-level context (FanQie platform, content types) but does not surpass schema's detail. 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?
Description clearly states it searches for books on FanQie platform by keywords, listing supported content types (novels, audiobooks, comics, short dramas). This distinguishes it from sibling tools like get_book_detail which retrieve specific book details.
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?
Description implies it should be used for keyword-based discovery, but does not explicitly state when to use vs alternatives (e.g., get_book_detail). No guidance on when not to use or prerequisites.
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.1.2get_book_detailget_book_directoryget_chapter_contentget_commentsget_contentget_device_pool_statusget_device_statusget_ios_contentget_manga_progressget_raw_contentget_simple_directoryregister_deviceregister_ios_devicesearch_booksScored across 14 tools
Multiple tools have overlapping purposes: get_chapter_content, get_ios_content, get_raw_content, and get_content all retrieve chapter content, making it unclear which to use. Similarly, get_book_directory and get_simple_directory serve the same function with different verbosity. Device registration and status tools are unrelated to the core content domain, adding confusion.
Most tools follow a 'get_X' or 'register_X' verb_noun pattern, but there are minor deviations such as 'search_books' and 'get_simple_directory' (adjective between verb and noun). The naming is mostly consistent and predictable.
With 14 tools, the count is well within the typical 3-15 range for a focused server. Each tool serves a clear purpose in the domain of book content retrieval and device management, though some redundancy exists.
The tool surface covers basic read operations (search, get details, get directory, get content, get comments) for books, audiobooks, manga, etc. However, there are no tools for creating, updating, or deleting content, nor for user authentication or advanced search filtering. The device management tools seem out of place for a content-focused server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-native fiction platform. Any AI can register, read, search and co-author novels via MCP or REST.
MCP server for Russian books search, details, and recommendation candidates.
Chinese web novel MCP: 36 tools (outline, prose, review, coach, KD export). BYOK, no API key.
Read-only MCP: search & read a Traditional Chinese (zh-TW) Taiwan community forum (PTT-style).