ask-user-rich
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ASK_USER_RICH_HOST | No | Bind address. | 127.0.0.1 |
| ASK_USER_RICH_NODE | No | Path to a specific Node.js executable to use when running via run.sh. | |
| ASK_USER_RICH_OPEN | No | Set to "0" to disable opening a browser, so the tool returns the link at once. | on |
| ASK_USER_RICH_PORT | No | Fixed port for the form server. Defaults to 0 for a random free port. | 0 |
| ASK_USER_RICH_LOG_DIR | No | Log and answer archive location. | logs/ in the package directory |
| ASK_USER_RICH_OPEN_CMD | No | Command run with the URL as its only argument. | platform opener |
| ASK_USER_RICH_PROGRESS_MS | No | Progress notification interval in milliseconds. | 15000 |
| ASK_USER_RICH_PUBLIC_HOST | No | Hostname used in the URL. | localhost |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ask_user_richA | Ask the user any number of questions at once in a rich browser form and wait for their answers. Use it instead of AskUserQuestion for grilling rounds, design reviews and any decision set with more than 4 questions or 4 options, long headers, markdown context, code/layout previews, or recommendations you want to argue for. Each question has an id, a header, a markdown body, options (id, label, markdown description, optional markdown/code preview), an optional recommended option id plus rationale, multiSelect, allowOther (free text, default true) and dependsOn (earlier question ids, display only). Set kind: "rank" to have the user order every option by priority instead of picking (returns Blocks until the user submits (it may take minutes; in Claude Code a long call continues as a background task). Returns Ids (question and option) are ASCII only, [A-Za-z0-9_.:-]: |
| await_user_answersA | Wait for the user to submit an interview that ask_user_rich left pending (delivery=link, a failed browser open, or an earlier call that stopped waiting). Returns the same summary and JSON as ask_user_rich; returns immediately if the user already submitted. |
| append_questionsA | Append follow-up questions to an interview whose form is still open, instead of opening a second form. Use it after ask_user_rich returned status "awaiting", or while a backgrounded ask_user_rich / await_user_answers call is still waiting: the open form updates live, shows the optional Questions take the same shape and rules as in ask_user_rich. Ids must be unique across the whole interview; dependsOn may name any existing question or an earlier one in this call. Returns at once; the answers arrive through the call that is already waiting, or through await_user_answers. Fails once the user has submitted: then ask a new interview. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
The three tools cover distinct lifecycle stages: starting an interview, resuming a pending one, and appending to an open form. ask_user_rich and await_user_answers return identical payloads and could be momentarily confused, but the descriptions explicitly state when each applies (link delivery, failed browser open, backgrounded call).
All three names follow a clean verb_noun snake_case pattern: ask_user_rich, await_user_answers, append_questions. Verbs are distinct and the resource (user questions/answers) is consistently implied.
Three tools is minimal but each maps to a real lifecycle step (open, wait, extend), matching the narrow, single-purpose scope of a rich user-interview server. It sits at the low end of the healthy range rather than being over-built.
The interview lifecycle is well covered: create, resume waiting, and append follow-ups, with clear handling of deferred/needs-info states. Minor gaps exist around managing abandoned interviews (no cancel/close or list-pending operation), but the core workflow has no dead ends.