Skip to content

Conversation

@benbrandt
Copy link
Member

Proposing the ability to add Agent provided configuration options to a session.

This makes the current pattern used by session modes more flexible, rather than adding additional hard-coded selectors to the protocol.

@benbrandt benbrandt requested a review from a team as a code owner October 29, 2025 13:33
@phil65
Copy link

phil65 commented Oct 29, 2025

Just some thaught here: MCP's elicitation feature uses a restricted subset of JSON Schema when it comes to asking information from the user via client. Would it make sense to align to that?

@benbrandt
Copy link
Member Author

@phil65 it's a good point. The enum type here could work: https://modelcontextprotocol.io/specification/draft/client/elicitation#supported-schema-types
I don't love double lists for values + display names but we could consolidate types here.

It wouldn't be exactly the same as it wouldn't follow the larger request/response lifecycle of an elicitation, but we could at least align on the schemas. I'll take a look before this moves from Draft to Preview for sure

@benbrandt
Copy link
Member Author

There is also the interesting distinction here in that we want to enforce a default value, in fact it is required, and we want to also send form state each time, which makes it harder to represent as a schema.

But we could pull out the form state to a separate struct on the side, so you get a schema + current values

@phil65
Copy link

phil65 commented Oct 30, 2025

Yes agreed, perhaps its not a 100% fit for this mechanism, but (slightly offtopic), I think some equivalent to MCP elicitation would be a nice feature for ACP (could potentially even replace the Permission-Request mechanism, which basically is like elicitation, but limited to 4 buttons?)

@benbrandt
Copy link
Member Author

Yep agreed this needs some work, and definitely fits with the use case

Copy link
Contributor

@agu-z agu-z left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excited for this! 🎉

}
}
}
```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could simplify the Client-side implementation by only including the config options state in this notification, and not in the session/set_config_option. The rationale being that the Client is gonna have to handle the notification anyway for changes originating from the Agent, so we could have just have one source of these.

Let me know if you disagree, though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you're suggesting, if I set an value, I just get a null back and rely on the agent sending an update if other values have changed as a result?

Proposing the ability to add Agent provided configuration options to a session.

This makes the current pattern used by session modes more flexible, rather than adding additional hard-coded selectors to the protocol.
@benbrandt benbrandt force-pushed the rfd-config-selector branch from 5877e70 to c036e08 Compare November 3, 2025 16:41
@benbrandt
Copy link
Member Author

Thanks for the feedback everyone! I incorporated it and am going to merge in Draft state. Will get it ready for Preview soon

@benbrandt benbrandt enabled auto-merge (squash) November 3, 2025 16:42
@benbrandt benbrandt merged commit 2f40371 into main Nov 3, 2025
1 check passed
@benbrandt benbrandt deleted the rfd-config-selector branch November 3, 2025 16:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants