RFD: Add Elicitation specification for structured user input #376
Conversation
Signed-off-by: Yordis Prieto <yordis.prieto@gmail.com>
yordis
changed the title
Apply fixes from code review and GitHub research: - Fix client capabilities to use ClientCapabilities pattern (like fs, terminal) - Add complete turn response example showing elicitation + content integration - Define single-elicitation-per-turn design decision for v1 - Clarify URL-mode OAuth is ACP-specific, not fully MCP-aligned - Expand validation behavior FAQ with client/server responsibility split These changes align with existing protocol patterns and clarify architectural decisions identified in code review.
Add comprehensive elicitation system allowing agents to request structured user input during conversation turns. Includes: - ElicitationRequest: Request types (text, number, select, multiselect, boolean, password, URL) - ElicitationSchema: JSON Schema constraints for validation - ElicitationOption: Choices for select/multiselect types - ElicitationResponse: User responses with convenient builder methods - ElicitationCapability: Client capability negotiation - StopReason.ElicitationRequested: Stop reason for elicitation requests - Integration with PromptResponse and PromptRequest All types support serialization, JSON Schema generation, and include comprehensive tests. Feature-gated under unstable_elicitation flag.
Add 14 new tests covering: - Schema constraints (min/max values, enum values) - URL mode with OAuth return formats - Metadata handling for options and responses - All ElicitationType variants serialization - Multiselect array responses - Optional field serialization behavior - Custom capability configurations Total test count: 37 (13 new elicitation tests)
|
Hey! Thanks for contributing, is it true, that we can handle things like that https://github.com/orgs/agentclientprotocol/discussions/371 with this feature? |
Add StreamMessage, StreamMessageDirection, and StreamMessageContent types for monitoring and debugging RPC message flow. These types enable implementations to observe incoming/outgoing requests, responses, and notifications. Includes: - StreamMessageDirection enum (Incoming/Outgoing) - StreamMessageContent enum (Request/Response/Notification variants) - StreamMessage struct wrapping content and direction - StreamSender/StreamReceiver type aliases using async-broadcast - Helper constructors (::incoming(), ::outgoing()) - 5 comprehensive tests for serialization and variants Also adds async-broadcast v0.7 dependency for async multi-consumer broadcast channel support.
|
Just for some context, OpenCodes question tool schema: |
|
Hey @ignatov these type of spec should allow for that type of "question" form to happen. In fact, my existing ACP needs is all about such feature. I am trying to write the spec AND figure out if I can make Zed GUI to implement it. Overall, the intent is to allow structure input from the user such as Questionnaire, or buttons for specific auctions (at least that is my immediate need). |
benbrandt
left a comment
benbrandt
left a comment
There was a problem hiding this comment.
We definitely need something like this, and adopting the same pattern as MCP also allows us to forward MCP elicitation requests which is nice
docs/rfds/elicitation.mdx
Outdated
|
|
||
| ```json | ||
| { | ||
| "method": "session/turn", |
There was a problem hiding this comment.
Is this a new method? Or what are you referring to here? I think it would make sense to potentially model this after how we do permission requests (there is an eliciation method with request/response pattern)
and then I think we need someway to associate this with content in the thread (maybe the client just puts it in there once it receives such a request)
…like permissions Changed elicitation from embedded in session/prompt flow to a separate request/response method pattern matching permissions design. This provides clearer protocol semantics and consistent handling of structured user input requests. PROTOCOL CHANGES: - Moved from PromptRequest.elicitation_response to RequestElicitationRequest - Moved from PromptResponse.elicitation to RequestElicitationResponse - New method: session/elicitation (separate like session/request_permission) API CHANGES: - Removed elicitation_response field from PromptRequest - Removed elicitation field from PromptResponse - Added RequestElicitationRequest wrapper struct - Added RequestElicitationResponse wrapper struct - Added SESSION_ELICITATION_METHOD_NAME constant This aligns with @benbrandt feedback on consistency with permission request/response pattern.
|
@benbrandt is it OK to ask to ignore the Rust changes for now, I know it could be annoying, but I am trying to make Zed to work to see the full picture, I just realized that I committed those changes as well while trying to fix the request/response situation. Since I am in such active development, and I want to see Zed working, the burden is on you to ignore those files and only focus on the markdown until we are ready to merge. Otherwise, totally cool, I create another branch for myself, just make it a bit more difficult since it requires to switch between them and synchronize a bit more. |
Updated RFD to document the refactored architecture where elicitation uses a separate session/elicitation request/response method (matching permissions pattern) instead of being embedded in session/prompt flow. KEY CHANGES: - Clarified that elicitation is triggered by stopReason: "elicitation_requested" - Updated flow to show separate session/elicitation method call - Aligned with permission request/response pattern for consistency - Added complete JSON-RPC examples with method names and full message structure This addresses @benbrandt's feedback about consistency between permission and elicitation request/response mechanisms.
4 participants
Signed-off-by: Yordis Prieto yordis.prieto@gmail.com