From c8b275581141ba27a9cb43c1431a8e9cc9b257d4 Mon Sep 17 00:00:00 2001 From: Kurtis Van Gent <31518063+kurtisvg@users.noreply.github.com> Date: Wed, 22 Apr 2026 19:47:00 +0000 Subject: [PATCH] feat: add 2026-04-15 weekly meeting notes --- meetings/2026-04-15_weekly.md | 88 +++++++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+) create mode 100644 meetings/2026-04-15_weekly.md diff --git a/meetings/2026-04-15_weekly.md b/meetings/2026-04-15_weekly.md new file mode 100644 index 0000000..00a0a41 --- /dev/null +++ b/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. \ No newline at end of file