sent-messaging

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Sent Messaging

Sent 消息功能

Operate direct message workflows with
messages.send
,
messages.get
, and
messages.activities.list
.
使用
messages.send
messages.get
messages.activities.list
操作直接消息工作流。

Establish connection and scope

建立连接与权限范围

  1. Let the MCP client perform OAuth 2.1/PKCE authorization. Never request, accept, print, or store tokens, API keys, authorization headers, client IDs, or secrets.
  2. Surface the organization and Sender Profile selected by the active connection before a mutation. If the client context does not expose both, use
    sent-account-readiness
    to inspect the authorized scope before continuing.
  3. Reauthorize in the client when the requested organization or Sender Profile differs from the active grant. Do not simulate a scope switch with payload fields.
  4. Minimize sensitive output. Mask phone numbers where practical and do not repeat message bodies after the operator has reviewed them.
If MCP is unsupported or authorization fails, keep the skill usable for payload planning. Explain that execution requires a compatible client or reauthorization; never ask the user to paste a credential.
  1. 让MCP客户端执行OAuth 2.1/PKCE授权。切勿请求、接受、打印或存储令牌、API密钥、授权标头、客户端ID或密钥。
  2. 在执行变更操作前,显示当前连接所选的组织和发送者配置文件。如果客户端上下文未同时暴露这两者,请先使用
    sent-account-readiness
    检查授权权限范围,再继续操作。
  3. 当请求的组织或发送者配置文件与当前授权权限不符时,在客户端重新授权。切勿通过负载字段模拟权限范围切换。
  4. 尽量减少敏感输出。尽可能屏蔽电话号码,且在操作人员查看过消息内容后,不再重复显示消息正文。
如果不支持MCP或授权失败,请确保该功能仍可用于负载规划。说明执行操作需要兼容的客户端或重新授权;切勿要求用户粘贴凭据。

Inspect a message

检查消息

  • Use
    messages.get
    for the current record when a message identifier is known.
  • Use
    messages.activities.list
    for lifecycle events and delivery evidence.
  • State that an accepted or queued send is not proof of delivery. Report delivered only when the returned state or activity establishes delivery.
  • Return identifiers, timestamps, and status evidence needed to answer the question, masking recipient data and omitting the message body unless it is necessary.
For aggregate trends, funnels, or root-cause analysis across many delivery records, hand off to
messaging-performance-analyzer
.
  • 当已知消息标识符时,使用
    messages.get
    获取当前记录。
  • 使用
    messages.activities.list
    获取生命周期事件和送达凭证。
  • 需说明,消息被接受或排队并不代表已送达。只有当返回的状态或活动确认已送达时,才可报告“已送达”。
  • 返回回答问题所需的标识符、时间戳和状态凭证,屏蔽收件人数据,除非必要,否则不显示消息正文。
如需对多条送达记录进行聚合趋势分析、漏斗分析或根本原因分析,请转交至
messaging-performance-analyzer
处理。

Prepare a send

准备发送消息

  1. Resolve the intended channel, Sender Profile, recipient, template or content, variables, scheduling inputs, and any idempotency field the tool supports. Do not invent missing values.
  2. For a high-volume send, use
    sent-account-readiness
    to check
    balance.get
    before preparing the mutation. Stop if the available balance or account readiness is insufficient or unclear.
  3. Build the exact
    messages.send
    arguments without calling the tool.
  4. Show a payload preview that includes the selected organization, Sender Profile, channel, exact destination, content or template identifier, variables, and scheduling/idempotency inputs. Show sensitive content once only; mask it where the operator can still verify the target.
  5. Ask for explicit confirmation for this exact payload. General approval given earlier in the conversation is not sufficient.
  6. Call
    messages.send
    immediately after that confirmation. If any payload value, scope, or elapsed context changes, discard the confirmation and preview again.
Never call
messages.send
without the preview and explicit confirmation immediately before the call.
  1. 确定目标渠道、发送者配置文件、收件人、模板或内容、变量、调度输入以及该工具支持的任何幂等字段。切勿编造缺失的值。
  2. 对于高批量发送,在准备变更操作前,使用
    sent-account-readiness
    调用
    balance.get
    检查余额。如果可用余额或账户状态不足或不明确,请停止操作。
  3. 构建精确的
    messages.send
    参数,但暂不调用该工具。
  4. 显示负载预览,包括所选组织、发送者配置文件、渠道、确切目标地址、内容或模板标识符、变量以及调度/幂等输入。敏感内容仅显示一次;在操作人员仍可验证目标的情况下,对其进行屏蔽。
  5. 请求对该精确负载进行明确确认。对话早期给出的一般性批准不足以作为依据。
  6. 确认后立即调用
    messages.send
    。如果任何负载值、权限范围或上下文发生变化,请放弃之前的确认并重新显示预览。
切勿在未先显示预览并获得明确确认的情况下调用
messages.send

Handle results and retries

处理结果与重试

  • Report the message identifier and the returned acceptance state. Say "accepted" or "queued" when that is all the response establishes; do not say "delivered."
  • Use
    messages.get
    or
    messages.activities.list
    when the user asks for subsequent delivery state.
  • Treat every retry as a new mutation: reconstruct the payload, show a fresh preview, and obtain new explicit confirmation immediately before the retry.
  • Never blindly retry an ambiguous send. If the first call times out or its outcome is unknown, inspect
    messages.get
    and
    messages.activities.list
    when an identifier exists. Without conclusive evidence, report the unknown outcome and duplication risk. Only attempt another send after the operator chooses to do so and completes a new preview and confirmation.
  • 报告消息标识符和返回的接受状态。当响应仅确认“已接受”或“已排队”时,如实说明;切勿声称“已送达”。
  • 当用户询问后续送达状态时,使用
    messages.get
    messages.activities.list
  • 将每次重试视为新的变更操作:重新构建负载、显示新的预览,并在重试前获取新的明确确认。
  • 切勿盲目重试结果不明确的发送操作。如果首次调用超时或结果未知,若存在标识符,请检查
    messages.get
    messages.activities.list
    。若无确凿证据,请报告结果未知以及重复发送的风险。仅在操作人员选择重新发送并完成新的预览和确认后,才可尝试再次发送。