Add support for URL mode elicitation #1021
Conversation
halter73
force-pushed
the
halter73/750
branch
from
0debdd5 to
8ee8b5b
Compare
|
|
||
| If the user provides the requested information, the ElicitationHandler should return an <xref:ModelContextProtocol.Protocol.ElicitResult> with the action set to "accept" and the content containing the user's input. | ||
| If the user does not provide the requested information, the ElicitationHandler should return an [<xref:ModelContextProtocol.Protocol.ElicitResult> with the action set to "reject" and no content. | ||
| Elicitation is an optional feature so clients declare their support for it in their capabilities as part of the `initialize` request. Clients can support `Form` (in-band), `Url` (out-of-band), or both. |
There was a problem hiding this comment.
Optional capability? It's a little redundant as almost every capability is optional. Maybe just "Clients declare their support.." ?
There was a problem hiding this comment.
| Elicitation is an optional feature so clients declare their support for it in their capabilities as part of the `initialize` request. Clients can support `Form` (in-band), `Url` (out-of-band), or both. | |
| Clients declare their support for elicitation in their capabilities as part of the `initialize` request. Clients can support `Form` (in-band), `Url` (out-of-band), or both. |
|
Really like the example. Only downside is it might distract from the fact url mode will usually point at an url that is distinct from the mcp server. I think an ideal sample should be MCP server and separate blazor server with some communication mechanism between them. Just to show it's out of band and the security pattern of the sensitive information never passing through the mcp server. But that's something that can be done later. |
halter73
force-pushed
the
halter73/750
branch
from
31c3125 to
66a0c7e
Compare
I accidently pushed the sample. I removed it from this PR. It wasn't fully functional yet, and it didn't use auth for the Blazor form. Later we can add a sample that leverages AddOpenIdConnect and AddCookie pointing to the same OAuth provider as AddMcp, possibly in a different project to show that the URL doesn't need to be hosted by the MCP server. I don't think it's really a problem to have the MCP server host the elicitation URL though. It still serves a purpose of collecting sensitive information from the user without exposing it to the host or client. |
| { | ||
| // If ElicitationCapability is set but both modes are null, default to form mode for backward compatibility | ||
| _options.Capabilities.Elicitation.Form = new(); | ||
| } |
There was a problem hiding this comment.
Seems like this could be simplified slightly to:
_options.Capabilities.Elicitation ??= new();
if (_options.Capabilities.Elicitation.Form is null &&
_options.Capabilities.Elicitation.Url is null)
{
// If both modes are null, default to form mode for backward compatibility.
_options.Capabilities.Elicitation.Form = new();
}
|
|
||
| var capability = new ElicitationCapability(); | ||
| bool hasForm = false; | ||
| bool hasUrl = false; |
There was a problem hiding this comment.
Why do we need these bools rather than just checking whether Form/Url are set?
This PR adds support URL mode elicitation requests defined by SEP-1036 which is for out-of-band server-to-client elicitations that may involve sensitive data the MCP server doesn't want to give to the MCP client or host.
Fixes #750