From be97afb6280f3f09dde3023af7e6c6de471753f6 Mon Sep 17 00:00:00 2001 From: Kurtis Van Gent <31518063+kurtisvg@users.noreply.github.com> Date: Fri, 10 Jul 2026 15:08:19 -0600 Subject: [PATCH] feat: add 2026-05-27 weekly meeting notes (#40) --- meetings/2026-05-27_weekly.md | 98 +++++++++++++++++++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100644 meetings/2026-05-27_weekly.md diff --git a/meetings/2026-05-27_weekly.md b/meetings/2026-05-27_weekly.md new file mode 100644 index 0000000..13e31fd --- /dev/null +++ b/meetings/2026-05-27_weekly.md @@ -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)