Use case
We run an MCP gateway (Arcade) on v1.7.0-pre.2 that brokers tool auth via url-mode elicitation: the server sends elicitation/create with a URL, the user completes an OAuth flow in the browser, and an out-of-band callback on our side learns the flow finished. At that point we need to send notifications/elicitation/complete to the client — and there is no exported API to do it.
Current behavior
- The client side is fully wired:
ClientOptions.ElicitationCompleteHandler (client.go), and the internal urlElicitationMiddleware registers a waiter keyed on ElicitationID and blocks until the completion notification arrives.
- The wire types exist but the sending side is sealed:
ElicitationCompleteParams is exported, but the method constant notificationElicitationComplete is unexported, the generic sender handleNotify (shared.go) is unexported, and ServerSession's only exported notification helper is NotifyProgress.
So a server that hands url-mode elicitation to an out-of-band channel can start the flow but can never finish it: the client waits until its context dies.
Why middleware isn't a workaround
Receiving middleware operates on inbound requests; it cannot emit an arbitrary server→client notification. There is no raw JSON-RPC escape hatch exported either.
Proposal
// NotifyElicitationComplete signals that an out-of-band (url-mode)
// elicitation identified by params.ElicitationID has completed.
func (ss *ServerSession) NotifyElicitationComplete(ctx context.Context, params *ElicitationCompleteParams) error
Mirrors the existing NotifyProgress shape; no new concepts. Happy to PR this if the direction is acceptable.
🐕 Written by Kyoto, an AI agent, on Pascal's behalf —
Use case
We run an MCP gateway (Arcade) on
v1.7.0-pre.2that brokers tool auth via url-mode elicitation: the server sendselicitation/createwith a URL, the user completes an OAuth flow in the browser, and an out-of-band callback on our side learns the flow finished. At that point we need to sendnotifications/elicitation/completeto the client — and there is no exported API to do it.Current behavior
ClientOptions.ElicitationCompleteHandler(client.go), and the internalurlElicitationMiddlewareregisters a waiter keyed onElicitationIDand blocks until the completion notification arrives.ElicitationCompleteParamsis exported, but the method constantnotificationElicitationCompleteis unexported, the generic senderhandleNotify(shared.go) is unexported, andServerSession's only exported notification helper isNotifyProgress.So a server that hands url-mode elicitation to an out-of-band channel can start the flow but can never finish it: the client waits until its context dies.
Why middleware isn't a workaround
Receiving middleware operates on inbound requests; it cannot emit an arbitrary server→client notification. There is no raw JSON-RPC escape hatch exported either.
Proposal
Mirrors the existing
NotifyProgressshape; no new concepts. Happy to PR this if the direction is acceptable.🐕 Written by Kyoto, an AI agent, on Pascal's behalf —