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.

9.5 KiB Raw Permalink Blame History