Enables reading WeChat Official Account articles by URL, returning structured Markdown with title, author, publish time, optional cover image, and article body. Supports single-article and batch retrieval (up to 10 URLs) with caching.
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., "@wechat-mcp Summarize this WeChat article: https://mp.weixin.qq.com/s/abc123"
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.
Read WeChat Official Account articles directly in Claude Code / Cursor / Windsurf. One config line. Zero API keys. Works in every MCP-compatible client.
wechat-mcp 是一个 Model Context Protocol (MCP) server，让任意 MCP 兼容的 AI 客户端（Claude Code、Claude Desktop、Cursor、Windsurf、Cline 等）直接读取微信公众号文章。
为什么需要它？微信公众号的 robots.txt 禁止了自动化访问，fetch_web、curl 默认情况下都拿不到 mp.weixin.qq.com 下的文章正文。wechat-mcp 绕过这个限制，把文章转成结构化 Markdown 直接喂给你的 AI。
把下面这段贴进 Claude Code：
帮我总结一下这篇文章：https://mp.weixin.qq.com/s/xxxxxxxxxxxxxClaude Code 自动调用 read_wechat_article 工具 → 返回标题、作者、正文 → 总结给你。
~/Library/Application Support/Claude/claude_desktop_config.json（macOS）
或 %APPDATA%\Claude\claude_desktop_config.json（Windows）：
{
"mcpServers": {
"wechat": {
"command": "npx",
"args": ["-y", "wechat-mcp"]
}
}
}重启 Claude Desktop。搞定。
~/.cursor/mcp.json：
{
"mcpServers": {
"wechat": {
"command": "npx",
"args": ["-y", "wechat-mcp"]
}
}
}~/.claude.json 或项目内 .claude/settings.json：
{
"mcpServers": {
"wechat": {
"command": "npx",
"args": ["-y", "wechat-mcp"]
}
}
}read_wechat_article读取一篇微信文章并返回 Markdown。
输入：
url (string, 必填) — mp.weixin.qq.com 域名的微信文章 URL
include_images (boolean, 默认 true) — 是否包含内联图片
max_length (number, 默认 20000) — 返回内容的最大字符数
输出： 标题 / 作者 / 发布时间 / 封面图（可选）/ Markdown 正文
read_multiple_wechat_articles批量读取最多 10 篇文章。
输入：
urls (string[], 必填, 1-10 项) — URL 列表
微信公众号对 fetch/curl 默认 UA 返回降级 HTML，且 robots.txt 声明禁爬。wechat-mcp 通过模拟桌面 Chrome UA 直接发 HTTP 请求拿原始 HTML，再用两套解析器兜底：
标准路径：从 js_content div 提取正文 + 处理内嵌图片
新版文章路径：从 JS 变量 cgiDataNew.content_noencode 解码（处理 type 9 / 10002 文章）
两套都拿不到时返回结构化错误（404、需关注公众号、登录墙）。
默认 30 分钟 TTL，进程内最多缓存 200 篇文章。同 URL 重复调用直接命中缓存，不会反复打微信服务器。
Node.js ≥ 18
MCP SDK ≥ 1.0
Claude Code / Claude Desktop / Cursor / Windsurf / Cline / 任意 stdio MCP 客户端
不支持需要登录/付费的会员文章
不支持视频号内容（仅图文文章）
不支持已被删除/违规下架的文章
高频调用建议加你自己的节流层
知乎文章 Provider（同样的"读不到"痛点）
CSDN / 掘金 Provider
微信公众号 RSS 监控模式（定时拉取更新）
多账号 cookie 池（突破登录墙）
欢迎 PR！思路：
新增 Provider：在 src/providers/ 下实现 fetch(url) => Markdown 接口
新增 MCP 工具：在 server.ts 注册 + 在 README 文档化
修复微信页面结构变化：跑一下 pnpm test，附上原文链接
MIT © 2026 lfc1402046
Related MCP server: readgzh
wechat-mcp is a Model Context Protocol server that lets any MCP-compatible AI client (Claude Code, Claude Desktop, Cursor, Windsurf, Cline, …) read WeChat Official Account articles directly.
Why? WeChat's robots.txt blocks automated access, and fetch/curl cannot reach mp.weixin.qq.com by default. wechat-mcp bypasses this and returns the article as clean Markdown.
Add this to your MCP client config:
{
"mcpServers": {
"wechat": {
"command": "npx",
"args": ["-y", "wechat-mcp"]
}
}
}That's it. Restart the client and ask your AI to read any mp.weixin.qq.com URL.
read_wechat_article — read one article, return Markdown
read_multiple_wechat_articles — batch up to 10 URLs
MIT
Read up to 10 WeChat articles at once and return each as Markdown. Use when the user provides a batch of URLs (e.g. from a list they want summarized).
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | List of WeChat article URLs (each must be mp.weixin.qq.com) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that this is a read operation and that results come back as Markdown with a max of 10 articles, but it omits per-URL failure behavior, whether one bad URL fails the batch, and any auth or rate-limit constraints.
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 tight sentences, zero waste, with the core capability front-loaded before the usage condition.
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 one-parameter read tool with no output schema, the description covers purpose, batch limit, output format, and usage context. It could be more complete about partial failures in a batch, but it is otherwise sufficient.
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%, and the schema already documents the array, min/max items, and required mp.weixin.qq.com domain. The description adds only the batch-size framing, 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?
States a specific verb and resource ("Read ... WeChat articles") plus the batch limit and Markdown return format. The word "multiple" and "up to 10 ... at once" implicitly distinguishes it from the singleton sibling read_wechat_article, though it does not name that sibling explicitly.
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?
Gives a clear triggering context: "Use when the user provides a batch of URLs (e.g. from a list they want summarized)." It does not explicitly state when to use the sibling single-article tool instead, but the batch condition is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a WeChat Official Account (mp.weixin.qq.com) article and return its title, author and Markdown body. Use this whenever the user shares a mp.weixin.qq.com URL or asks you to summarize/read a WeChat article. Returns up to 20,000 chars by default.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | WeChat article URL (must be mp.weixin.qq.com) | |
| max_length | No | Max characters in the returned content (default 20000) | |
| include_images | No | Include inline images in the Markdown (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description does extra work by explaining what is returned: title, author, and Markdown body. It also discloses that content is capped at up to 20,000 characters by default, which is useful behavioral context beyond the schema. It does not cover error cases or restrictions such as inaccessible or deleted articles.
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 three tightly written sentences with no filler. The core action is front-loaded, followed by usage guidance and the truncation default. Every sentence contributes useful 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?
For a simple three-parameter read tool with a fully documented schema, the description covers purpose, invocation context, return fields, and default truncation. It does not mention the multi-article sibling or failure modes, but those are not strictly required for correct invocation. It is nearly complete for this tool's complexity.
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 all three parameters are already documented in the input schema. The description reinforces the mp.weixin.qq.com URL constraint and the 20,000-character default but adds little parameter meaning beyond the schema. 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 states a specific verb and resource: read a WeChat Official Account article and return its title, author, and Markdown body. It clearly establishes the tool as a single-article reader. It does not explicitly distinguish itself from the sibling read_multiple_wechat_articles tool.
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?
It gives a clear usage condition: use whenever the user shares a mp.weixin.qq.com URL or asks to summarize/read a WeChat article. That covers the primary invocation context well. It does not mention when to use the multi-article sibling instead, so it stops short of explicit alternatives.
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.0read_multiple_wechat_articlesread_wechat_articleScored across 2 tools
The tools are clearly differentiated based on the input scale: one handles a single item, and the other handles a list of items. There is no ambiguity for an agent deciding which function to call based on the user's request format.
The naming convention is highly consistent, using the verb 'read' as the core action for both tools. The snake_case format and structural similarity make the set very easy to read and predict.
With only two tools, the set is appropriately scoped for its singular focus on article consumption. While minimal, having separate tools for single versus batch operations is a sensible division for this specific domain.
The tools cover the core 'read' lifecycle for individual and group articles. However, the surface lacks upstream functionality like searching by keyword or listing all available articles, which would make the set more robust.
Read WeChat public account articles via MCP. 99.89% anti-scraping success, 50-87% token compression.
Jina AI Reader/Search MCP — turn any URL into clean LLM-ready markdown, plus web search.
Convert files, URLs, and documents to clean, AI-ready Markdown via MCP.
Web scraping for AI agents. Converts URLs to clean, LLM-ready Markdown with anti-bot bypass.
