feat: add 2026-04-15 weekly meeting notes

meetings/2026-04-15_weekly.md

@@ -0,0 +1,88 @@
+# 2026-04-15 MCP: Transport Working Group (Weekly)
+
+## TL;DR
+The meeting focused on triaging open SEPs against a newly extended mid-May merge
+deadline, characterized by a highly analytical and slightly pressured vibe as
+the team wrestled with stateless protocol design compromises. Productive
+friction centered on whether intermediate gateways or end-client LLMs should
+dictate the caching and filtering mechanics of protocol capabilities
+(specifically `tools.list`). Ultimately, complex global capability scoping was
+tabled in favor of finalizing the simplified Tasks SEP (2557), though
+significant technical debate remains regarding the removal of ephemeral
+cancellation and the validity of retaining the stateful `list.tasks` capability.
+
+## Detailed Summary
+
+### SEP Logistics and Prioritization
+*   **Merge Window Extension:** The deadline for merging pending SEPs has been
+    extended by two weeks to mid-May, though the team agreed to maintain urgency
+    to finalize approvals.
+*   **Focus Areas:** Immediate priority is on finalizing the new stateless PR
+    (SEP 2575 / redux of 1442) and incorporating Plugable Transport updates.
+
+### Global Capability Scope & Stateless Tool Filtering
+Gabriel Zimmerman presented a proposal addressing how capabilities (e.g.,
+elicitation, sampling) should be handled across independent calls in a stateless
+environment.
+*   **The Problem:** If a client doesn't declare an "elicitation" capability on
+    a `tools.list` call, the server doesn't know whether to filter out tools
+    that require elicitation for subsequent `tools.call` requests.
+*   **Tension Point - Caching vs. Filtering:** Kurtis Van Gent highlighted that
+    allowing servers to dynamically filter `tools.list` based on changing
+    capabilities or authorization (OAuth) breaks client caching predictability.
+    If the protocol doesn't define strict cache invalidation criteria, clients
+    won't know when to refresh their tool lists.
+*   **Tension Point - Gateways vs. Direct LLM Clients:** Geoff Goodman advocated
+    for an unauthenticated, exhaustive `tools.list` to serve intermediaries like
+    enterprise gateways and registries for policy enforcement. Shaun Smith
+    strongly disagreed, arguing that designing protocol features around legacy
+    gateway constraints actively harms dynamic LLM integration, noting that MCP
+    servers can theoretically generate an infinite set of dynamic tools. 
+*   **Trade-off:** Shifting filtering to the client side ensures exhaustive
+    lists for gateways but forces LLMs to handle errors gracefully if they
+    select a tool they lack the capabilities to execute. 
+*   **Consensus:** While standardizing global capability scopes is conceptually
+    important, it is not urgent enough to block the current release cycle. The
+    group agreed to table the proposal, citing that users currently rely on
+    acceptable workarounds (like manual tool blacklisting).
+
+### Tasks SEP (2557) & Protocol Simplification
+Luca Chang walked through SEP 2557, which simplifies task continuity by
+collapsing the polling lifecycle entirely into `tasks.get` (removing
+`tasks.result`) and supporting push-based SSE streams.
+*   **Tension Point - Cancellation Semantics:** With the shift to statelessness,
+    the group debated what "cancellation" actually guarantees for long-running,
+    state-mutating operations. Because cancellation notifications cannot
+    guarantee delivery or rollback, its application to ephemeral workflows (like
+    MRTR/standard IO) is flawed.
+*   **Consensus:** The specification must explicitly document that cancellation
+    is strictly "best-effort." Furthermore, the group agreed to explore
+    restricting cancellation *exclusively* to explicit Tasks, removing it
+    entirely from standard, ephemeral JSON-RPC requests to maintain internal
+    protocol consistency.
+*   **Tension Point - The Fate of `list.tasks`:** Luca argued for retaining
+    `list.tasks` (filtered by an auth context/identity) to allow server-hosting
+    runtimes to cleanly drain pending tasks before spinning down. Kurtis and
+    Caitie pushed back heavily, arguing that this introduces stateful behavior
+    (resembling removed "sessions") into a stateless protocol, and asserted that
+    tracking pending operations is the responsibility of the agent loop/host
+    framework, not the core MCP protocol.
+*   **Escalation:** The necessity of `list.tasks` is unresolved. The burden of
+    proof was shifted to Luca to explicitly justify its inclusion via a formal
+    decision document.
+
+## Next Steps & Timeline
+Between now and the mid-May merge deadline, the core maintainers will focus on
+finalizing SEP 2575 and the Tasks SEP (2557). Team members are expected to leave
+asynchronous feedback on the open pull requests, specifically targeting the
+revised cancellation semantics. Luca will author a separate defense for the
+`list.tasks` capability to determine if it survives the 6.30 release.
+
+## Action Items
+- [ ] **Kurtis Van Gent** Draft a small PR implementing the pluggable transport
+  feature.
+- [ ] **All Participants** Leave async feedback on the PR regarding the proposed
+  restriction of cancellation functionality purely to tasks.
+- [ ] **Luca Chang** Write a formal decision document explicitly outlining the
+  pros, cons, and necessary use cases for retaining `list.tasks` in the
+  protocol.