Skip to main content
Glama
deenesjakoruzh
jj-cheng25

weixin-articles-mcp

by jj-cheng25
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

weixin-articles-mcp

用于读取 微信公众号文章 的 MCP 服务器，提供原生多模态输出——图片和视频关键帧以内容块形式返回，而非 URL。

仅供个人/研究使用。 本工具仅读取公开可访问的文章 URL，不会绕过任何身份验证或反爬虫措施。使用前请参阅 免责声明。

License: MIT Python 3.10+ GitHub stars

为什么需要这个工具

其他为 LLM 读取微信文章的工具通常返回 图片 URL 列表 —— 你的 LLM 必须点击链接才能真正看到图片，这会增加额外的往返请求并消耗上下文。

本服务器直接返回 图片本身，以及 视频关键帧。你的 LLM 可以一次性看到你所看到的内容。

工具

文章正文

图片

视频

WebFetch (内置)

✅ (常被反爬虫拦截)

❌ 仅 URL

❌

现有微信 MCP / Skills

✅

❌ 仅 URL

❌

weixin-articles-mcp

✅

✅ 原生图片块

✅ 关键帧作为图片块

Related MCP server: WeChat Article Parser

功能特性

  • 📰 可靠的微信抓取 — 纯 Python httpx GET 请求，无需 Rust 二进制文件或无头浏览器

  • 🖼️ 原生图片内容 — PNG/JPG 以 MCP Image 块返回，过滤 GIF，每篇文章上限 10 张

  • 🎬 支持三种嵌入类型的视频处理：

    • 微信公众号原生视频 (<iframe data-mpvid="wxv_*">)：从内联 JS 中提取 mp4，通过 ffmpeg 生成 8 帧均匀分布的关键帧

    • 腾讯视频 (v.qq.com iframe)：通过 yt-dlp + ffmpeg 生成关键帧

    • 微信视频号 (<mp-common-videosnap>)：通过公共 batch_get_video_snap API 获取完整元数据（时长、尺寸、高清封面、完整描述、点赞数、发布者认证）+ 封面图。mp4 流受微信 finder 协议保护 — 详见下文 为什么不支持视频号 mp4？

  • 🕒 发布时间恢复 — 提取其他解析器遗漏的 var ct Unix 时间戳

  • 🪶 极简安装 — pip install + 可选的 ffmpeg（用于视频）；无需 Chromium，无需 Rust

安装

# Core (article + images)
pip install weixin-articles-mcp

# With video keyframe support
pip install "weixin-articles-mcp[video]"
brew install ffmpeg   # or apt install ffmpeg on Linux

配置

Claude Desktop / Claude Code

{
  "mcpServers": {
    "weixin-articles": {
      "command": "weixin-articles-mcp"
    }
  }
}

Cursor / Cline

使用相同的 JSON，放入客户端的 MCP 服务器配置中即可。

使用方法

配置完成后，只需将微信文章 URL 粘贴到对话中：

Read https://mp.weixin.qq.com/s/cexkyzQBRDG3uIF6g5cEbQ

你的 LLM 将收到：

  • 文章元数据（标题、公众号、发布时间、封面 URL）

  • Markdown 格式的完整文章正文

  • 所有内联 PNG/JPG 图片作为原生图片内容块

  • 每个视频对应 8 张关键帧图片

工具参考

read_article(url: str) -> list[content_block]

返回一个 MCP 内容块列表：

  • [0] — 文本块：元数据 + 文章正文 Markdown

  • [1..N] — 图片块：文章图片（最多 10 张，已过滤 GIF）

  • 每个视频（最多 3 个）：

    • 微信原生或腾讯视频：一个文本标记 + 8 个关键帧图片块

    • 微信视频号：一个文本标记（包含时长、尺寸、点赞数、发布者、描述）+ 1 个高清封面图片块

失败时，返回一个以 Error: 开头的文本块。

开发路线图

  • [x] 具备反爬虫处理的微信文章抓取

  • [x] 原生图片内容块

  • [x] 微信公众号原生视频关键帧提取

  • [x] 腾讯视频关键帧提取

  • [x] 通过公共 API 丰富微信视频号元数据

  • [ ] 通过 faster-whisper 实现 ASR 字幕（针对原生 + 腾讯视频）

  • [ ] 已读文章全文搜索

  • [ ] 公众号订阅 / 新文章通知

为什么不支持视频号 mp4？

简而言之：文章中的微信视频号视频刻意不向公共网络访问暴露可下载的 mp4 流。mp4 位于微信的 finder 协议内，该协议需要 (a) 已登录的微信客户端会话，(b) finder 特定的加密（mp4 的前 128KB 使用固定密钥进行 XOR 加密），以及 (c) 在网络层拦截来自微信 PC 客户端的流。

市面上所有开源的微信视频号下载器 —— ltaoo/wx_channels_download, qiye45/wechatVideoDownload, putyy/res-downloader, KingsleyYau/WeChatChannelsDownloader 等 —— 都是通过 MITM HTTPS 代理 + 微信 PC 客户端 + 根证书安装 来解决的。这种模式与 MCP 服务器的运行方式（无客户端、无用户交互、无管理员安装）根本不兼容。

我们采取的替代方案是：调用微信的公共 batch_get_video_snap API（无需 Cookie 或会话），为你的 LLM 提供次优选择 —— 高清封面图、完整描述、时长、尺寸、点赞数和发布者认证。对于大多数用例（阅读和总结文章），这足以传达视频的核心内容。

如果你确实需要 mp4 文件，请在此 MCP 之外安装上述专用工具之一 —— 它们可以互补使用。

架构

src/weixin_articles_mcp/
├── server.py     # FastMCP entrypoint, tool registration
├── fetcher.py    # httpx GET with browser UA
├── parser.py     # WeChat DOM extraction (BeautifulSoup + lxml)
├── markdown.py   # HTML → Markdown (markdownify subclass)
└── media.py      # Image download + video download/keyframe extraction

贡献

欢迎提交 PR。特别期待在以下方面获得帮助：

  • 微信视频号 URL 处理

  • 对不常见发布者模板变体的适应性

  • 更多的测试用例（不同文章风格）

提交 Issue: https://github.com/jj-cheng25/weixin-articles-mcp/issues

免责声明

本工具仅供 个人、教育和研究使用。

本工具的功能：

  • 使用标准浏览器 User-Agent 读取公开可访问的微信文章 URL (mp.weixin.qq.com/s/...) —— 这与任何使用网页浏览器的用户所看到的内容相同

  • 仅调用接受空身份验证字段的公共微信 API 端点（即微信设计为无需登录即可访问的接口）

  • 强制执行默认 1 秒的请求最小间隔，以防止本工具被滥用为高频爬虫

本工具 不 做以下事情：

  • 使用 Cookie、登录会话或任何形式的用户凭据

  • 绕过任何技术保护、反爬虫措施或加密流（例如，微信视频号 mp4 刻意 不 支持 —— 详见 为什么不支持视频号 mp4？）

  • 解密、逆向工程或规避微信的协议级保护

  • 在即时响应之外存储、缓存或重新分发抓取的内容

用户责任：

  • 使用本工具时请 遵守微信的服务条款。个人/研究用途的公开文章阅读通常符合内容预期的消费方式；高频抓取或商业再分发则可能不符合。

  • 尊重版权。文章内容归原作者和发布者所有；本工具仅抓取并转发给你的 LLM 进行内联处理。

  • 不要对 mp.weixin.qq.com 进行洪水式请求 —— 请保持人类阅读频率。默认速率限制设置较为保守，你可以通过在环境中设置 WEIXIN_FETCH_INTERVAL_S=2.0（或更高）来进一步收紧。

本项目作者和贡献者不对因滥用而产生的任何责任负责。使用本软件即表示你完全承担确保你的使用符合适用法律及所连接服务条款的责任。

许可证

MIT — 详见 LICENSE。

Available Tools

1 tool
read_articleA

Read a WeChat Official Account article (mp.weixin.qq.com/s/...) and return its content as a multimodal block list:

  • First text block: title, account, publish time, cover URL, video count, and the full article body in Markdown.

  • Image blocks: the article's PNG/JPG images (GIFs filtered out, capped at

    1. returned as native image content so the LLM can see them directly.

  • Per-video groups: a text marker video kind=... vid=... keyframes=N followed by N evenly-spaced keyframe images (capped at 3 videos).

On failure the response is a single text block starting with "Error:".

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesA WeChat article URL, format: https://mp.weixin.qq.com/s/xxx

TDQS

A4.2/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description fully discloses behavior: return format (title, account, time, cover, video count, Markdown body), image handling (GIFs filtered, cap at 10), video keyframes (cap at 3), and error format (single text block starting with 'Error:'). This is comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed but efficiently structured: a concise overview followed by a well-organized list of return components. Every sentence adds value, though slightly verbose due to thoroughness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one parameter, no output schema, and no annotations, the description provides complete guidance: input format, full output structure with all edge cases (errors, caps, filtering). An agent can invoke it correctly without additional info.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage and a single parameter 'url' already described in schema, the description adds only marginal value by repeating the URL format and specifying it's for WeChat account articles. Baseline meets expectation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads a WeChat Official Account article and returns its content as a multimodal block list. It specifies the URL format and details the output structure, leaving no ambiguity about the tool's function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly provide when or when not to use this tool, nor does it mention alternatives (though none exist in context). Usage is implied but not formally guided.

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.

  1. 1 tool updatev0.1.0
    • First observedread_article
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no ambiguity between tools. The single tool 'read_article' has a clear, distinct purpose.

Naming Consistency5/5

The single tool name 'read_article' follows a clear verb_noun pattern. Consistency is not an issue with one tool.

Tool Count4/5

One tool is appropriate for the narrow purpose of reading WeChat articles given a URL. While minimal, it matches the server's focused scope.

Completeness3/5

The tool reads articles thoroughly, but lacks any discovery or listing capabilities. For a server named 'weixin-articles-mcp', the absence of search or listing is a notable gap.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers