sent-messaging

发送消息

使用 messages.send、messages.get 和 messages.activities.list 操作直接消息工作流。

建立连接并确认范围

1. 让 MCP 客户端执行 OAuth 2.1/PKCE 授权。绝不要请求、接受、打印或存储令牌、API 密钥、授权标头、客户端 ID 或机密。
2. 执行变更前，显示当前连接所选的组织和 Sender Profile。如果客户端上下文未同时提供两者，则使用 sent-account-readiness 检查已授权范围后再继续。
3. 如果组织授权支持显式指定操作身份，请使用经过验证的操作身份。
4. 尽量减少敏感信息输出。在可行时遮蔽电话号码；操作人员查看消息正文后，不要再次复述。

如果不支持 MCP 或授权失败，仍应让此技能可用于规划请求载荷。说明执行操作需要兼容的客户端或重新授权；绝不要要求用户粘贴凭据。

组织授权可以通过工具架构中的可选 profileId 选择自有 Sender Profile；省略该字段时，将以已认证账户身份操作。使用 sender_profiles.list 或 sender_profiles.get 验证所有权，并在预检读取、变更和后续读取中使用相同的选择器。Profile 授权不能使用此选择器。若要切换到其他组织或授权范围之外的 Profile，请重新授权。绝不要臆造范围字段或索取凭据。

检查消息

• 已知消息标识符时，使用 messages.get 获取当前记录。
• 使用 messages.activities.list 获取生命周期事件和投递证据。
• 说明发送已接受或已排队并不能证明已投递。只有返回状态或活动能证实已投递时，才报告为已投递。
• 返回回答问题所需的标识符、时间戳和状态证据；遮蔽收件人数据，除非确有必要，否则省略消息正文。

对于涉及大量投递记录的汇总趋势、漏斗或根因分析，转交给 messaging-performance-analyzer。

准备发送

1. 确定目标渠道、Sender Profile、收件人、现有模板、变量、scheduledAt 和 idempotencyKey。发送仅支持模板：先在相同的操作范围内使用 templates.list 或 templates.get，在 template 中引用其真实 ID 或名称，并在 template.parameters 中提供所有已声明变量。绝不要将消息文本作为模板名称传入，也不要臆造自由文本参数。不要臆造缺失值。
2. 对于高量发送，在准备变更前使用 sent-account-readiness 检查 balance.get。如果可用余额或账户就绪状态不足或不明确，则停止操作。
3. 构建完整的 messages.send 参数，但不要调用工具。
4. 显示请求载荷预览，其中包含所选组织、Sender Profile、渠道、确切的目标地址、现有模板标识符及其已审核内容、变量，以及排期和幂等性输入。敏感内容仅显示一次；在操作人员仍能确认目标的前提下对其进行遮蔽。
5. 针对此确切的请求载荷征求明确确认。对话中更早给出的概括性同意不够。
6. 确认后立即调用 messages.send。如果任何请求载荷值、范围或上下文时效发生变化，请作废此次确认并重新显示预览。

绝不要在调用前未立即显示预览并取得明确确认的情况下调用 messages.send。

安排发送

scheduledAt 是可选的。将用户提供的日期、时间和时区解析为带有明确 UTC 偏移量或 Z 的 ISO-8601 时间戳；不带偏移量的时间戳会被拒绝。执行时，发送时间必须在未来 1 分钟至 30 天内。在预览中注明确切的本地时间和 UTC 时间，并在调用前重新验证时间范围。

接受后会返回 QUEUED 和 scheduledAt；随后消息会变为 SCHEDULED，可通过 messages.get 查看，并会在请求时间前后几分钟内发送。收件人的免打扰时段可能会使发送推迟到下一个允许的时间，该时间会通过 message.scheduled 报告。不要承诺精确的送达时间。账户的定时发送限制可能会导致发送被拒绝。没有 MCP 改期或取消工具；不要虚构此类工具。

对于架构支持的幂等性，请使用驼峰形式的 idempotencyKey；相同的键可在 24 小时内重放缓存的发送结果。恢复同一操作时，请保留原始键和参数。另一个不同的发送意图需要使用自己的键。幂等性不能替代审核和确认。

处理结果和重试

• 报告消息标识符和返回的接受状态。如果响应仅能确认已接受或已排队，就说“已接受”或“已排队”；不要说“已送达”。
• 用户询问后续送达状态时，使用 messages.get 或 messages.activities.list。
• 将每次重试都视为新的变更：重新构建载荷、展示新的预览，并在重试前立即获取新的明确确认。
• 绝不要盲目重试结果不明确的发送。如果首次调用超时或结果未知，且存在标识符，则检查 messages.get 和 messages.activities.list。如果没有确凿证据，请报告结果未知及重复发送风险。只有在操作人员选择重试并完成新的预览和确认后，才能再次尝试发送。