Skip to main content
Glama
huxuanming

wechat-md-mcp-server

by huxuanming
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

微信 Markdown 转换 MCP

把 Markdown 转成适合微信公众号的内联样式 HTML。服务只负责渲染输出，复制富文本交给用户现有工作流（浏览器、Doocs/md、WeMD、mdnice 等）。

工具

工具

说明

convert_markdown_to_wechat_html

Markdown → 内联样式 HTML 字符串

open_wechat_html_in_browser

将 HTML 存入缓存并在浏览器中打开，全选复制后可直接粘贴到公众号编辑器

list_wechat_themes

返回可用主题列表

转换成功后自动缓存 HTML 到 ./.cache/wechat-mcp/，可通过 WECHAT_MCP_CACHE_DIR 环境变量覆盖。

Related MCP server: Xiayan MCP Server

运行

uvx --from "git+https://github.com/huxuanming/wechat-md-mcp-server.git" wechat-md-mcp-server

本地开发：

uvx --from . wechat-md-mcp-server

查看可用工具：

uvx --from . wechat-md-mcp-server --list-tools

MCP 配置示例

远程（GitHub）：

{
  "mcpServers": {
    "wechat-md-mcp-server": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/huxuanming/wechat-md-mcp-server.git", "wechat-md-mcp-server"]
    }
  }
}

本地开发（推荐用 uv run，自动感知代码变化）：

{
  "mcpServers": {
    "wechat-md-mcp-server": {
      "command": "uv",
      "args": ["--directory", "/path/to/wechat-md-mcp-server", "run", "wechat-md-mcp-server"]
    }
  }
}

本地开发不要用 uvx --from /path，uvx 会缓存构建产物，代码修改后不会自动重建。

工具参数

convert_markdown_to_wechat_html

参数

类型

必填

说明

markdown

string

是

源 Markdown 文本

theme

string

否

主题，见下方列表，默认 default

title

string

否

文章标题，渲染为 h1

输出：HTML 字符串（<article>...</article>）。

list_wechat_themes

无参数，返回主题名称和描述列表。

主题

名称

风格

default

通用企业风

tech

简洁技术风

warm

暖色品牌风

apple

Apple 极简风

wechat-native

微信绿原生风

命令行工具

wechat-md-convert 可直接转换本地 Markdown 文件：

uvx --from . wechat-md-convert input.md --theme tech --out output.html

参数

说明

input

输入 Markdown 文件路径

--theme

主题（默认 default）

--title

标题覆盖

--out

输出 HTML 路径，省略则写入缓存目录

--cache-dir

覆盖缓存目录

--open

转换完成后自动在浏览器中打开，全选复制即可粘贴到公众号编辑器

