Feature hasn't been suggested before.
Describe the enhancement you want to request
Problem
The question tool's Option only has { label, description }. This forces the LLM to either:
a) Offer a guessed default value as a concrete option (the user may not want it, and can't correct it inline), or
b) Use a dummy label like "You tell me". Selecting it passes only that text to the LLM, requiring a second question to get the actual value, or
c) Rely on the UI's "Type your own answer" (a generic catch-all, disconnected from the specific option, with a 2-step flow: click custom, textarea appears, type, submit).
Example:
User name is not configured in git. What should the user name be?
1. john_doe
2. you tell me
3. Type your own answer
If the user picks "you tell me", the LLM just gets ["you tell me"] with no actual value. The LLM then has to ask another question or guess. If the user picks "Type your own answer", they have to type everything from scratch, even though the "you tell me" option already signaled intent.
Proposed Solution
Add an optional input field to Option. When true, the UI renders that option with an inline text field: the user can type the value directly next to the option, without a separate textarea step.
Schema change:
const Option = Schema.Struct({
label: Schema.String,
description: Schema.String,
+ input: Schema.optional(Schema.Boolean).annotate({
+ description: "When true, this option renders with an inline text input for the user to type a value",
+ }),
})How the LLM would use it:
{
question: "User name is not configured in git. What should the user name be?",
options: [
{ label: "john_doe", description: "Use the default username" },
{ label: "you tell me", description: "Specify a custom username", input: true }
]
}How the UI would render it:
1) john_doe - Use the default username
2) you tell me - Specify a custom username
[________________]
How the answer reaches the LLM:
The answer would encode both the selected option and the typed input:
["you tell me: <user-typed-value>"].
This way the LLM gets both the intent ("the user picked the 'you tell me' option") and the actual value in one shot.
Key Distinction
This is NOT about replacing the existing "Type your own answer" (custom input). That catch-all should stay. This is about letting the LLM tag specific options that inherently need free-text input, so they get inline treatment, keeping the flow single-step and semantically clear.
Backward Compatibility
input defaults to false / undefined. Existing tool calls unchanged.- The UI simply checks
option.input to decide render mode.
- No breaking changes to the event/bus/API layer.
Related
Feature hasn't been suggested before.
Describe the enhancement you want to request
Problem
The
questiontool'sOptiononly has{ label, description }. This forces the LLM to either:a) Offer a guessed default value as a concrete option (the user may not want it, and can't correct it inline), or
b) Use a dummy label like
"You tell me". Selecting it passes only that text to the LLM, requiring a second question to get the actual value, orc) Rely on the UI's "Type your own answer" (a generic catch-all, disconnected from the specific option, with a 2-step flow: click custom, textarea appears, type, submit).
Example:
If the user picks "you tell me", the LLM just gets
["you tell me"]with no actual value. The LLM then has to ask another question or guess. If the user picks "Type your own answer", they have to type everything from scratch, even though the "you tell me" option already signaled intent.Proposed Solution
Add an optional
inputfield toOption. Whentrue, the UI renders that option with an inline text field: the user can type the value directly next to the option, without a separate textarea step.Schema change:
const Option = Schema.Struct({ label: Schema.String, description: Schema.String, + input: Schema.optional(Schema.Boolean).annotate({ + description: "When true, this option renders with an inline text input for the user to type a value", + }), })How the LLM would use it:
How the UI would render it:
How the answer reaches the LLM:
The answer would encode both the selected option and the typed input:
["you tell me: <user-typed-value>"].This way the LLM gets both the intent ("the user picked the 'you tell me' option") and the actual value in one shot.
Key Distinction
This is NOT about replacing the existing "Type your own answer" (custom input). That catch-all should stay. This is about letting the LLM tag specific options that inherently need free-text input, so they get inline treatment, keeping the flow single-step and semantically clear.
Backward Compatibility
inputdefaults tofalse/undefined. Existing tool calls unchanged.option.inputto decide render mode.Related
questiontool.Asking Question#8930 (closed). Requested a general comment field alongside answers. Different scope.questiontool prompt already tells the LLM "don't include 'Other' or catch-all options" because the UI adds custom automatically. This proposal gives the LLM a legitimate reason to include an input-tagged option.