当用户要查 Sent 号码能力或汇总消息发送/送达/联系人指…

通过 Sent MCP 只读工具，在明确组织、Sender Profile、日期范围和时区后，查询号码能力及汇总的消息发送、送达、联系人指标并做同期对比。

适用场景

解决思路

1. 使用 `numbers.lookup`、`dashboard.messages_sent`、`dashboard.deliverability`、`dashboard.contacts` 执行只读分析。
2. 采用 client-managed OAuth 2.1/PKCE 建立访问上下文。
3. 绝不请求或暴露 token、API key、authorization header、client ID 或 secret。
4. 当客户端暴露时，识别当前活跃 organization 和 Sender Profile。
5. 如果请求的 scope 不同，通过客户端重新授权，而不是添加凭据或隐藏的 scope 字段。
6. 最小化敏感输出：对电话号码做掩码，尽可能聚合，省略回答问题不需要的 contact、KYC、account 和 message-body 数据。
7. 使用 `numbers.lookup` 获取所提供号码的可用 capability、格式、类型或路由信号。
8. 说明号码查询只描述 capability，不是 opt-in、consent、ownership、identity 或 permission to message 的证据；只要结果可能用于规划 outreach，就必须说明这一区别。
9. 调用 dashboard 工具前，先解析明确的 date range 和 timezone；如果用户省略任一，询问或清楚说明假设。
10. 用 `dashboard.messages_sent` 查询 sent-volume 指标。
11. 用 `dashboard.deliverability` 查询 aggregate acceptance 和 delivery outcomes。
12. 用 `dashboard.contacts` 查询 aggregate contact 指标。
13. 除用户明确要求外，比较时保持相同 organization、Sender Profile、date range、timezone、channel 和 aggregation grain。
14. 每个结果都必须说明所使用的 date range 和 timezone。
15. 按响应实际能确立的状态标注 accepted、sent、delivered、failed 和 unknown；绝不把 accepted 合并/等同于 delivered。
16. 本技能用于 dashboard totals、rates 和 trends。
17. 当请求涉及 message-level delivery records、funnel drop-off、error-code clustering 或 root-cause diagnosis 时，改用 `messaging-performance-analyzer`。
18. 记住 deliverability dashboard 只能定位变化，不能单独证明 operational cause。

适用边界 · 注意事项

• 不适用于需要 message-level 投递记录、漏斗流失、错误码聚类或根因诊断的请求（应改用 `messaging-performance-analyzer`）。
• 不适用于把号码查询结果当作 opt-in、consent、ownership、identity 或 permission to message 证据的场景。
• 不适用于无法通过 client-managed OAuth 2.1/PKCE 访问 Sent MCP 工具或必须自行提供/暴露凭据的场景。