experimental_registerMcpEvents covers the control methods, and the docs leave verification, signing and delivery to the application on purpose. That makes sense for network calls and durability. Two pieces of that work are pure functions that every adopter writes the same way, and both are easy to get subtly wrong:
- Callback verification. Build the signed
{"type":"verification","challenge":…}request forverifyEndpoint, then check the receiver's echo with a constant-time comparison. - Signed delivery request. Build the event envelope (
eventId,name,timestamp,data,cursor) and its headers:webhook-id,webhook-timestamp,webhook-signature(viastandardwebhooks) andX-MCP-Subscription-Id. During a secret rotation, sign with both secrets.
Both would take values and return { headers, body }, or a boolean for the echo check. They'd make no network calls, keep no state and start no timers, so they stay inside the scope the docs set.
We run the draft extension in production at Taskaid, with ChatGPT as the subscriber, and maintain these pieces ourselves today. Would you take a PR for them? If so, under which names and module, for example alongside experimental_validateMcpEventDelivery?
Activity
0No activity yet.