diff --git a/meetings/2026-07-15_weekly.md b/meetings/2026-07-15_weekly.md new file mode 100644 index 0000000..8e6e07c --- /dev/null +++ b/meetings/2026-07-15_weekly.md @@ -0,0 +1,156 @@ +# 2026-07-15 MCP: Transport Working Group (Weekly) + +## TL;DR +The MCP: Transport Working Group conducted a smaller weekly meeting to review +administrative updates, discuss Gabriel Zimmerman's capabilities Specification +Enhancement Proposal (SEP), map out key design questions and use cases for +reintroducing sessions, and establish future workshop topics. While the team +aligned on prioritizing a comprehensive justification for session reintroduction +and formally evaluating the trade-offs between transport mechanisms to resolve +architectural and security concerns, they debated client-side versus server-side +filtering, state handles versus session IDs for concurrency, and the security of +localhost HTTP transport versus running HTTP/2 over standard I/O. The overall +vibe was collaborative yet cautious, with members acknowledging that a stronger, +more bulletproof case is needed before proposing sessions back to the core +maintainers. + +## Detailed Summary + +### Administrative and Meeting Scheduling +* **Attendance Updates:** The working group noted a smaller attendance for the + current session. Summer vacations and other obligations have reduced turnout. + Kurtis Van Gent noted that Katie McCaffrey appears to have completed her + contributions now that her stateless session logic is merged, though she may + return for topics of interest. Additionally, Gabriel Zimmerman shared that + Mike Kistler has retired from his role. +* **Scheduling Form Reminder:** Kurtis reminded attendees to complete the + meeting time preference form by Friday so the group can reschedule. While + three people completed it at the last minute, everyone else is urged to submit + their preferences or accept whatever time is chosen. + +### Client Capabilities and Server Filtering +* **Tool Execution Failures:** Gabriel Zimmerman raised the problem of tool + execution failures occurring when an LLM attempts to call a tool that is not + supported by the client. +* **Extensions and Capabilities Filtering:** Gabriel proposed that servers + return required extensions and capabilities so clients can filter out + unsupported tools before execution. Stephen Halter noted that this problem + also exists for tasks, referencing how the SDK previously handled "tool + execution" before it was simplified out. +* **Client-Side vs. Server-Side Filtering:** Kurtis Van Gent questioned why this + filtering cannot be handled entirely on the server side, which is the current + recommended pattern. Gabriel explained that server-side filtering is + complicated by the "cache key issue" where varying capabilities in different + client execution environments can lead to a "weird cache key" when caching + tools. +* **Caching and TTL Guidance:** Kurtis suggested that rather than introducing + complex client-side capabilities, the protocol could simply update the TTL + mechanism with clear guidance on what invalidates a cache key and forces the + client to fetch a new list of tools. Gabriel Zimmerman agreed to update his + Specification Enhancement Proposal (SEP) to represent both server-side and + client-side options and detail specific caching invalidation rules. + +### Reintroducing Stateful Sessions: Core Challenges +* **The Session ID Conflict:** Kurtis Van Gent explained that the previous + session implementation failed because the session ID was overloaded for both + transport-level bookkeeping and application state, breaking user expectations + and leading to its removal from the protocol. +* **Design Open Questions:** Kurtis presented several design challenges that + must be addressed to construct a compelling proposal for the core maintainers: +* *Naming:* "Session" is overloaded; alternatives like "thread ID", + "conversation ID", or "context ID" should be evaluated. +* *ID Generation:* Debating the pros and cons of client-generated versus + server-minted IDs. Stephen Halter strongly advocated for server-side minting, + arguing that client-generated IDs limit utility, make requests easy to forge, + and remove trusted values. +* *Lifecycle:* Clarifying how sessions are created, when they are cleaned up, + and their relation to standard I/O process lifetime. +* *Scope of Impact:* Determining whether a session can alter the tools list, + tool call outputs, resources, or prompts. +* *Concurrency:* Managing parallel requests and sub-agent behaviors (e.g., + whether sub-agents get unique IDs or reuse parent session IDs). +* *Optionality:* Deciding if sessions are strictly opt-in and how to handle + clients that do not support them. +- **State Handles vs. Session IDs:** Gabriel Zimmerman raised a concern from a + Microsoft engineer regarding the determinism of state handles (e.g., shopping + carts) and whether harnesses can guarantee they are correctly passed through + downstream workflows. Stephen Halter agreed that while higher-level state + handles are useful for shopping carts, session IDs are essential for + environments like LLM competitions where the harness must prevent cheating by + remaining in control. + +### Session Use Cases and Alternatives +- **Infrastructure Routing and Instance Affinity:** The group discussed the + necessity of routing session calls consistently to a specific microVM. +* *Option A (Client-provided Headers):* Middleware handles routing via a + client-provided header. Kurtis and Luca Chang noted the downside: there is no + standard header name, meaning arbitrary clients cannot connect to arbitrary + servers dynamically. +* *Option B (Server State Handles):* Initializing a conversation returns a state + handle used for downstream routing. Luca Chang strongly opposed this, stating + that gateways would have to rewrite upstream tools to add handle parameters, + which would conflict with servers managing explicit state handles. Stephen + Halter added that no generic session-aware gateway exists to support this. +- **Observability and Auditing:** Tracking the order and metrics of tool calls. +* *Option A (Non-MCP Tracing):* Cloud Code or other harnesses pass a + conversation ID header for tracking. +* *Option B (Resource-based Indexing):* Indexing audit logs at the resource + level itself (e.g., Cloud SQL instances). Luca Chang noted that a gateway + cannot extract telemetry automatically because it does not know the semantics + of specific tools, whereas the server can emit this natively. +* *Cookie Jar Mechanism:* Gabriel Zimmerman suggested echoing a metadata field + back and forth. Kurtis noted this was previously rejected for protocol + complexity. +- **Progressive Discovery of Tools:** Kurtis suggested that discovering tools + through skills activation (`skills:activate`) is a viable path because models + are already trained to utilize skills. Stephen Halter questioned if this would + replace or merely supplement the standard tools list. +- **Multi-step Stateful Workflows:** For workflows like counters, the group + agreed that state handles are a cleaner and more appropriate solution than + sessions. + +### Future Workshop Topics and Transport Security +- **Upcoming Topics:** Kurtis outlined a typed list of future topics: pluggable + transports (e.g., gRPC support), tool versioning, HTTP over standard I/O, + internationalization, and content type support. +- **HTTP over Standard I/O:** Andreas Schlapbach and Stephen Halter discussed + running HTTP/1.1 or HTTP/2 over local standard I/O streams to align local and + remote transport behaviors. Stephen noted that multiplexing for parallelism + would make HTTP/2 a strong choice. +- **Security Risks of HTTP Transports:** Kurtis expressed security concerns + regarding localhost HTTP, specifically DNS rebinding risks and the lack of + encryption when token verification is used. Luca Chang suggested that + applications could pass an unguessable token to the subprocess to verify + requests, but Kurtis countered that localhost HTTP remains unencrypted. The + group agreed on the critical need to define a comprehensive threat model + before evolving local transports. + +## Next Steps & Timeline +- Between now and the next meeting, Kurtis Van Gent will draft comprehensive + briefs for the future workshop topics, including pluggable transports, tool + versioning, and HTTP over standard I/O. +- All working group members are requested to fill out the meeting scheduling + preference form by Friday to help determine the next meeting time. +- Once responses are collected, Kurtis will reschedule and organize the next + meeting. +- Andreas Schlapbach will begin investigating standard I/O transport mechanisms. +- Gabriel Zimmerman will update his capabilities Specification Enhancement + Proposal (SEP) with server-side options and caching invalidation triggers. + +## Action Items +- [ ] **Gabriel Zimmerman** Update capabilities Specification Enhancement + Proposal (SEP) to include server-side options, clarify cache invalidation + rules, and address caching key/TTL feedback. +- [ ] **Luca Chang** Review Kurtis's sessions use cases draft and comment on the + PR to articulate why existing middleware routing is insufficient and document + gateway conflict concerns. +- [ ] **Kurtis Van Gent** Draft technical briefs for the upcoming workshop + topics (pluggable transports, tool versioning, internationalization, and HTTP + over standard I/O). +- [ ] **Kurtis Van Gent** Reschedule and organize the next working group meeting + based on the scheduling form results. +- [ ] **The group** Complete the meeting time preference form by Friday. +- [ ] **The group** Review the reintroducing sessions proposal and identify + potential gaps or solutions to strengthen the case for core maintainers. +- [ ] **Andreas Schlapbach** Investigate the feasibility and security + implications of standard input/output as a transport mechanism. \ No newline at end of file