Skip to main content
Glama

Set post-publish WeChat notifications

set_publish_notify
Idempotent

Owner only. Control the three notifications this workspace sends after publishing, all WeChat service-account template messages sent only to people in the workspace and never to clients: auto_push sends each new live version to WeChat automatically, one personal link per person; include_me decides whether that automatic push also reaches whoever triggered the publish; unread_remind tells the author once when a page has been published for seven days without anyone opening it (once per page). Pass only the switches you want to change; the others keep their current value. With auto_push off you can still send a specific page with push_to_wechat; with it on, publishing already sends it — no need to call push_to_wechat as well (each person gets a version once; repeat calls are deduplicated automatically). People who have not followed the service account cannot receive these: the switch being on does not mean delivery — the receipt from push_to_wechat is what tells you. When YOU have no WeChat binding or have not followed the service account, the receipt includes a binding QR code (an image plus bind_qr_image_url): the user scans it in WeChat, which follows the service account and links that WeChat to the current account in one step. Never tell the user to “sign in by scanning in WeChat” — that creates a separate account. Calling it with no arguments only reports the current state and hands out the code when needed; when the user says they have scanned, call it again to confirm. For ONE page only, also pass proposal_id: auto_push then sets that page (true = notify for this page even when the workspace is off; false = do not notify for this page, neither people nor subscribers; null = follow the workspace again); proposal_id alone reports whether the page is notified. include_me and unread_remind are workspace-wide and cannot be combined with proposal_id. For a single small edit, leave the switches alone and pass quiet: true to publish_file / finalize_upload / publish_version. SUBSCRIBE CODES (for clients, managers or family — not workspace members): whenever proposal_id is passed, the result also carries that page’s subscribe code (an image plus subscribe_code.qr_image_url). One WeChat scan follows the service account and subscribes that person to the page, so new versions reach them as WeChat reminders. The default code is the same one as in the publish receipt; for a code with a note for one person add subscribe_code_label (such as “for Mr. Wang”; the same label returns the same code). Passing proposal_id + subscribe_code_label without auto_push only issues the code, without reading or changing switches, and needs editor rather than owner. Pages that are private, suspended or published without signing in get no code, and the result says why. SUBSCRIBER LIST (who subscribed to the page, shown by get_engagement_summary as one line per person with a row number, grouped by source code): revoke_subscribe_code (a code_id) revokes a code — scanning it no longer subscribes anyone, and everyone who subscribed through it is unsubscribed; remove_subscriber (a row number) removes one person. Both need proposal_id and editor rather than owner; passing only them (without auto_push / subscribe_code_label) only edits the list and issues no code. Confirm with the user which code or row before doing either. SUBSCRIBE TO A FOLDER (for weekly or daily issues — no new code for every issue): pass folder_id (optionally with subscribe_code_label) to get that folder’s subscribe code. One scan subscribes the person to the whole folder: any page in it getting a new version, or a new page being added, sends a reminder (at most one a day per subscription); pages marked internal do not notify. folder_id cannot be combined with proposal_id or the switches; folders visible only to you get no code.

Input Schema

