Proposal: an optional input kind hint on PromptArgument (text | select | search) #3222
layibabalola
started this conversation in
Ideas - General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
The gap.
PromptArgumenttoday carries name/description/required. A client rendering a prompt-input form cannot distinguish "free text" from "pick one of a known set" from "search a large corpus" - so even a client that faithfully implementscompletion/completehas to guess whether a bare textbox, a dropdown, or a type-to-filter combobox is the right control.Concrete case. Our server (a Salesforce support-case tool) exposes prompts whose one argument is a case number. The ideal UX is a picker over the user's open cases: the server already implements
completion/completefor it, including empty-input completion that returns the full list so a dropdown could populate with zero typing. But nothing in the declaration tells a client this argument IS pickable - the completions capability says the server can answer, not what the answer's shape means for the control.Working server-side implementation (empty input = full option set, typed input narrows): https://gist.github.com/layibabalola/77616813ce7bfdd28b569c29b2e508d3
Proposal. An optional
inputhint on PromptArgument:{ "name": "caseNumber", "required": true, "input": { "kind": "search" } }"select": the client SHOULD populate a dropdown fromcompletion/completewith an empty value (the server returns the full option set)."search": the client SHOULD render a type-to-filter combobox backed by debouncedcompletion/completecalls."text"(or absent): today's behavior.Why a hint and not UI schema. The client still owns the controls; the server states only the SHAPE of the answer. Clients that ignore
inputkeep today's behavior, so it is fully backwards compatible - the same graceful-degradation posture as every other optional capability.What we shipped meanwhile (evidence the gap has real cost): our prompts now declare zero arguments and instruct the model to detect the target from the chat or list options in-chat and wait for the user's pick. It works, but it spends a model round-trip and an extra user turn to do what one dropdown could.
All reactions