Skip to main content
Glama
Tiansiyu-tj

wecom-doc-mcp

by Tiansiyu-tj
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

📄 wecom-doc-mcp

Let AI read your Enterprise WeChat docs — in real time.

MCP Node TypeScript License

English · 中文

🤔 Why

Enterprise WeChat documents sit behind SSO. AI assistants can't access them.

This MCP server bridges the gap: provide your browser cookie once, and the server handles authenticated fetching + HTML-to-Markdown conversion on every request.

💬 "帮我看下这个文档: https://doc.weixin.qq.com/doc/w3_xxx"
         │
         ▼
   ┌─────────────┐     🍪      ┌──────────────┐     📝     ┌──────────┐
   │ Claude Code  │ ──Cookie──▶ │  MCP Server   │ ──HTML──▶ │ Markdown │
   └─────────────┘             └──────────────┘            └──────────┘

Related MCP server: feishu-reader

🛠️ Tools

Tool

Description

📖 fetch_wecom_doc

Fetch a document by URL → return Markdown

🍪 set_wecom_cookie

Save cookie locally (chmod 600)

✅ check_wecom_auth

Verify if saved cookie is still valid

🚀 Quick Start

Step 1 — Install

git clone https://github.com/Tiansiyu-tj/wecom-doc-mcp.git
cd wecom-doc-mcp
npm install

Step 2 — Register with Claude Code

Add to ~/.mcp.json:

{
  "mcpServers": {
    "wecom-doc": {
      "command": "npx",
      "args": ["tsx", "/path/to/wecom-doc-mcp/src/index.ts"]
    }
  }
}

Step 3 — Get Your Cookie 🍪

1. 🌐  Open doc.weixin.qq.com → log in
2. 🔧  F12 → Network tab
3. 📋  Click any request → copy the Cookie header value

Step 4 — Use It

You:    帮我设置企业微信 Cookie: <paste>
Claude: ✅ Cookie 已保存

You:    帮我看下这个文档: https://doc.weixin.qq.com/doc/w3_xxx
Claude: # 文档标题
        这是文档的内容...

📐 Architecture

                          wecom-doc-mcp
                    ┌─────────────────────┐
                    │                     │
  fetch_wecom_doc ──┤  📡 /dop-api/opendoc│
        │           │  Call WeChat's       │
        │           │  internal API for    │──── 📝 Markdown
        │           │  document JSON data  │
        │           │                     │
        │           │  🧹 cleanDocText    │
        │           │  Strip HYPERLINK     │
        │           │  markup → clean text │
        │           │                     │
        │           │  📄 Fallback:       │
        │           │  cheerio + turndown  │
        │           └─────────────────────┘
        │
  set_wecom_cookie ─── 💾 ~/.claude/wecom-doc-mcp/.env (mode 600)
        │
  check_wecom_auth ─── 🏥 GET doc.weixin.qq.com → 200?

🔐 Cookie Auth

Two modes, your choice:

Mode

How

When

💾 Persistent

set_wecom_cookie → saved to ~/.claude/wecom-doc-mcp/.env

Set once, use forever (until expiry)

⚡ Per-request

Pass cookie param to fetch_wecom_doc

Override on the fly

🔒 Cookie file lives outside the project directory — never committed, never shared, chmod 600.

📑 Supported Document Types

Type

URL Pattern

Status

📝 Documents

/doc/

✅ Verified

📊 Spreadsheets

/sheet/

🔧 Untested

🎞️ Slides

/slide/

🔧 Untested

🧠 Mind Maps

/mind/

✅ Verified

🔀 Flowcharts

/flowchart/

🔧 Untested

📋 Smart Sheets

/smartsheet/

🔧 Untested

📦 Tech Stack

Dependency

Purpose

@modelcontextprotocol/sdk

MCP protocol implementation

cheerio

HTML parsing

turndown

HTML → Markdown conversion

tsx

TypeScript runtime

📄 License

MIT

Available Tools

3 tools
check_wecom_authA

检查当前保存的 Cookie 是否仍然有效

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/5.0
Behavior2/5

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

No annotations exist, so the description must disclose behavioral traits. It only states the purpose without clarifying what happens if the cookie is invalid, whether the operation is read-only, or any 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.

