LivePage · 活页

Send this page’s live version to WeChat

push_to_wechat

Send this page’s CURRENT LIVE version to WeChat as a service-account template message. By default (to omitted or "self") it goes to YOU ONLY — the account calling this tool — whether or not the workspace has other members; nobody else receives anything. to: "members" sends it to the people in this workspace instead (the creator plus every member; you are excluded when “also send to me” is off). It is never sent to clients — forward them the link instead. Pass include_subscribers: true to also send it to this page’s subscribers (each person gets a version once, and at most one reminder a day). The receipt’s first line is the same sentence the publish receipt uses — “This time it will notify: you, 2 teammate(s), 5 subscriber(s) (4 reachable)” — relay it to the user as is. Each person receives their own personal link, created on first send and reused afterwards, so reading activity shows who opened it. This ignores the workspace’s automatic-push switch: it is a manual send. AUTOMATIC DEDUPLICATION: each person gets a given version once — automatic push, publishing, this tool and subscriber reminders share one ledger. When automatic push is on, publishing has already sent it, so there is no need to call this tool; a repeat call sends nothing and the receipt says “already sent (automatic push · 14:03), not sent again”. Pass force: true only when the user really wants it again (only with to: "self", at most 5 times a day). People who have not followed the service account do not receive it, and the receipt reports those separately (not followed / refused / no WeChat binding) — that is not an error. A page with no live version is rejected with a clear 409 rather than silently doing nothing. When YOU did not receive it (no WeChat binding or not following), the receipt includes a binding QR code (an image plus bind_qr_image_url): once the user scans it in WeChat, the binding completes within seconds and this page is re-sent to them only — no second call needed. Never tell the user to “sign in by scanning in WeChat” — that creates a separate account. When the user says “send it to my WeChat”, call this tool; when the user is on a computer and only wants the page just published in their own phone’s WeChat, the publish receipt’s push_qr_url code also works — one WeChat scan, no account linking.

Input Schema

Name	Required	Description
`to`	No	Who receives it: self (default) = only you; members = the people in this workspace (the creator plus every member)
`force`	No	true = 这一版你已经收到过、仍要再收一次（只能配 to="self"，每人每天最多 5 次）。不传 = 已推过的不再重复发
`proposal_id`	Yes	要推哪一份，`list_proposals` 里的 proposal_id
`include_subscribers`	No	true = also send to this page’s subscribers (each person gets a version once, and at most one reminder a day). Omit = only people in the workspace

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 21, 2026

addedInput schema / properties / force

Added value: +{
+  "description": "true = 这一版你已经收到过、仍要再收一次（只能配 to=\"self\"，每人每天最多 5 次）。不传 = 已推过的不再重复发",
+  "type": "boolean"
+}

Changed1 schema field changedOct 13, 2026

addedInput schema / properties / to

Added value: +{
+  "description": "Who receives it: self (default) = only you; members = the people in this workspace (the creator plus every member)",
+  "enum": [
+    "self",
+    "members"
+  ],
+  "type": "string"
+}

Changed1 schema field changedOct 6, 2026

addedInput schema / properties / include_subscribers

Added value: +{
+  "description": "true = also send to this page’s subscribers (each person gets a version once, and at most one reminder a day). Omit = only people in the workspace",
+  "type": "boolean"
+}

First observedOct 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes far beyond the annotations: discloses the shared deduplication ledger across automatic push/publishing/this tool, the force limit (5/day, self only), the 409 on missing live version, the QR binding flow, and that non-followers are reported but not errors. These are exactly the mutation traits (idempotentHint=false, openWorldHint=true) an agent needs to reason about 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.

Conciseness4/5

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

Front-loaded with the core action and default before the edge cases, and every clause carries operational detail. It is dense and long, with mild repetition of the dedup concept, but the length is largely justified by the behavioral quirks it must disclose.

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?

No output schema exists, yet the description describes the receipt's first line, the dedup message, the failure categories, and the bind_qr_image_url — so an agent knows exactly what comes back and how to relay it. Nothing essential for correct invocation is missing.

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 schema already documents each param. The description adds meaning beyond it — e.g., that `to: "members"` excludes the caller when "also send to me" is off, and how `force` interacts with the dedup ledger — though it largely restates the schema's own wording for `to` and `include_subscribers`.

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?

States a specific verb and resource — sending the page's CURRENT LIVE version as a WeChat template message — and immediately distinguishes itself from alternatives like automatic push and the publish receipt's push_qr_url. An agent can tell what this does versus set_publish_notify or publish_version without opening the schema.

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?

Explicitly says when to call it ("when the user says send it to my WeChat"), when not to (automatic push already sent it — no need to call), and offers the alternative path (publish receipt's push_qr_url for computer users). Defaults, exclusions, and the force caveat are all laid out.

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

All LivePage · 活页 tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?