feat: add 2026-05-27 weekly meeting notes (#40)
This commit is contained in:
parent
e84ed6f35b
commit
be97afb628
1 changed files with 98 additions and 0 deletions
98
meetings/2026-05-27_weekly.md
Normal file
98
meetings/2026-05-27_weekly.md
Normal file
|
|
@ -0,0 +1,98 @@
|
|||
# **2026-05-27 MCP: Transport Working Group (Weekly)**
|
||||
|
||||
# **TL;DR**
|
||||
|
||||
The meeting achieved key technical consensus on restricting custom header
|
||||
numeric serialization and refining legacy standard IO server restart logic,
|
||||
while mapping out future specification development targets. To prevent
|
||||
serialization and comparison mismatches of floating-point numbers across
|
||||
language runtimes, the team agreed to restrict custom headers strictly to
|
||||
integer primitives. The group also resolved that clients should not proactively
|
||||
restart legacy standard IO servers to probe for protocol support, deciding
|
||||
instead to restart only if the server process crashes on the initial attempt.
|
||||
|
||||
# **Detailed Summary**
|
||||
|
||||
## **Custom Header Numeric Serialization**
|
||||
|
||||
* **Floating-Point Quirks:** Mike Kistler highlighted that JSON-to-header
|
||||
conversion of numeric values can cause mismatches due to serialization quirks
|
||||
(e.g., 42 serializing as 42.0).
|
||||
* **Consensus \- Integer Restrictions:** To avoid comparison errors with
|
||||
floating-point precision, the team agreed to restrict custom header numeric
|
||||
values strictly to primitive integers, explicitly prohibiting floating-point
|
||||
numbers.
|
||||
* **Validation Location:** It was established that clients must reject tool
|
||||
inputs containing non-integer numbers in custom headers, and the server will
|
||||
handle the verification as it unpacks the request.
|
||||
* **Tension Point \- Integer Precision Limits:** Peter Alexander pointed out
|
||||
that integers must be constrained to less than 2^53 (standard double-precision
|
||||
float representation) to prevent rounding errors in JavaScript runtimes.
|
||||
|
||||
## **Standard IO Restart Logic & Backwards Compatibility**
|
||||
|
||||
* **Tension Point \- Proactive Server Restarts:** Under the backwards
|
||||
compatibility flow for stateless standard IO, Kurtis Van Gent originally
|
||||
proposed restarting the server if the initial `serverdiscover` failed. Peter
|
||||
Alexander and Caitie McCaffrey objected to proactive restarts, noting that
|
||||
starting heavy servers twice (e.g., Playwright taking \~1 second to spawn)
|
||||
creates terrible performance optics for the new stateless protocol.
|
||||
* **Consensus \- Crash-Only Restarts:** The group agreed that clients should not
|
||||
proactively restart standard IO servers to check for compatibility. Instead,
|
||||
clients will attempt `serverdiscover`, and if the server crashes, only then
|
||||
will they restart and fallback to `initialize`.
|
||||
* **Tension Point \- Ping Before Initialize:** Shaun Smith proposed using a
|
||||
`ping` request before `initialize` to negotiate protocol versions, as the spec
|
||||
historically allowed pings before initialization. However, Kurtis Van Gent and
|
||||
Luca Chang verified that the spec mandates `initialize` as the first
|
||||
interaction, meaning some servers might crash on pre-initialization pings.
|
||||
|
||||
## **SDK Implementation Timeline & Future Roadmap**
|
||||
|
||||
* **Timeline Sign-offs:** Kurtis Van Gent outlined the official milestones: June
|
||||
28th for SDK and client maintainer sign-off, July 14th for the full spec
|
||||
freeze, July 21st for Tier 1 SDK readiness, and July 28th for the official
|
||||
spec launch.
|
||||
* **Tension Point \- Error Message Standardization:** Kurtis Van Gent proposed
|
||||
standardizing error messages and preferred HTTP status codes to prevent SDKs
|
||||
from creating proprietary interpretations. Mark Roth strongly cautioned
|
||||
against over-constraining error message text, noting that in gRPC, status
|
||||
codes are for machines and error messages are flexible text for human
|
||||
debugging.
|
||||
* **Pluggable Transports:** Mark Roth emphasized that pluggable transports are a
|
||||
high priority. Kurtis Van Gent and Mark Roth agreed to collaborate on a
|
||||
unified proposal.
|
||||
|
||||
# **Next Steps & Timeline**
|
||||
|
||||
Mike Kistler will update the numeric header restriction PR and request Peter
|
||||
Alexander's review. Kurtis Van Gent will update the standard IO process
|
||||
lifecycle PR to reflect crash-only restarts and remove host process lifetime
|
||||
parity constraints. Shaun Smith will draft outcome briefs for streaming and Gzip
|
||||
transport-level compression.
|
||||
|
||||
# **Action Items**
|
||||
|
||||
- [ ] **Mike Kistler** Modify the pull request to mandate that numeric values in
|
||||
custom headers must be integers less than 2^53.
|
||||
- [ ] **Kurtis Van Gent** Update server restart guidance in the documentation to
|
||||
specify crash-only restarts for standard IO.
|
||||
- [ ] **Caitie McCaffrey** Review the roots PR that updates the roots example to
|
||||
use prompts.
|
||||
- [ ] **Peter Alexander** Investigate how the Rust SDK handles pings before
|
||||
initialization.
|
||||
- [ ] **Shaun Smith** Locate and present documented proof regarding whether
|
||||
pings are allowed before initialization.
|
||||
- [ ] **Kurtis Van Gent** Modify the standard IO process pull request to remove
|
||||
prescriptive host application lifetime constraints.
|
||||
- [ ] **Kurtis Van Gent** Collaborate with Mark Roth on the pluggable transports
|
||||
proposal.
|
||||
- [ ] **Shaun Smith** Write high-level outcome briefs for streaming and Gzip
|
||||
compression mechanisms at the transport level.
|
||||
- [ ] **Kurtis Van Gent** Draft a problem statement regarding standardized error
|
||||
message formatting.
|
||||
- [ ] **Stephen Halter** Retrieve the deferred pull request for pluggable
|
||||
transports.
|
||||
|
||||
Source: [Meeting Notes — May 27,
|
||||
2026](https://docs.google.com/document/d/1G5E458FlLfxzoPEWwt9xo9ELCZG4zAcwaWB5HLp1Kc8/edit?usp=drive_web&tab=t.besnu9g9mrpd)
|
||||
Loading…
Reference in a new issue