feat: add 2026-02-25 weekly meeting notes (#21)
This commit is contained in:
parent
61819cab19
commit
c1076f0387
1 changed files with 78 additions and 0 deletions
78
meetings/2026-02-25_weekly.md
Normal file
78
meetings/2026-02-25_weekly.md
Normal file
|
|
@ -0,0 +1,78 @@
|
|||
# 2026-02-25 Transports WG (Weekly)
|
||||
|
||||
## TL;DR
|
||||
The working group agreed to advance the Multi-Roundtrip Request (MRTR)
|
||||
Specification Enhancement Proposal (SEP) to the core contributors for initial
|
||||
feedback, despite open questions regarding SDK backward compatibility. To manage
|
||||
the SEP's complexity, the group decided to decouple a significant redesign of
|
||||
the Tasks API from the current proposal. Caitie McCaffrey will formalize the
|
||||
schema changes, which treat requests for more information as optional parameters
|
||||
to gracefully handle client mismatches. Additionally, Shaun Smith presented an
|
||||
early draft for Session management. The group discussed open design questions
|
||||
regarding server identity, Key-Value store usage, and handling servers that mix
|
||||
stateful and stateless tools, culminating in an action item for Shaun Smith to
|
||||
draft a formal SEP detailing these specific use cases.
|
||||
|
||||
## Detailed Summary
|
||||
|
||||
### MRTR SEP: Error Handling & Mismatched Inputs
|
||||
* Caitie McCaffrey submitted a PR to address error handling, proposing that
|
||||
servers treat requests for more information as optional parameters.
|
||||
* If a client returns unexpected or mismatched data (e.g., returning only one of
|
||||
two requested parameters), the server should simply ignore the unexpected data
|
||||
and re-request the missing information.
|
||||
* The group agreed this should be framed as guidance for tool developers rather
|
||||
than strict protocol-level error handling.
|
||||
* Concerns about infinite loops from clients repeatedly sending bad data should
|
||||
be handled via standard rate limiting and throttling, not at the protocol
|
||||
level.
|
||||
|
||||
### MRTR SEP: Persistent Workflow & Tasks API
|
||||
* Luca Chang and Mark Roth discussed simplifying the persistent workflow by
|
||||
combining task status, input responses, and final results into a single
|
||||
unified `tasks continue` RPC.
|
||||
* However, to prevent the MRTR SEP from becoming overly bloated, the group
|
||||
reached a consensus to decouple this larger Tasks API redesign from the
|
||||
current MRTR proposal.
|
||||
* The group will proceed with the current MRTR structures and signal to SDK
|
||||
maintainers that the Tasks API remains experimental and subject to future
|
||||
optimization.
|
||||
|
||||
### SEP Advancements & Core Contributor Review
|
||||
* Despite concerns raised by Shaun Smith and Peter Alexander regarding SDK
|
||||
backward compatibility and the lack of a live reference implementation, the
|
||||
group voted (7 approvals, 2 abstentions) to advance the MRTR SEP to the core
|
||||
maintainers to gather early feedback.
|
||||
* Caitie McCaffrey, Mark Roth, and Gabriel Zimmerman will finalize the schema
|
||||
changes by Friday to prepare for this review.
|
||||
* The separate Request-Response Association SEP was confirmed as accepted, and
|
||||
Caitie McCaffrey will proceed with merging it into the main repository.
|
||||
|
||||
### Sessions Proposal (V2)
|
||||
* Shaun Smith demonstrated a rough draft PR for session management, utilizing
|
||||
the `meta` tag for cookie data to enable features like session creation,
|
||||
resumption, and deletion.
|
||||
* Open questions remain regarding server identity, the inclusion of a Key-Value
|
||||
(KV) store within the session data, and whether to include list/recover
|
||||
operations.
|
||||
* Caitie McCaffrey raised a critical scoping concern regarding the complexity of
|
||||
mixing stateful (session-based) and stateless tools within a single MCP
|
||||
server, suggesting that servers should ideally operate entirely in one
|
||||
paradigm or the other.
|
||||
* Kurtis Van Gent tasked Shaun Smith with drafting a concrete SEP that
|
||||
explicitly compares the approach to HTTP cookies and outlines the specific use
|
||||
cases and flows for session support.
|
||||
|
||||
## Action Items
|
||||
- [ ] Caitie McCaffrey to format the error handling PR as guidance for tool
|
||||
developers rather than a strict protocol-level error handling mechanic.
|
||||
- [ ] Caitie McCaffrey, Mark Roth, and Gabriel Zimmerman to finalize and publish
|
||||
the proper set of schema changes for the MRTR SEP by Friday.
|
||||
- [ ] Caitie McCaffrey to ping Dan to confirm the merge of the Request-Response
|
||||
Association SEP.
|
||||
- [ ] Kurtis Van Gent to request time in the upcoming core contributors meeting
|
||||
for the MRTR SEP, send the relevant links, and ensure Mark Roth is added to
|
||||
the invite to discuss rationale.
|
||||
- [ ] Shaun Smith to draft a concrete SEP for Sessions that covers use cases, a
|
||||
comparison to HTTP cookies, and the flow/overlap for MCP servers mixing
|
||||
session and non-session support.
|
||||
Loading…
Reference in a new issue