Conciseness5/5

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

The description is a single, concise sentence with no extraneous information. It is appropriately front-loaded for quick comprehension.

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

Completeness3/5

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

Given zero parameters, no output schema, and simple purpose, the description is adequate but incomplete. It does not describe the return value or behavior on failure, leaving the agent uncertain about the tool's output.

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

Parameters4/5

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

No parameters defined, so schema coverage is 100%. Per guidelines, 0 params yields a baseline of 4. The description does not need to add parameter details.

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 checks whether the saved Cookie is still valid, using a specific verb and resource. It is distinct from siblings (fetch_wecom_doc, set_wecom_cookie) which handle document fetching and cookie setting.

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

Usage Guidelines4/5

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

The context suggests this tool is for verifying authentication before using sibling tools, but no explicit when-to-use or when-not-to-use guidance is provided. The sibling names imply usage order.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fetch_wecom_docA

抓取企业微信文档内容并转为 Markdown。支持文档、表格、幻灯片等类型。

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes企业微信文档链接，如 https://doc.weixin.qq.com/doc/xxx
cookieNo可选，临时 Cookie。不传则使用已保存的 Cookie

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description bears full responsibility for behavioral disclosure. It explains the core conversion action and notes supported file types, but fails to mention error handling, rate limits, authentication requirements beyond an optional cookie, or any side effects. The description is adequate but not comprehensive.

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

Conciseness5/5

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

The description is extremely concise—a single sentence in Chinese—that immediately conveys the core action (fetch and convert) and scope (document types). It is front-loaded and contains no filler. Every word carries meaning.

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

Completeness2/5

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

Given the presence of sibling auth tools and no output schema, the description lacks crucial context. It does not explain prerequisites (e.g., need for prior authentication via set_wecom_cookie), what happens if cookie is invalid, or the format of the returned Markdown. For a tool with two parameters and moderate complexity, this is insufficiently complete.

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?

Schema coverage is 100% with clear descriptions for both parameters: URL example and cookie explanation. The tool description adds general capability info but not parameter-specific details. Since the schema already covers parameter meanings, baseline 3 is appropriate; the description does not significantly enhance parameter understanding beyond the schema.

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's purpose: fetching WeCom document content and converting to Markdown, supporting various types like docs, tables, and slides. The name fetch_wecom_doc aligns perfectly, and siblings set_wecom_cookie and check_wecom_auth are distinct auth-related tools, making differentiation easy.

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 implies usage for converting WeCom documents to Markdown but does not explicitly state when to use this tool versus alternatives or prerequisites. It mentions optional cookie but does not clarify if prior cookie setting (via sibling tool) is needed for successful fetch. No exclusions or conditions provided.

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. Dates show when Glama detected each change.

  1. 3 tool updatesv1.0.0
    • First observedcheck_wecom_auth
    • First observedfetch_wecom_doc
    • First observedset_wecom_cookie
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0
Disambiguation5/5

Each tool has a distinct purpose: fetching document content, saving authentication credentials, and verifying authentication validity. No overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case: fetch_wecom_doc, set_wecom_cookie, check_wecom_auth.

Tool Count5/5

With 3 tools, the server is well-scoped for its purpose of fetching WeCom documents with authentication management. Each tool earns its place.

Completeness4/5

The set covers authentication setup, validation, and document fetching. A minor gap is the lack of a tool to list or search documents, but the core workflow is complete for fetching known documents.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Weixin MCP

    Bwkyd
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables reading and extracting content from WeChat public account articles using browser automation, allowing AI models to analyze and summarize WeChat articles through natural language requests.
    447
    MIT

  • doc-hub-mcp

    wxkingstar
    F
    license
    Not graded
    quality
    C
    maintenance
    Provides retrieval of WeChat Work and Feishu developer documentation, enabling AI assistants to query API references without switching browsers.
    18
    19
    -

  • yuque-cookie-mcp

    dove-yang
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI assistants to manage Yuque (语雀) documents via MCP protocol, with cookie-based login that does not require a super membership.
    13
    1
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Tiansiyu-tj/wecom-doc-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server