Human-in-the-Loop MCP server for interactive AI agent workflows. Provides tools for AI agents to request human input, confirmation, and approval at critical decision points. Tools BLOCK until the user responds, ensuring human oversight of consequential actions.
This HITL server presents a well-structured interaction toolkit with clear naming conventions and decent parameter schemas. All 6 tools follow a consistent verb_noun pattern (hitl_ask, hitl_choose, hitl_collect, hitl_confirm, hitl_notify, hitl_poll) that clearly signals their intent. Input schemas are present and properly typed for all tools. Descriptions are present for all tools and most parameters. However, there are meaningful gaps: (1) output schemas are completely undocumented, callers cannot predict return structure; (2) several parameter descriptions are minimal or generic ('Optional project identifier for session tracking' lacks detail on what tracking means or how project_id affects behavior); (3) no error handling guidance documented, what happens on timeout, invalid input, or user cancel?; (4) hitl_poll's single parameter lacks sufficient context about request_id origin and validity window. The server demonstrates solid fundamentals but lacks the production-grade polish of A-tier tools.
Request free-form text input from the user
Present the user with a choice between multiple options
Collect structured data from the user via a form
Request user confirmation (yes/no) for an action
Send a notification message to the user
Poll for a user response without blocking indefinitely
Output schemas completely undocumented. No tool documents what fields or structure it returns. LLMs cannot predict or chain results.
Parameter descriptions lack actionable detail. 'Optional project identifier for session tracking' does not explain what project_id controls, whether it affects response routing, or how to obtain valid values.
hitl_poll description is minimal (only 66 chars) and does not explain where request_id comes from, how long it remains valid, or what response formats to expect on different states.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 64 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 69 | - | v1 |
No timeout or error handling guidance in tool descriptions. hitl_ask and hitl_choose accept max_wait_minutes but do not document what happens when timeout fires (exception? null return? default value?).
hitl_collect 'fields' parameter schema is minimal. No description of field structure (how to specify field name, type, validation rules, etc.). LLMs cannot construct valid field arrays without trial-and-error.
No documented relationship between tool calls. hitl_poll references a request_id, but no tool describes how to obtain a request_id or whether all HITL tools return one.