RFD: Add Elicitation specification for structured user input #376
Conversation
yordis
changed the title
|
Hey! Thanks for contributing, is it true, that we can handle things like that https://github.com/orgs/agentclientprotocol/discussions/371 with this feature? |
|
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
|
@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. |
|
@benbrandt I think that we have to work on that in the next wave |
|
@ignatov tomorrow I am back home so I can continue the work, I got distracted by trying to actually make a Zed GUI that allow us to do OpenCode-style of questionnaire as a PoC. Let me know whatever you would like to see happening, I am available in 24hrs |
benbrandt
left a comment
benbrandt
left a comment
There was a problem hiding this comment.
OK left some notes.
I would also appreciate to have the RFD merged separately from the Rust changes. as some of the things you have added would fit better within the SDK (this crate should be mostly limited to schema types)
So before we can merge this, I would want these separated to focus the review and also save you a bunch of extra work
That will happen for sure! Please ignore for now, 🙏🏻 I will revert the code tomorrow when I wake up and move it to another branch for my own sake. |
yordis
force-pushed
the
yordis/elicitation-rfc
branch
from
01c9114 to
5216630
Compare
Signed-off-by: Yordis Prieto <yordis.prieto@gmail.com>
yordis
force-pushed
the
yordis/elicitation-rfc
branch
from
5216630 to
275bba2
Compare
…ient capabilities
…arify structured input modes
…design principles
…n mechanisms for clarity and security
… and cancellation logic
… for agent workflows
…fy optionality of fields
… response handling
Elicitation is a request/response pattern - agents send requests when they need information and control their own flow. Removed stopReason and turn lifecycle dependencies.
…irements and message flow diagrams
|
@benbrandt to what extent I should simplify the RFD and simply point to MCP spec? Otherwise, I am getting lost in term of making sure I added all the semantic correctly. And I can't see what exactly is just an addon from ACP perspective. Any thoughts on the topic? |
|
|
||
| 2. **Support two elicitation modes** (following [MCP SEP-1036](https://modelcontextprotocol.io/community/seps/1036-url-mode-elicitation-for-secure-out-of-band-intera)): | ||
| - **Form mode** (in-band): Structured data collection via JSON Schema forms | ||
| - **URL mode** (out-of-band): Browser-based flows for sensitive operations like OAuth (addressing PR #330 authentication pain points) |
There was a problem hiding this comment.
I have a question about this. Currently, elicitation is part of a session, but some agents may not allow a session to start until authentication happens. @benbrandt briefly touched on this during #330. So I am wondering if this would be suitable for OAuth.
My second concern is that some clients implements OAuth "weirdly". IIRC, Codex uses a local server, GitHub Copilot uses device OAuth which requires a code to be passed around.
Those differences make sense once you consider the use cases: agents are running locally (hence the device OAuth), MCPs often require talking to an external service. Agents require auth to start, MCPs can ask for authentication only when first invoked.
All that said, I am not against this proposal. In fact, I am quite in favor! But I do wonder if this will effectively address the OAuth concerns. In cases it is indeed unclear, we could start only with the form mode.
There was a problem hiding this comment.
@josevalim I think we need to distinguish between:
-
Agent Authentication (what you're describing):
- User authenticates TO the agent itself before session starts
- Pre-session auth flow
- Different patterns: device OAuth (Copilot), local server (Codex)
- Blocking: session cannot start until complete
-
Resource Authentication (what this RFD addresses):
- Agent requests access to third-party resources DURING session
- In-session auth flow
- Example: "I need GitHub access to read your repos"
- Non-blocking: session already running, agent needs additional capability
At least that is how I understand it. I would expect the session to exist by the time you get to this one.
There was a problem hiding this comment.
That answers it, thank you!
5 participants
Signed-off-by: Yordis Prieto yordis.prieto@gmail.com