Provides autocomplete for GitHub issues and pull requests in multiline input dialogs.
Allows GitHub Copilot CLI to request human input through browser dialogs for interactive decision-making.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@human-loop-mcp show a confirmation dialog to deploy v2.1.0 to production"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that gives AI agents a way to ask the human operator questions through the browser.
A lightweight localhost HTTP server spins up
Your default browser opens a dialog page
You fill in the form (optionally attaching files) and submit
The response flows back to the agent through MCP
No Python, no Tkinter, no Electron — just a Node.js process, a browser tab, and clean HTML.
GUI-based human-in-the-loop tools often break on macOS (Accessibility permissions, focus stealing, Python framework builds). This project sidesteps all of that by using the browser as the UI layer — it works everywhere Node.js runs.
Related MCP server: Implore MCP
7 MCP tools | Text input, multiline, choice, confirmation, info, health check, and usage guidance |
File attachments | Drag-and-drop, paste, or click-to-upload files in the multiline dialog. Files are base64-encoded and returned alongside the text response (5 MB per-file limit) |
Autocomplete |
|
Dark/light mode | Follows system preference automatically |
Keyboard-first |
|
Command-palette UI | Linear/Raycast-inspired design with purple accents, monospace labels, noise texture background |
Zero bloat | Only two runtime dependencies: |
Single-file HTML | No static assets, no bundler — fully server-rendered |
npm install -g human-loop-mcpOr run directly without installing:
npx human-loop-mcpgit clone https://github.com/dzulfiikar/human-loop-mcp.git
cd human-loop-mcp
npm install
npm run buildAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"human-loop": {
"command": "npx",
"args": ["-y", "human-loop-mcp"]
}
}
}Add to .cursor/mcp.json or equivalent:
{
"mcpServers": {
"human-loop": {
"command": "npx",
"args": ["-y", "human-loop-mcp"]
}
}
}[mcp_servers.human-loop]
command = "npx"
args = ["-y", "human-loop-mcp"][mcp_servers.human-loop-dev]
command = "npx"
args = ["tsx", "/path/to/human-loop-mcp/src/index.ts"]Tool | Description |
| Single-line text, password, integer, or float input |
| Single or multi-select from a list of choices |
| Large text area with autocomplete and file attachments |
| Binary confirm/cancel dialog |
| Informational message with acknowledgement |
| Returns guidance text on when to use the tools |
| Returns server health status and available tools |
{
"title": "API Key",
"prompt": "Enter your OpenAI API key:",
"input_type": "password"
}{
"title": "Database",
"prompt": "Which database should I use?",
"choices": ["PostgreSQL", "MySQL", "SQLite"],
"allow_multiple": false
}{
"title": "Deploy",
"message": "Deploy v2.1.0 to production?",
"confirm_label": "Deploy",
"cancel_label": "Abort"
}The get_multiline_input dialog supports file attachments through three methods:
Method | How |
Drag and drop | Drag files onto the textarea — a drop overlay appears |
Paste |
|
Upload button | Click the paperclip "Attach" button below the textarea |
Any file type is accepted
5 MB per-file limit — oversized files are rejected with an inline error
Files are base64-encoded and returned in the tool result alongside the text value
Image previews are shown as thumbnails in the attachment chips
Each chip shows the file name, size, and a remove button
When no files are attached, the result is identical to the previous format (fully backward-compatible)
When attachments are present, the get_multiline_input tool returns:
{
"action": "submit",
"value": "Here is the screenshot",
"attachments": [
{
"name": "screenshot.png",
"type": "image/png",
"size": 48210,
"data": "iVBORw0KGgo..."
}
]
}When no attachments are provided, the attachments field is omitted entirely.
Variable | Default | Description |
|
| HTTP server bind address |
| (ephemeral) | Fixed HTTP port. If unset, the OS assigns a random port |
| (unset) | Set to |
import { BrowserDialogServer } from "human-loop-mcp/browser/browser-dialog-server";
const server = new BrowserDialogServer({
port: 8080,
launchUrl: async (url) => {
console.log(`Open: ${url}`);
},
});┌──────────────────────────────────────────┐
│ MCP Client (AI Agent) │
│ Claude / Cursor / Copilot CLI │
└──────────────┬───────────────────────────┘
│ stdio (JSON-RPC)
┌──────────────▼───────────────────────────┐
│ index.ts Tool registration │
│ service.ts Business logic │
│ browser-dialog-server.ts HTTP + APIs │
│ dialog-session-manager.ts Sessions │
│ html.ts HTML/CSS/JS renderer │
└──────────────┬───────────────────────────┘
│ HTTP (localhost)
┌──────────────▼───────────────────────────┐
│ Browser Dialog UI │
│ Forms · Autocomplete · Attachments │
│ Dark/light · Keyboard shortcuts │
└──────────────────────────────────────────┘MCP client calls a tool (e.g. get_multiline_input) via stdio JSON-RPC
index.ts routes the call to HumanLoopService
service.ts transforms args and calls BrowserDialogServer.openDialog()
browser-dialog-server.ts creates a session, starts HTTP if needed, opens the browser
html.ts renders a self-contained HTML page with the dialog form
User submits (with optional file attachments) — the POST handler validates and resolves the session promise
Response flows back through MCP to the AI agent, including any base64-encoded attachments
npm install # Install dependencies
npm run dev # Run from source (tsx, hot-reload)
npm run build # Compile to dist/
npm test # Run tests (Vitest)
npm run typecheck # Type-check without emittingsrc/
├── index.ts MCP server entry point & tool registration
├── service.ts Tool handler business logic
└── browser/
├── browser-dialog-server.ts HTTP server, browser launcher, API endpoints
├── dialog-session-manager.ts Session lifecycle, validation & attachment types
└── html.ts Dialog page renderer (forms, autocomplete, attachments)
tests/
├── service.test.ts
├── dialog-session-manager.test.ts
└── browser-dialog-server.test.tsSee CONTRIBUTING.md for development setup, code style, and PR guidelines.
Explain when to use the human-loop browser tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose any behavioral traits (e.g., side effects, output format, permissions). It does not even indicate whether the tool is read-only or returns a prompt.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one sentence and concise, but it is underspecified and does not earn its place by providing useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description must stand alone. It fails to explain what the tool returns or how to interpret its output, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline is 4. However, the description adds no meaningful context about the tool's function beyond the empty schema. It scores 3 due to lack of added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Explain when to use the human-loop browser tools' is vague and does not specify a concrete action or resource. It sounds like a documentation title rather than a tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus sibling tools (e.g., get_user_input, show_info_message). The description only mentions 'human-loop browser tools' without clarifying which context applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a browser-based choice dialog for the user.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| prompt | Yes | ||
| choices | Yes | ||
| allow_multiple | No | ||
| default_values | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but adds minimal behavioral info beyond stating it opens a dialog. It does not disclose blocking behavior, return value, or timeout effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single under-specified sentence. For a tool with five parameters and no other documentation, it fails to provide necessary detail, making it not appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 params, 3 required, no output schema, no annotations), the description is woefully incomplete. It does not cover parameter semantics, return values, or usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no explanation of the five parameters (title, prompt, choices, allow_multiple, default_values). The agent gets no help understanding parameter roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (open), resource (browser-based choice dialog), and purpose (for the user). It distinguishes from siblings like get_user_input and show_confirmation_dialog, which serve different interaction patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the user needs to make a choice from predefined options, but provides no explicit guidance on when not to use or alternatives. No scenarios or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a browser-based single-line input dialog for the user.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| prompt | Yes | ||
| input_type | No | ||
| default_value | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It only states 'opens a browser-based dialog' but does not disclose whether it blocks execution, returns the input, handles cancellation, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but at the cost of omitting critical details about parameters and behavior. It is underspecified rather than efficiently comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no schema descriptions, and no output schema, the description fails to cover essential information like how input_type affects the UI or what the return value is. It is inadequate for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It does not describe title, prompt, input_type, or default_value. The word 'single-line' hints at text input but is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens a browser-based single-line input dialog, specifying the resource (input dialog) and action (get user input). It subtly distinguishes from siblings like get_user_choice by implying free-text input, but could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_user_choice or show_confirmation_dialog. The description lacks context for selecting the appropriate tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check server and browser dialog runtime health.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the purpose. It does not mention what the tool returns, potential side effects, authentication needs, or error conditions, leaving significant gaps in understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no extraneous words. It is front-loaded and communicates the tool's purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too brief. It does not specify the return value format or any behavioral details, which is insufficient for an agent to fully understand the tool's output and potential issues.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema coverage is 100%. The description adds no param information, but none is needed. Baseline 4 is appropriate as the description does not detract from schema completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' and a clear resource 'server and browser dialog runtime health', distinguishing it from sibling tools that deal with user interactions (e.g., show_info_message, get_user_input).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings. The description does not mention any context, prerequisites, or exclusions, leaving the agent without direction on appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask the user to confirm or cancel an action in the browser.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| message | Yes | ||
| cancel_label | No | ||
| confirm_label | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether the dialog is blocking, what it returns, if it requires user interaction, or any side effects. The description only states it 'asks', lacking essential behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (8 words), front-loading the core purpose. It is efficient with no fluff, though it sacrifices depth for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no behavioral annotations, the description is incomplete. It does not explain return values, prerequisites, or how the dialog interacts with the browser (e.g., blocking nature). Agent lacks critical info for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about parameters (title, message, cancel_label, confirm_label). While parameter names are somewhat self-explanatory, the description does not clarify their roles or link them to the dialog behavior, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: asking the user to confirm or cancel an action. It uses a specific verb ('Ask') and resource ('confirm or cancel'), distinguishing it from sibling tools like 'get_user_input' (open text) or 'get_user_choice' (multiple options).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for binary confirmations, but does not mention when not to use it or how it differs from sibling tools like 'show_info_message' or 'get_human_loop_prompt'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show an informational browser page and wait for acknowledgement.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| message | Yes | ||
| acknowledge_label | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description provides basic behavior but lacks details about blocking nature, timeout, permissions, or whether it can be dismissed. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, clearly conveys the main action. Could benefit from slightly more detail, but remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, description misses parameter clarifications and does not distinguish from similar siblings. Return behavior not mentioned, but output schema is absent so not fully required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description does not explain parameters beyond their names. It associates title and message with the informational page but omits the purpose of acknowledge_label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it shows an informational page and waits for acknowledgement. Good verb+resource combination, but does not explicitly distinguish from sibling show_confirmation_dialog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like show_confirmation_dialog or get_user_input. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: showing info, getting input, getting a choice, confirming, explaining usage, and health check. No overlaps.
All tool names follow a consistent verb_noun or noun_noun pattern in snake_case (e.g., show_info_message, get_user_input, health_check). No deviations.
6 tools is well-scoped for a human-in-the-loop server, covering core interaction types without bloat or insufficiency.
The set covers the essential human-loop interactions: informational display, single-line input, choice selection, confirmation, plus a meta tool and health check. No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Poke your human for approvals and decisions during agent sessions — answered with one phone tap.
Send mobile pings and route human questions, approvals, and handoffs from AI agents.
Get a real human to verify, decide, or improve an AI agent's work.
Human-input bridge for AI agents with voice-first answer links, MCP tools, and HTTP APIs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dzulfiikar/human-loop-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server