SEP-1034: elicitation default values.

[findleyr]

Our elicitation schemas are intentionally decoupled from their JSON-RPC implementation. However, when validating the schema, we should apply defaults.

Unlike tool handling, I'm not sure we should inject these defaults into the Content map.

This implements SEP-1034.

[findleyr]

If someone wanted to help move this along this week, here are TODOs:

• Investigate how other SDKs treat this.
• Use jsonschema.Resolved.ApplyDefaults when validating the schema
• Add tests.

[markus-kusano]

Open question: Do we need to handle elicitation defaults on the server side, or just on the client, or both? I think we need to just do it in 1 location (either on the client or the server). But! If we are expected to talk to clients/server that are not using the Go SDK then we might want to make sure to use the defaults in both, rather than assuming we are talking to a Go MCP SDK client and server

Why? Elicitation requests are a request for input from the server to the client. The schema on the elicitation request from the server to the client contains the expected format of the response, as well as the defaults. If the client chooses to not include anything in the response for fields with defaults then the default value should be used. The default can be applied eon the client side (before sending the response back), or on the server side (before the values are used).

The TL;DR flow for this is:

1. Server sends elicitation request with schema with optional defaults
2. Client decides how to respond to the request, potentially not including values for some parts of the schema
3. [Option A] The client sets the fields in the response to their default value, sends the response back to the server
4. [Option B] The server sets fields on the response to their default value after getting the response

We only need one of [Option A] or [Option B] since they are redundant. OTOH, we might want to harden the server to also use the defaults, e.g., this would make the system work if we are talking to a client that is not using the Go implementation

[findleyr]

@markus-kusano I'm hesitant to do it on the server side on the basis of typescript not doing this, and preserving information: the handler should see exactly which information the client submitted.

A middle ground might be to simply apply defaults on the server side before validation. That way, if the default is "6", with min=4 and max=8, and the client doesn't submit the field, the content is still considered valid. WDYT?

[findleyr]

BTW, I actually noticed that we weren't doing any validation server side, and wondered if this is just the practice. It's not: the typescript SDK validates on both caller and callee.

I filed #648. Fixing this for eliciation will be one half of that.