You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
|[A](./optionAShimMrtrCanonical.ts)| MRTR-native only | Emulates retry loop over SSE | Yes, but safe (guard is explicit in source) | Full elicitation |
22
+
|[B](./optionBShimAwaitCanonical.ts)|`await elicit()` only | Exception → `IncompleteResult`| Yes, **unsafe** (invisible in source) | Full elicitation |
23
+
|[C](./optionCExplicitVersionBranch.ts)| One handler, `if (mrtr)` branch | Version accessor | No | Full elicitation |
24
+
|[D](./optionDDualRegistration.ts)| Two handlers | Picks by version | No | Full elicitation |
25
+
|[E](./optionEDegradeOnly.ts)| MRTR-native only | Nothing | No | Error ("requires newer client") |
26
26
27
27
"Hidden re-entry" = the handler function is invoked more than once for a single logical tool call, and the author can't tell from the source text. A is safe because MRTR-native code has the re-entry guard (`if (!prefs) return`) visible in the source even though the _loop_ is
28
28
hidden. B is unsafe because `await elicit()` looks like a suspension point but is actually a re-entry point on MRTR sessions — see the `auditLog` landmine in that file.
@@ -45,8 +45,8 @@ the dual-path burden on the tool author rather than the SDK.
45
45
All demos use `DEMO_PROTOCOL_VERSION` to simulate the negotiated version, since the real SDK doesn't surface it to handlers yet:
`IncompleteResult` is smuggled through the current `registerTool` signature as a JSON text block (same hack as #1597). A real implementation emits `JSONRPCIncompleteResultResponse` at the protocol layer — see `shims.ts:wrap()`.
0 commit comments