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
{{ message }}
Repository navigation
mcp: URLElicitationRequiredError disagrees with Elicit and ParseURLElicitationRequiredError #1500
URLElicitationRequiredError treats an empty Mode as "form" and panics, while ServerSession.Elicit infers "url" from URL/ElicitationID (inferElicitMode). It also accepts elicitations with no URL or ElicitationID, and an empty list, so a server can build a -32042 that ParseURLElicitationRequiredError (#1495) rejects. This is the open point from #1495.
Change
Infer the mode as Elicit does and marshal the inferred copies, so the wire always carries "mode": "url".
Return a plain (non-*jsonrpc.Error) error for any input a client could not act on: an empty list, a nil elicitation, a non-URL mode, or a missing URL/ElicitationID. No panics: nothing in the SDK recovers a handler panic, so one takes the server process down, and these values are often computed at runtime. Relaxing the current non-URL-mode panic to an error breaks no caller.
Share one validation helper between the builder and ParseURLElicitationRequiredError, so the two cannot drift again.
This replaces the tests that expect a panic for an empty or "form" mode. Out of scope: Elicit itself does not check for a URL or elicitation ID in URL mode.
I'd like to send the PR for this; I have it ready.
Thanks for following up after #1495! After looking this over, we'd prefer to keep URLElicitationRequiredError as-is and close this out. -32042 (CodeURLElicitationRequired) is 2025-11-25-only and was removed in 2026-07-28 in favor of multi-round-trip InputRequiredResult, so we want to avoid changing the behavior of an existing exported helper for a deprecated protocol feature .
Changing its existing panic/return behavior would also carry compatibility (MCPGODEBUG) cost for very little practical benefit.
Activity
guglielmo-san commentedon Nov 5, 2026
Thanks for following up after #1495! After looking this over, we'd prefer to keep
URLElicitationRequiredErroras-is and close this out.-32042(CodeURLElicitationRequired) is2025-11-25-only and was removed in2026-07-28in favor of multi-round-tripInputRequiredResult, so we want to avoid changing the behavior of an existing exported helper for a deprecated protocol feature .Changing its existing panic/return behavior would also carry compatibility (
MCPGODEBUG) cost for very little practical benefit.QuentinBisson commentedon Nov 5, 2026
No worries thanks ;)