NameRequiredDescriptionDefault
auto_pushNoPush each new live version to WeChat automatically; with proposal_id it changes this page only, and null returns the page to the workspace setting
folder_idNo拿某个文件夹的订阅码时传(`list_folders` 里的 folder_id):扫了订上整个文件夹,夹里有新版本或新的一页都提醒。不能和 proposal_id / 开关一起传
include_meNo自动推送也发给触发发布的那个人本人
proposal_idNo只管这一页时传(`list_proposals` 里的 proposal_id):看 / 改这一页的提醒,并附上这一页的订阅码;不传 = 改整个工作区
unread_remindNo发布七天没人打开时提醒作者一次
remove_subscriberNoRemove one person from the subscriber list (row number, from the subscriber list in get_engagement_summary); future updates of this page will not remind them. Requires proposal_id; confirm with the user first
subscribe_code_labelNo订阅码的备注(≤ 20 字,如「给王总」),只有作者自己看得到;不传 = 这一页的默认码。需要同时传 proposal_id
revoke_subscribe_codeNoRevoke one of this page’s subscribe codes (code_id, from the subscriber list in get_engagement_summary): scanning it no longer subscribes anyone, and everyone who subscribed through it is unsubscribed. Requires proposal_id; confirm with the user first

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / show_update_note
      Removed value: -{
      -  "description": "从更新提醒点进这一页时,顶部出不出「本次更新」横条(+「看改了哪」)。默认关 = 直接看最新版;true = 打开,false = 关回去。需要同时传 proposal_id",
      -  "type": "boolean"
      -}
  2. Changed1 schema field changed
    • addedInput schema / properties / show_update_note
      Added value: +{
      +  "description": "从更新提醒点进这一页时,顶部出不出「本次更新」横条(+「看改了哪」)。默认关 = 直接看最新版;true = 打开,false = 关回去。需要同时传 proposal_id",
      +  "type": "boolean"
      +}
  3. Changed8 schema fields changed
    • addedInput schema / properties / auto_push / anyOf
      Added value: +[
      +  {
      +    "type": "boolean"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedInput schema / properties / auto_push / description
      Previous value: -"有新版本发布时自动推到微信"New value: +"Push each new live version to WeChat automatically; with proposal_id it changes this page only, and null returns the page to the workspace setting"
    • removedInput schema / properties / auto_push / type
      Removed value: -"boolean"
    • addedInput schema / properties / folder_id
      Added value: +{
      +  "description": "拿某个文件夹的订阅码时传(`list_folders` 里的 folder_id):扫了订上整个文件夹,夹里有新版本或新的一页都提醒。不能和 proposal_id / 开关一起传",
      +  "maxLength": 26,
      +  "minLength": 26,
      +  "type": "string"
      +}
    • addedInput schema / properties / proposal_id
      Added value: +{
      +  "description": "只管这一页时传(`list_proposals` 里的 proposal_id):看 / 改这一页的提醒,并附上这一页的订阅码;不传 = 改整个工作区",
      +  "maxLength": 26,
      +  "minLength": 26,
      +  "type": "string"
      +}
    • addedInput schema / properties / remove_subscriber
      Added value: +{
      +  "description": "Remove one person from the subscriber list (row number, from the subscriber list in get_engagement_summary); future updates of this page will not remind them. Requires proposal_id; confirm with the user first",
      +  "maxLength": 16,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / revoke_subscribe_code
      Added value: +{
      +  "description": "Revoke one of this page’s subscribe codes (code_id, from the subscriber list in get_engagement_summary): scanning it no longer subscribes anyone, and everyone who subscribed through it is unsubscribed. Requires proposal_id; confirm with the user first",
      +  "maxLength": 40,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / subscribe_code_label
      Added value: +{
      +  "description": "订阅码的备注(≤ 20 字,如「给王总」),只有作者自己看得到;不传 = 这一页的默认码。需要同时传 proposal_id",
      +  "maxLength": 40,
      +  "type": "string"
      +}
  4. First observed

TDQS

A3.6/5.0
Behavior2/5

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

The description adds genuinely useful behavior beyond the annotations: owner-only access, per-person deduplication, the caveat that 'the switch being on does not mean delivery', the QR binding flow, and the one-scan folder subscription semantics. However, it explicitly documents removal/unsubscription operations ('everyone who subscribed through it is unsubscribed', remove_subscriber) that require user confirmation, while the annotation declares destructiveHint: false — a mismatch between the declared safety profile and the described effects.

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

Conciseness2/5

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

It is a dense wall of text mixing at least four distinct behaviors (workspace switches, single-page overrides, subscribe codes/subscriber lists, folder subscriptions) into one run-on block. After the strong first sentence, information is not front-loaded by task, and the result is far longer than needed to route the agent correctly.

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 an 8-parameter, 0-required, multi-mode tool with no output schema, the description compensates well: it explains the receipts, the bind QR ('bind_qr_image_url'), the subscribe code ('subscribe_code.qr_image_url'), and why some pages get no code. It is close to complete, held back only by the safety-profile gap and the fact that the delegation modes (revoke_subscribe_code, remove_subscriber) are buried rather than signposted.

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?

Schema coverage is 100%, so the baseline is 3, but the description goes well beyond the schema by codifying cross-parameter combinatorics the schema cannot express: proposal_id alone = read-only report, proposal_id + subscribe_code_label without auto_push = issue code only, null auto_push = revert to workspace setting. This is real added meaning; it loses a point only because several schema descriptions are in Chinese and partly duplicated rather than complemented.

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 opening 'Owner only. Control the three notifications this workspace sends after publishing' states a specific verb+resource and immediately distinguishes the three switches (auto_push, include_me, unread_remind). It also differentiates from the sibling push_to_wechat ('with auto_push off you can still send a specific page with push_to_wechat'). The only weakness is scope drift: the tool also issues/subscribes/revokes codes and edits subscriber lists, so 'set_publish_notify' as a single label understates what the agent is invoking.

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

Usage Guidelines5/5

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

Guidance is unusually explicit: when to call push_to_wechat vs rely on auto_push, when to pass proposal_id vs folder_id, and hard exclusions ('include_me and unread_remind are workspace-wide and cannot be combined with proposal_id'; 'folder_id cannot be combined with proposal_id or the switches'). It even routes the agent to quieter siblings (publish_file / finalize_upload / publish_version with quiet: true) for a small edit, and instructs 'Confirm with the user which code or row' before destructive edits.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources