RFD: Session Input Options #393
Conversation
chazcb
changed the title
chazcb
force-pushed
the
chazcb/session-input-options
branch
from
59e4455 to
70166f4
Compare
|
Planning to update to:
I might split the two proposals out in the near future depending on need! |
benbrandt
left a comment
benbrandt
left a comment
There was a problem hiding this comment.
Thanks for kicking this off! A few thoughts:
- Without a breaking change, we definitely would need to make sure no inputs are required (could revisit as a v2 protocol version)
- Session Config options were purposely a bit restricted since they need to encapsulate not only what config options are available, but also their current state, since they are "live" forms so to speak, and can be updated by both the user and the agent
- I wonder if we should somehow treat new/load options more similarly to MCP elicitation #376 since we likely want some more flexibility, and this is more of an input form to be filled out once that doesn't have the same state considerations of session config
MCP elicitation takes a JSON Schema approach, but is much more restricted to limit the client burden. We need to support it anyway for MCP support + other agent needs like asking users specific questions, so I guess my thought is: if the client supports elicitation, could we use the same thing to also support requesting additional inputs from the user when starting a session?
I like the approach of keeping this as similar as possible to session config, but I also wonder if this is a different enough use case, we can actually make it more similar to elicitation instead.
Another thought: could the agent do an elicitation post new thread happening to request more configuration if needed before the user sends a prompt?
And another: are these config options something we as clients should show on every new session? Or do some of these configuration options only need to be set on first load if configuration hasn't been set yet? And the defaults carry over unless a user wants to change them?
docs/rfds/session-input-options.mdx
Outdated
| "agentCapabilities": { ... }, | ||
| "agentInfo": { ... }, | ||
| "configOptions": { | ||
| "session/new": [ |
There was a problem hiding this comment.
I wonder if we can somehow come up with a more structured way of handling this since we know which resources this affects, but maybe it is also fine to tie this to method names since those are stable enough. Just recording my indecision 😄
docs/rfds/session-input-options.mdx
Outdated
| type: "select"; | ||
| defaultValue?: string | number | boolean | null; | ||
| options: Array<{ | ||
| value: string | number | boolean | null; // Machine-readable value |
There was a problem hiding this comment.
Question: why allow for multiple value types here and not just strings?
There was a problem hiding this comment.
This is based on our internal simplified JSON schema. I didn't realize that elicitation also uses a simplified schema, so love the idea of moving to that instead.
There was a problem hiding this comment.
cool yeah I think it will allow clients and agents to reuse UI + validation logic for this stuff if we can keep it closer, and I suspect it will likely cover what we need here
docs/rfds/session-input-options.mdx
Outdated
| ```typescript | ||
| interface SelectOption extends ConfigOptionBase { | ||
| type: "select"; | ||
| defaultValue?: string | number | boolean | null; |
There was a problem hiding this comment.
Does this being optional indicate that this is a required field if no default is provided?
There was a problem hiding this comment.
No, the intention is that none of these fields are required. This defaultValue is intended to be a hint to the client about what the agent might use if the field is not filled out.
There was a problem hiding this comment.
Got it. This will be one difference from the elicitation json schema which is it will not be allowed to have "required" fields.
But I think we can learn a lot from this and potentially allow required fields later if it feels useful
docs/rfds/session-input-options.mdx
Outdated
| type: "multiselect"; | ||
| defaultValue?: Array<string | number | boolean | null>; | ||
| options: Array<{ | ||
| value: string | number | boolean | null; |
Proposal for allowing Agents to declare what input options they accept for session/new and session/load requests in InitializeResponse. This complements the existing Session Config Options RFD: - Input Options: Discovery of options for session creation/loading - Config Options: Runtime configuration during a session Key features: - JSON Schema subset for rich type definitions - Separate schemas for newSession vs loadSession - Enables dynamic client UIs for session configuration - All options are optional - Agents must provide defaults Co-Authored-By: Claude <[email protected]>
- Add `hint` for UI guidance (placeholder text, input hints) - Add `default` for declaring default values agents will use - Update examples to demonstrate usage - Add open question about whether both description and hint are needed Co-Authored-By: Claude <[email protected]>
- Change schema format from custom types to JSON Schema 2020-12 subset - Rename configOptions (schema) to configSchema in InitializeResponse - Add alternatives considered section documenting post-session elicitation - Reference MCP elicitation spec instead of duplicating schema details Co-Authored-By: Claude Opus 4.5 <[email protected]>
chazcb
force-pushed
the
chazcb/session-input-options
branch
from
3b65b61 to
147bb5a
Compare
chazcb
changed the title
- Use MCP elicitation JSON Schema format (no need to redefine) - Clarify status quo: _meta workarounds, no discovery or standard config field - Move elicitation alternatives to "Alternatives Considered" section - Streamline document to focus on init-time discovery proposal Co-Authored-By: Claude Opus 4.5 <[email protected]>
…around Co-Authored-By: Claude Opus 4.5 <[email protected]>
2 participants
Summary
Proposal for allowing Agents to declare input options they accept for
session/newandsession/loadrequests, advertised inInitializeResultcapabilities.Uses MCP elicitation's JSON Schema format for defining input schemas, providing ecosystem consistency.
Key Design Decisions
InitializeResult.capabilities.sessions, enabling clients to show configuration UI before session creationnewSessionvsloadSessionoperationsWhy not pure elicitation?
We considered using MCP elicitation directly (server requests input after
session/new), but this has UX tradeoffs:By advertising schemas at init time, clients can build configuration UIs that feel native rather than reactive.
Related