WeChat Publisher MCP Server

Overview Schema Source Related Servers Discussions Admin

wechat_get_article_stats

Retrieve cumulative WeChat article read, share, and favorite counts by publication date, limited to snapshots within 30 days after publishing; results are not real-time.

Instructions

按发表日期读取文章累计阅读、分享、收藏人数；不是实时数据，msgId 与 articleId 不通用

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "date": "<date>"
    },
    "name": "wechat_get_article_stats"
  }
}

Input Schema

Name	Required	Description	Default
`date`	Yes	文章发表日期 YYYY-MM-DD；查询发表后最多 30 天内的累计统计快照
`msgId`	No	可选：统计接口返回的 msgId（含文章序号），不是 articleId

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Oct 28, 2026

TDQS

A3.8/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 and does add real behavioral context: the data is a non-real-time cumulative snapshot, and msgId is not interchangeable with articleId — a genuine footgun warning. It omits permission requirements, rate limits, and error behavior for out-of-window dates, keeping it short of a 5.

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?

A single compact sentence with two clauses, front-loading the core operation and then the two key constraints. No filler whatsoever.

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 two-parameter read tool with full schema coverage and no output schema, the description names the returned metrics (reads, shares, favorites) and flags data staleness, which is enough to call it correctly. Minor gap: no mention of behavior for dates outside the 30-day window.

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 description coverage is 100%, so both parameters are already documented, including the 30-day snapshot window and the msgId caveat. The description reinforces the msgId/articleId distinction but adds no syntax or format information beyond the schema, so baseline 3 applies.

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?

States a specific verb and resource in Chinese: read cumulative reads/shares/favorites for an article by publication date. It is clearly distinguishable from wechat_list_articles and the upload/draft siblings, though it never names an alternative explicitly.

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?

Usage is implied through '按发表日期' (by publication date) and the note that data is not real-time, which hints at when the tool is appropriate. However, it never states when to prefer this over wechat_list_articles or what to do if the date is outside the valid window.

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

Deploy Server