MCP Events
MCP协议的扩展草案，引入服务器主动向客户端推送事件的能力，将交互模式从单向请求-响应扩展为双向订阅推送，适用于监控告警、数据更新、任务完成回调等场景
时间轴 (近 90 天)
使用 MCP Events 时应先从一个明确的单点场景开始跑通签名校验和任务模板，再逐步扩展触发源，并监控 30 次/小时的额度以防耗尽。
MCP Events 官方规定每小时最多触发 30 次任务运行。
MCP Events 要求对回调请求进行签名校验：开发者用密钥对原始请求体计算签名，并与请求头中的签名比对，校验失败必须直接拒绝。
签名计算必须基于原始请求体而非解析后再序列化的内容，否则字节级差异会导致校验失败；密钥应通过环境变量注入而非硬编码。
由于 MCP Events 每小时仅允许 30 次触发，其定位是低频、高价值的自动化节点，而非高吞吐的批量处理管道。
对高频事件场景，应通过聚合设计或前置过滤来减少触发次数，把 30 次额度留给真正需要模型判断的事件。
Vercel Connect 正式进入 MCP Events 公开测试阶段，允许开发者让应用和 Agent 订阅来自兼容 MCP 服务器的 webhook 事件。
ChatGPT 正在添加对 MCP Events 的草案支持，允许 MCP 服务器主动向客户端推送事件
文章提出的核心观点是：订阅本质上就是一张凭证，因为它授予了外部系统在未来主动触达用户会话的持续权限
订阅作为持续有效的授权应被当作凭证管理，需要有明确的持有者、有效范围、生命周期以及可被撤销的机制
还有 2 条时间轴事件
全部知识事实 (10)
使用 MCP Events 时应先从一个明确的单点场景开始跑通签名校验和任务模板，再逐步扩展触发源，并监控 30 次/小时的额度以防耗尽。
50%待验证MCP Events 要求对回调请求进行签名校验：开发者用密钥对原始请求体计算签名，并与请求头中的签名比对，校验失败必须直接拒绝。
50%待验证签名计算必须基于原始请求体而非解析后再序列化的内容，否则字节级差异会导致校验失败；密钥应通过环境变量注入而非硬编码。
50%待验证由于 MCP Events 每小时仅允许 30 次触发，其定位是低频、高价值的自动化节点，而非高吞吐的批量处理管道。
50%待验证对高频事件场景，应通过聚合设计或前置过滤来减少触发次数，把 30 次额度留给真正需要模型判断的事件。
50%待验证MCP Events 官方规定每小时最多触发 30 次任务运行。
50%待验证文章提出的核心观点是：订阅本质上就是一张凭证，因为它授予了外部系统在未来主动触达用户会话的持续权限
50%待验证订阅作为持续有效的授权应被当作凭证管理，需要有明确的持有者、有效范围、生命周期以及可被撤销的机制
50%待验证业界常见的凭证撤销应对方案是「短窗口 + 强校验」：令牌有效期设得极短，同时在每次推送前向权威状态源实时查询订阅有效性
50%待验证ChatGPT 正在添加对 MCP Events 的草案支持，允许 MCP 服务器主动向客户端推送事件
50%