支持的 Markdown 语法

  • 标题：# 到 ######

  • 段落、换行

  • 无序列表（- / * / +）、有序列表

  • 引用：>

  • 分割线：--- 或 ***

  • 粗体：**bold**，斜体：*italic*，嵌套：**bold *italic* bold**

  • 行内代码：`code`

  • 代码块：```lang ... ```

  • 链接：[text](https://...) / [text](#anchor) / [text](mailto:...)

快速验证

uvx --from . python3 - <<'PY'
import server as s
md = "# 标题\n\n这是**测试**，带[链接](https://example.com)和`代码`。"
print(s.parse_markdown(md, theme_name="default")[:300])
PY

缓存目录优先级

  1. WECHAT_MCP_CACHE_DIR 环境变量

  2. <输入文件目录>/.cache/wechat-mcp/

  3. ~/.cache/wechat-mcp/（macOS：~/Library/Caches/wechat-mcp/）

  4. 系统临时目录

Available Tools

3 tools
convert_markdown_to_wechat_htmlA

Convert Markdown to WeChat-friendly HTML with inline styles for copy/paste publishing workflows.

ParametersJSON Schema
NameRequiredDescriptionDefault
themeNoTheme name: default | tech | warm | apple | wechat-nativedefault
titleNoOptional article title rendered as h1
markdownYesSource markdown text

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the output HTML includes inline styles and is intended for copy/paste workflows, which are behavioral traits. It does not mention potential limitations or details about the conversion process, but for a pure conversion tool, it adequately describes the core behavior.

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, well-structured sentence that starts with the main verb 'Convert.' It wastes no words and immediately communicates the essential purpose and a key detail (inline styles).

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

Completeness4/5

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

The tool has a simple parameter set, and the schema covers parameters. There is no output schema, but the description implies the output is HTML. It does not mention the return format in detail, but for this straightforward conversion tool, the description is sufficient given its simplicity.

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?

The input schema has 100% coverage with descriptions for all three parameters (markdown, theme, title). The description itself adds no additional parameter information, so the baseline of 3 is appropriate. The schema already explains the parameters sufficiently.

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

Purpose4/5

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

The description clearly states that the tool converts Markdown to WeChat-friendly HTML, with a specific verb ('Convert') and resource ('Markdown to WeChat-friendly HTML'). It also mentions inline styles and publishing workflows. However, it does not explicitly differentiate from sibling tools like open_wechat_html_in_browser, though the distinct action implies differentiation.

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 description provides a clear context: 'for copy/paste publishing workflows,' indicating when to use this tool. It does not mention alternatives or exclusions, but the use case is well implied. No explicit 'when not to use' is provided, but the stated purpose is clear enough.

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

list_wechat_themesA

List available rendering themes.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It states the tool lists available themes, implying a read-only operation, but does not describe the output format, any side effects, or security considerations. It adds minimal behavioral context beyond the name.

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 sentence, directly stating the action and subject. It contains no filler or redundant information.

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

Completeness4/5

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

Given the simplicity of the tool and lack of parameters, the description is adequate. However, it does not describe what the returned theme list looks like (e.g., array of strings) or how these themes relate to the sibling tools, leaving some room for ambiguity.

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?

There are zero parameters, so the baseline of 4 applies. The description does not need to explain parameter semantics, and it correctly conveys that the tool requires no input.

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 uses a specific verb 'list' and resource 'available rendering themes', clearly distinguishing it from sibling tools that open HTML or convert Markdown to HTML.

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?

No explicit guidance on when to use this tool vs alternatives is provided. The usage is implied by the name and description—when you need to see available themes—but there is no mention of exclusions or alternative tools for related actions.

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

open_wechat_html_in_browserA

Open a cached WeChat HTML file in the default browser. Select all and copy in the browser, then paste into WeChat editor as rich text.

ParametersJSON Schema
NameRequiredDescriptionDefault
cache_pathYescache_path returned by convert_markdown_to_wechat_html

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. It states that the tool opens a file in a browser, which implies a read-only, non-destructive action, but it does not mention potential side effects like launching an external application, whether the browser will block, or what happens if the file path is invalid. The workflow instruction adds context, but some behavioral details remain implicit.

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 two sentences with no wasted words. The first sentence front-loads the core action, and the second provides essential workflow guidance. Every word earns its place, making it highly concise and well-structured.

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

Completeness4/5

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

For a simple single-parameter tool, the description covers the purpose, the workflow, and the necessary context (cached file from conversion). It doesn't elaborate on error handling or return values, but given the tool's simplicity and the schema already documenting the parameter, the description is sufficiently complete. A brief note about the file not existing would be a minor enhancement, but it's not critical.

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?

The schema covers the single parameter (cache_path) with a clear description stating it is returned by convert_markdown_to_wechat_html. The tool description adds the word 'cached' and the workflow context, but this is largely redundant with the parameter description. Baseline 3 is appropriate since the schema already provides the essential meaning.

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 action (open), the target resource (cached WeChat HTML file), and the destination (default browser). It also includes the follow-up workflow (select all, copy, paste), making the tool's purpose unambiguous and distinct from the sibling tools that convert or list themes.

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 description provides clear context: it is used after converting Markdown to WeChat HTML, as it references the cached file. The second sentence explains exactly what to do next, effectively telling the user when to use this tool (as an intermediate step) and what actions follow. It doesn't explicitly mention alternatives, but no real alternatives exist for this specific open-and-copy workflow.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0
Disambiguation5/5

Each tool serves a distinct purpose: conversion, opening in the browser, and listing themes. No overlap or ambiguity in their intended use.

Naming Consistency5/5

All tool names follow a consistent verb-first pattern (open, convert, list) with snake_case, making the set predictable and easy to navigate.

Tool Count5/5

Three tools is an ideal size for a focused Markdown-to-WeChat conversion utility, covering the essential workflow without unnecessary bloat.

Completeness5/5

The server covers the full conversion cycle: converting Markdown to HTML, previewing/opening it for copy-paste, and supporting theme selection. No obvious gaps for its stated purpose.

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

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/huxuanming/wechat-md-mcp-server'

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