human_input
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HIM_LOG | No | Log level; all logs go to stderr. | info |
| HIM_FALLBACK | No | Fallback mode when the client does not support elicitation: 'return' | 'http' | 'off'. | return |
| HIM_HTTP_HOST | No | Host address for http fallback. | 127.0.0.1 |
| HIM_HTTP_OPEN | No | Whether to open the browser in http fallback mode. | 1 |
| HIM_HTTP_PORT | No | Port for http fallback (0 means auto-assign). | 0 |
| HIM_TIMEOUT_MS | No | Single question wait limit (1000–3600000). | 300000 |
| HIM_STRICT_STDOUT | No | Set '0' to disable console → stderr redirection protection. | 1 |
| HIM_AUTO_REJECT_MS | No | Declines faster than this threshold (ms) are treated as auto-rejected. | 400 |
| HIM_MULTISELECT_MODE | No | How multiselect answers are returned: 'array' | 'text'. | array |
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_choiceA | Ask the user to choose exactly one of 2-25 options and wait for the answer. Use this when a decision has a small set of genuinely viable alternatives and the choice changes what you build — for example an architecture, a library, a naming scheme, or a file layout. Prefer this over ask_confirm whenever the real answer is a choice rather than yes/no, and over ask_text whenever the reasonable answers can be enumerated. The user may additionally leave free-text notes when allow_free_text is true. Returns the selected option label in |
| ask_confirmA | Ask the user a single yes/no question and wait for the answer. Use this before destructive or irreversible actions (deleting, overwriting, migrating, force-pushing, publishing), and for any binary decision the user should own. State the exact target and the consequence in |
| ask_textA | Ask the user an open-ended question and wait for a typed answer. Use this only when the answer cannot be enumerated — a URL, a credential-free identifier, a naming preference, or extra context you cannot infer. If a handful of concrete answers would cover most cases, use ask_choice instead so the user can answer with one keystroke. Returns the typed string in |
| ask_multi_selectA | Ask the user to select one or more options from a list and wait for the answer. Use this when the user should pick a subset — which platforms to target, which checks to enable, which modules to include. Set min/max when the count genuinely matters; leave them out otherwise. Returns the selected labels in |
| human_input_statusA | Diagnostic: report whether the connected client supports MCP form elicitation, which fallback mode is configured, and how long questions may wait. Call this once when the user asks why a question did not appear, or to verify that this MCP server is actually connected. This tool never asks the user anything and never blocks. |
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 5 tools
Each tool targets a distinct interaction mode: single-choice, binary confirm, free-text, multi-select, and diagnostic status. The descriptions explicitly call out when to prefer one over another, leaving no ambiguity about tool boundaries.
Four question tools follow a clear `ask_<type>` pattern, making their purpose immediately obvious. The diagnostic tool `human_input_status` deviates from this pattern, but its distinct role as a non-question tool makes the inconsistency minor.
Five tools is a well-scoped set for a human-input server: each interaction mode earns its place, and adding more would likely over-engineer the surface.
The server covers the full range of human input scenarios: enumerated single choice, multi-select, yes/no, and open-ended text. The status tool fills the diagnostic gap, giving agents a way to verify connectivity and behavior without blocking.