diff --git a/meetings/2026-05-13_weekly.md b/meetings/2026-05-13_weekly.md
new file mode 100644
index 0000000..9569b23
--- /dev/null
+++ b/meetings/2026-05-13_weekly.md
@@ -0,0 +1,94 @@
+# **2026-05-13 MCP: Transport Working Group (Weekly)**
+
+# **TL;DR**
+
+The meeting finalized task notification semantics and introduced the Triggers
+and Events Working Group proposal. The group reached consensus on explicitly
+disallowing progress and logging notifications on tasks under the subscription
+model, choosing to table these in favor of defining a robust intermediate
+results pattern later. Peter Alexander presented the three delivery modes of the
+triggers and events primitive: polling, push stream, and web hooks. Tensions
+arose concerning web hook security, specifically DDoS amplification attacks, and
+whether cursor compatibility should be mandated between polling and web hook
+delivery to ensure reliable pub/sub delivery.
+
+# **Detailed Summary**
+
+## **Task Notification Strategy**
+
+* **Reworking Notifications:** The team discussed how progress and logging
+  notifications fit into tasks. Under the stateless SEP, normal requests use an
+  SSE stream for notifications, which is incompatible with task polling.  
+* **Tension Point \- Fragmented Notifications:** The group debated three
+  options: subscribing to all task notifications in `subscriptionslist`
+  (disjointed from base spec), opening an SSE stream on `tasks.get` (fragmented
+  and complex for polling), or disallowing progress/logging on tasks
+  temporarily.  
+* **Consensus \- Temporary Disallowance:** The group agreed to Solution 3, which
+  explicitly disallows SSE streams on tasks, supporting only the
+  `subscriptionslist` for task status updates.  
+* **Tension Point \- Progress vs Intermediary Results:** Shaun Smith advocated
+  for progress notifications as a major UX improvement. Caitie McCaffrey and
+  Peter Alexander argued that progress is too simple and what users actually
+  want is intermediate results with steering input (e.g., telling a task to
+  change a generated color).
+
+## **Triggers and Events Primitive**
+
+* **Events Primitive Introduction:** Peter Alexander introduced a new events
+  primitive (`events.list`) for low-rate server-side events (e.g., Discord
+  messages, build alerts), excluding high-throughput or multimedia streams.  
+* **Three Delivery Modes:** The proposal supports polling (clients pull at
+  intervals), push streams (single SSE connection per subscription), and web
+  hooks (soft TTL-based subscription where the server posts to the client).  
+* **Tension Point \- Cursors and Reliability:** Caitie McCaffrey noted that
+  implementing cursors for replay makes this more like pub/sub than best-effort
+  notifications. Cursors are generated by the server and passed by the client to
+  resume streams.
+
+## **Web Hook Architecture & Security**
+
+* **Two-Hop Architecture:** Shaun Smith noted that web hooks require an open
+  HTTP point on both the MCP server and the host client, creating an extra hop.
+  Peter Alexander defended this, stating it provides a constrained, filtered API
+  for hosts.  
+* **Tension Point \- DDoS and Handshake Security:** Kurtis Van Gent raised
+  concerns that malicious actors could register fake web hook endpoints to
+  orchestrate amplification DDoS attacks. The team agreed on adding an endpoint
+  verification challenge-response step and client-generated HMAC signing
+  secrets.  
+* **Tension Point \- Web Hook Cursors:** Kurtis Van Gent questioned the
+  necessity of cursors for web hooks, arguing that standard web hooks start from
+  the subscription moment. Caitie McCaffrey and Clare Liguori noted that
+  combining web hooks as a "wake up" signal with background polling is a common,
+  reliable pattern.  
+* **Tension Point \- Mandating Cursor Compatibility:** Kurtis Van Gent expressed
+  concerns about not mandating cursor compatibility if both polling and web
+  hooks are supported, as arbitrary clients and servers must align.
+
+# **Next Steps & Timeline**
+
+Core maintainers will move forward with task notification specifications without
+progress/logging. Peter Alexander will update the triggers and events proposal
+with details on transport rationale and handshake verification, while Caitie
+McCaffrey will follow up on official task acceptance votes.
+
+# **Action Items**
+
+- [ ] Caitie McCaffrey Follow up on the official acceptance status of tasks and
+  check the necessity of a voting process.  
+- [ ] Caitie McCaffrey Investigate real-world progress notification use cases
+  and compare them against Shaun Smith's examples.  
+- [ ] Peter Alexander Update the events proposal document to clarify the
+  coexistence rationale for pull, push, and web hook modes.  
+- [ ] Peter Alexander Add endpoint verification steps and security measures to
+  the web hook specification to prevent DDoS attacks.  
+- [ ] Shaun Smith Analyze the complexities of many-to-many relationships between
+  servers, hosts, and multiple web hooks.  
+- [ ] Clare Liguori Develop and test client-side architectures showing protocol
+  implementation based on these definitions.  
+- [ ] All Participants Conduct larger system demos with external event sources
+  (Discord, Telegram) to evaluate production readiness.
+
+Source: [Meeting Notes — May 13,
+2026](https://docs.google.com/document/d/1KFwTal-yFzfszl6VOsCjNLu7L6joNLbipBversMrM6Q/edit?usp=meet_tnfm_email)