mcp-server-weread
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., "@mcp-server-wereadshow me my bookshelf"
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 Server
一个为微信读书提供MCP(Model Context Protocol)服务的工具,支持将微信读书的书籍、笔记和划线数据提供给支持MCP的大语言模型客户端,如Claude Desktop。
功能特点
从微信读书获取书架信息
搜索书架中的图书
获取图书的笔记和划线
获取图书的热门书评
支持按章节组织笔记和划线
与支持MCP协议的LLM客户端无缝集成
Related MCP server: wechat-mcp-server
主要工具
get_bookshelf - 获取用户书架上所有书籍
返回书籍基本信息,包括书名、作者、译者和分类等
search_books - 通过关键词检索用户书架上的书籍
支持模糊匹配和精确匹配
可选是否包含详细信息
可设置最大结果数量
get_book_notes_and_highlights - 获取指定书籍的所有划线和笔记
支持按章节组织结果
支持筛选划线样式
返回结构化的数据以便于LLM理解
get_book_best_reviews - 获取指定书籍的热门书评
支持设置返回数量
支持分页浏览
包含评分、点赞数和评论者信息
安装与使用
先决条件
Node.js 16.x 或更高版本
微信读书账号和有效的Cookie
安装教程
与Claude Desktop集成
有多种方式可以与Claude Desktop集成:
方式一:通过 npx 使用(最简单,推荐)
打开Claude Desktop
进入设置 -> MCP配置
添加工具,使用以下JSON配置:
{ "mcpServers": { "mcp-server-weread": { "command": "npx", "args": ["-y", "mcp-server-weread"], "env": { // 方式1:使用Cookie Cloud(推荐) "CC_URL": "https://cc.chenge.ink", // Cookie Cloud的URL "CC_ID": "您的ID", // Cookie Cloud的ID "CC_PASSWORD": "您的密码" // Cookie Cloud的密码 // 或方式2:直接提供Cookie // "WEREAD_COOKIE": "您的微信读书Cookie" } } } }
方式二:全局安装后使用
全局安装包:
npm install -g mcp-server-weread在Claude配置中使用:
{ "mcpServers": { "mcp-server-weread": { "command": "mcp-server-weread", "env": { // 同上方式配置环境变量 } } } }
提示:直接在Claude配置中提供环境变量的方式更加方便,无需设置.env文件,推荐使用。
CookieCloud 配置说明
为了解决 Cookie 频繁过期,需要重新获取并更新环境变量的问题。本项目支持 CookieCloud 服务来自动同步和更新 Cookie。CookieCloud 是一个开源的跨浏览器 Cookie 同步工具,支持自建服务器。
配置步骤:
安装浏览器插件 Edge商店:CookieCloud for Edge Chrome商店:CookieCloud for Chrome
配置 CookieCloud 插件
服务器地址:使用默认服务器 https://cc.chenge.ink 或填入自建服务器地址 点击 "自动生成密码" 同步域名关键词中填入 "weread" 点击"保存" ,然后点击 "手动同步"确保配置生效 [可选] 如果需要插件自动保活,可以在保活中填入 https://weread.qq.com,插件会自动刷新 Cookie
在MCP Json中配置CookieCloud变量: CC_URL=你的CookieCloud服务器地址 (或使用我的默认服务器地址 https://cc.chenge.ink ) CC_ID=你的CookieCloud用户UUID CC_PASSWORD=你的CookieCloud密码 注意:配置 CookieCloud 后,系统会优先使用 CookieCloud 获取 Cookie,获取失败才会使用 WEREAD_COOKIE 环境变量的值。
Cookie获取方法
微信读书的Cookie可以通过以下步骤获取:
使用Chrome浏览器登录微信读书网页版
按F12打开开发者工具,切换到Network标签页
刷新页面,在请求列表中找到weread.qq.com的请求
在Headers中找到Cookie字段,复制其完整内容
将复制的内容添加到MCP Json 或 .env文件的WEREAD_COOKIE变量中
使用示例
以下是一些与LLM对话的示例:
获取书架信息
用户: 帮我查看我的微信读书书架
LLM: 我将获取您的微信读书书架信息。
[LLM调用get_bookshelf工具]
我从您的微信读书书架获取到了208本书籍。以下是部分书籍:
1. 《隐藏的自我》- 大卫·伊格曼
2. 《思考,快与慢》- 丹尼尔·卡尼曼
3. 《人类简史》- 尤瓦尔·赫拉利
...搜索特定书籍
用户: 帮我找关于心理学的书
LLM: 我将搜索您书架上与心理学相关的书籍。
[LLM调用search_books工具,参数为keyword="心理学"]
在您的书架上,我找到了3本与心理学相关的书籍:
1. 《思考,快与慢》- 丹尼尔·卡尼曼(进度:75%)
2. 《乌合之众》- 古斯塔夫·勒庞(进度:50%)
3. 《心理学与生活》- 理查德·格里格(进度:30%)
您想了解哪一本书的更多信息?获取笔记和划线
用户: 帮我整理《思考,快与慢》这本书的笔记
LLM: 我将获取《思考,快与慢》的笔记和划线。
[LLM调用search_books工具,找到书籍ID]
[LLM调用get_book_notes_and_highlights工具]
以下是您在《思考,快与慢》中的笔记和划线(按章节组织):
第一章:系统1和系统2
- 划线:「系统1的运行是无意识且快速的,不怎么费脑力,没有感觉,完全处于自主控制状态。」
- 您的笔记:「系统1负责直觉和快速判断,系统2负责缓慢的理性思考。」
第三章:锚定效应
- 划线:「锚定效应指的是在不确定情境下进行数字估计时,会过度受到事先接触的不相干数字的影响。」
...获取热门书评
用户: 这本《原则》有哪些热门书评?
LLM: 我会为您查找《原则》的热门书评。
[LLM调用search_books工具,找到书籍ID]
[LLM调用get_book_best_reviews工具]
以下是《原则》的热门书评:
1. 评论者"思考者"(评分:5星):
"这是一本关于如何思考的书。达利欧将自己多年的经验总结为可操作的原则,帮助我们做出更好的决策。特别喜欢他关于'痛苦+反思=进步'的观点,非常实用。"
👍 182 | 💬 23
2. 评论者"投资学习者"(评分:4星):
"桥水基金创始人的思想精华,值得反复阅读。书中的工作原则部分对管理者特别有帮助,建议先读生活原则,再读工作原则。"
👍 94 | 💬 12
...许可证
MIT
贡献
欢迎提交Pull Request或Issue来改进此项目。
Available Tools
4 toolsget_book_best_reviewsB
Get popular reviews for a specific book
| Name | Required | Description | Default |
|---|---|---|---|
| book_id | Yes | Book ID | |
| count | No | Number of reviews to return | |
| max_idx | No | Pagination index | |
| synckey | No | Sync key for pagination |
TDQS
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 behavioral disclosure. It only says 'Get popular reviews' without explaining pagination behavior (max_idx, synckey), how 'popular' is determined, required authentication, 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 a single sentence, which is concise but lacks necessary behavioral context. While it is not verbose, it under-specifies the tool's behavior, making it merely adequate.
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 has 4 parameters with pagination and no output schema. The description does not explain the pagination mechanism, the sorting order of reviews, or potential error conditions. Given no annotations, the description is insufficient for complete understanding.
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 tool description adds no additional meaning beyond what the schema provides, meeting the baseline for high 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?
The description clearly states 'Get popular reviews for a specific book', identifying the action (get), resource (popular reviews), and scope (for a specific book). This distinguishes it from sibling tools like get_book_notes_and_highlights or get_bookshelf.
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 explicit guidance on when to use this tool versus alternatives. The description only implies usage when popular reviews are needed, but does not mention exclusions or compare to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_book_notes_and_highlightsB
Get all highlights and notes for a specific book, organized by chapter
| Name | Required | Description | Default |
|---|---|---|---|
| book_id | Yes | Book ID | |
| include_chapters | No | Whether to include chapter information | |
| organize_by_chapter | No | Whether to organize by chapter | |
| highlight_style | No | Highlight style filter, null means all |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only describes the basic function and output organization, lacking details on permissions, side effects, error handling, or 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?
The description is a single, concise sentence of 12 words, front-loading the key action and resource. No unnecessary or 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 absence of an output schema, the description partially explains the structure ('organized by chapter') but omits details on returned fields, pagination, or error handling. 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?
Schema coverage is 100% with parameter descriptions. The description adds no new semantic value beyond the schema, but it does reinforce the 'organize_by_chapter' parameter. Baseline for high coverage 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 'Get all highlights and notes for a specific book, organized by chapter', specifying verb, resource, scope, and organization. It distinctly differs from sibling tools like get_book_best_reviews, get_bookshelf, and search_books.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention when not to use it. Implicit differentiation from siblings is not enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_bookshelfA
Get all books in the user's bookshelf with comprehensive statistics and categorization information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It states 'Get all books' implying a read operation, but does not mention authentication needs, rate limits, or potential side effects. Adequate for a simple retrieval but lacks depth.
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 conveys the tool's function without any redundant or unnecessary words. It is front-loaded and efficient.
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 provides an adequate overview ('books, statistics, categorization') but lacks specifics about the return structure or potential constraints. It is sufficient for a simple tool but not comprehensive.
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 has zero parameters, so the description has no parameter details to add. Baseline 4 is appropriate as no extra information is needed.
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 'Get all books in the user's bookshelf with comprehensive statistics and categorization information', which specifies the exact resource and action. It effectively distinguishes from sibling tools like get_book_best_reviews and search_books that focus on different aspects.
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 use for retrieving all bookshelf books with stats, but provides no explicit guidance on when to use versus siblings or any exclusions. Context signals (sibling names) help differentiate, but the description itself lacks usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_booksB
Search for books in the user's bookshelf by keywords and return matching books with details and reading progress
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Search keyword to match book title, author, translator or category | |
| exact_match | No | Whether to use exact matching, default is fuzzy matching | |
| include_details | No | Whether to include detailed information | |
| max_results | No | Maximum number of results to return |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions return of 'details and reading progress' but does not disclose side effects, read-only nature, auth needs, rate limits, or error behavior.
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 is front-loaded with the core action. No wasted words, though structure could be improved with bullet points or separate outcome statements.
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 four parameters, siblings, and no output schema or annotations, the description is insufficiently complete. It does not explain the meaning of 'details and reading progress', handling of no results, or pagination, which would be helpful given the missing output schema.
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 all parameters described. The description adds minimal extra meaning beyond the schema, only tying keyword and include_details to the search output. 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's action (search), resource (books in bookshelf), and output (matching books with details and reading progress). It distinguishes from siblings which focus on reviews, notes, or the entire bookshelf.
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 for keyword-based search but provides no explicit guidance on when to use versus siblings like get_book_best_reviews or get_bookshelf. No when-not-to-use or alternative selection advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
v0.2.2- First observed
get_book_best_reviews - First observed
get_book_notes_and_highlights - First observed
get_bookshelf - First observed
search_books
TDQS
Scored across 4 tools
Each tool serves a distinct purpose: browsing the bookshelf, searching within it, retrieving notes/highlights for a specific book, and fetching reviews. No two tools overlap in functionality.
Three tools follow the 'get_*' pattern, but 'search_books' uses a different verb, creating a minor inconsistency. The naming is otherwise clear and uniform in style.
With 4 tools, the set is well-scoped for a read-only book management service, covering essential retrieval operations without unnecessary bloat.
The tools adequately cover data retrieval (list, search, highlights, reviews) but lack any write operations such as adding or removing books, limiting overall completeness.
Maintenance
Related MCP Connectors
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server for Russian books search, details, and recommendation candidates.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Related MCP Servers
- AlicenseBqualityDmaintenanceA local MCP server that lets LLM agents read EPUB books and PDF documents with outline-first navigation, precise node reads, and local SQLite persistence.292MIT
- FlicenseCqualityDmaintenanceMCP server for reading local WeChat data, enabling AI assistants to query chat history, contacts, sessions, and more via MCP tools.207-
- AlicenseAqualityBmaintenanceAn MCP server that lets an LLM browse, search, and download books from OPDS catalogs (e.g., Project Gutenberg, Standard Ebooks) using tools for feed navigation, full-text search, and acquisition link downloads.41AGPL 3.0
- AlicenseNot gradedqualityAmaintenanceMCP server providing an Agent-first, read-only interface to authorized WeChat conversations, with CLI and plugin support for Codex and Claude Code.1MIT