How do I use Human-In-the-Loop MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Human-In-the-Loop MCP Server Ask the user to choose a framework: React, Vue, or Angular" 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.

Human-In-the-Loop MCP Server

by GongRzhe

Overview Schema Related Servers Score Discussions

Python

Local

Human-In-the-Loop MCP Server

License: MIT PyPI version

A powerful Model Context Protocol (MCP) Server that enables AI assistants like Claude to interact with humans through intuitive GUI dialogs. This server bridges the gap between automated AI processes and human decision-making by providing real-time user input tools, choices, confirmations, and feedback mechanisms.

demo

🚀 Features

💬 Interactive Dialog Tools

Text Input: Get text, numbers, or other data from users with validation
Multiple Choice: Present options for single or multiple selections
Multi-line Input: Collect longer text content, code, or detailed descriptions
Confirmation Dialogs: Ask for yes/no decisions before proceeding with actions
Information Messages: Display notifications, status updates, and results
Health Check: Monitor server status and GUI availability

🎨 Modern Cross-Platform GUI

Windows: Modern Windows 11-style interface with beautiful styling, hover effects, and enhanced visual design
macOS: Native macOS experience with SF Pro Display fonts and proper window management
Linux: Ubuntu-compatible GUI with modern styling and system fonts

⚡ Advanced Features

Non-blocking Operation: All dialogs run in separate threads to prevent blocking
Timeout Protection: Configurable 5-minute timeouts prevent hanging operations
Platform Detection: Automatic optimization for each operating system
Modern UI Design: Beautiful interface with smooth animations and hover effects
Error Handling: Comprehensive error reporting and graceful recovery
Keyboard Navigation: Full keyboard shortcuts support (Enter/Escape)

Related MCP server: Flag MCP

📦 Installation & Setup

Quick Install with uvx (Recommended)

The easiest way to use this MCP server is with uvx:

# Install and run directly
uvx hitl-mcp-server

# Or use the underscore version
uvx hitl_mcp_server

Manual Installation

Install from PyPI:
```
pip install hitl-mcp-server
```
Run the server:
```
hitl-mcp-server
# or
hitl_mcp_server
```

Development Installation

Clone the repository:

git clone https://github.com/GongRzhe/Human-In-the-Loop-MCP-Server.git
cd Human-In-the-Loop-MCP-Server

Install in development mode:
```
pip install -e .
```

🔧 Claude Desktop Configuration

To use this server with Claude Desktop, add the following configuration to your claude_desktop_config.json:

Using uvx (Recommended)

{
  "mcpServers": {
    "human-in-the-loop": {
      "command": "uvx",
      "args": ["hitl-mcp-server"]
    }
  }
}

Using pip installation

{
  "mcpServers": {
    "human-in-the-loop": {
      "command": "hitl-mcp-server",
      "args": []
    }
  }
}

Configuration File Locations

Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

Important Note for macOS Users

Note: You may need to allow Python to control your computer in System Preferences > Security & Privacy > Accessibility for the GUI dialogs to work properly.

After updating the configuration, restart Claude Desktop for the changes to take effect.

🛠️ Available Tools

1. `get_user_input`

Get single-line text, numbers, or other data from users.

Parameters:

title (str): Dialog window title
prompt (str): Question/prompt text
default_value (str): Pre-filled value (optional)
input_type (str): "text", "integer", or "float" (default: "text")

Example Usage:

result = await get_user_input(
    title="Project Setup",
    prompt="Enter your project name:",
    default_value="my-project",
    input_type="text"
)

2. `get_user_choice`

Present multiple options for user selection.

Parameters:

title (str): Dialog window title
prompt (str): Question/prompt text
choices (List[str]): Available options
allow_multiple (bool): Allow multiple selections (default: false)

Example Usage:

result = await get_user_choice(
    title="Framework Selection",
    prompt="Choose your preferred framework:",
    choices=["React", "Vue", "Angular", "Svelte"],
    allow_multiple=False
)

3. `get_multiline_input`

Collect longer text content, code, or detailed descriptions.

Parameters:

title (str): Dialog window title
prompt (str): Question/prompt text
default_value (str): Pre-filled text (optional)

Example Usage:

result = await get_multiline_input(
    title="Code Review",
    prompt="Please provide your detailed feedback:",
    default_value=""
)

4. `show_confirmation_dialog`

Ask for yes/no confirmation before proceeding.

Parameters:

title (str): Dialog window title
message (str): Confirmation message

Example Usage:

result = await show_confirmation_dialog(
    title="Delete Confirmation",
    message="Are you sure you want to delete these 5 files? This action cannot be undone."
)

5. `show_info_message`

Display information, notifications, or status updates.

Parameters:

title (str): Dialog window title
message (str): Information message

Example Usage:

result = await show_info_message(
    title="Process Complete",
    message="Successfully processed 1,247 records in 2.3 seconds!"
)

6. `health_check`

Check server status and GUI availability.

Example Usage:

status = await health_check()
# Returns detailed platform and functionality information

📋 Response Format

All tools return structured JSON responses:

{
    "success": true,
    "user_input": "User's response text",
    "cancelled": false,
    "platform": "windows",
    "input_type": "text"
}

Common Response Fields:

success (bool): Whether the operation completed successfully
cancelled (bool): Whether the user cancelled the dialog
platform (str): Operating system platform
error (str): Error message if operation failed

Tool-Specific Fields:

get_user_input: user_input, input_type
get_user_choice: selected_choice, selected_choices, allow_multiple
get_multiline_input: user_input, character_count, line_count
show_confirmation_dialog: confirmed, response
show_info_message: acknowledged

🧠 Best Practices for AI Integration

When to Use Human-in-the-Loop Tools

Ambiguous Requirements - When user instructions are unclear
Decision Points - When you need user preference between valid alternatives
Creative Input - For subjective choices like design or content style
Sensitive Operations - Before executing potentially destructive actions
Missing Information - When you need specific details not provided
Quality Feedback - To get user validation on intermediate results

Example Integration Patterns

File Operations

# Get target directory
location = await get_user_input(
    title="Backup Location",
    prompt="Enter backup directory path:",
    default_value="~/backups"
)

# Choose backup type
backup_type = await get_user_choice(
    title="Backup Options",
    prompt="Select backup type:",
    choices=["Full Backup", "Incremental", "Differential"]
)

# Confirm before proceeding
confirmed = await show_confirmation_dialog(
    title="Confirm Backup",
    message=f"Create {backup_type['selected_choice']} backup to {location['user_input']}?"
)

if confirmed['confirmed']:
    # Perform backup
    await show_info_message("Success", "Backup completed successfully!")

Content Creation

# Get content requirements
requirements = await get_multiline_input(
    title="Content Requirements",
    prompt="Describe your content requirements in detail:"
)

# Choose tone and style
tone = await get_user_choice(
    title="Content Style",
    prompt="Select desired tone:",
    choices=["Professional", "Casual", "Friendly", "Technical"]
)

# Generate and show results
# ... content generation logic ...
await show_info_message("Content Ready", "Your content has been generated successfully!")

🔍 Troubleshooting

Common Issues

GUI Not Appearing

Verify you're running in a desktop environment (not headless server)
Check if tkinter is installed: python -c "import tkinter"
Run health check: health_check() tool to diagnose issues

Permission Errors (macOS)

Grant accessibility permissions in System Preferences > Security & Privacy > Accessibility
Allow Python to control your computer
Restart terminal after granting permissions

Import Errors

Ensure package is installed: pip install hitl-mcp-server
Check Python version compatibility (>=3.8 required)
Verify virtual environment activation if using one

Claude Desktop Integration Issues

Check configuration file syntax and location
Restart Claude Desktop after configuration changes
Verify uvx is installed: pip install uvx
Test server manually: uvx hitl-mcp-server

Dialog Timeout

Default timeout is 5 minutes (300 seconds)
Dialogs will return with cancelled=true if user doesn't respond
Ensure user is present when dialogs are triggered

Debug Mode

Enable detailed logging by running the server with environment variable:

HITL_DEBUG=1 uvx hitl-mcp-server

🏗️ Development

Project Structure

Human-In-the-Loop-MCP-Server/
├── human_loop_server.py       # Main server implementation
├── pyproject.toml            # Package configuration
├── README.md                 # Documentation
├── LICENSE                   # MIT License
├── .gitignore               # Git ignore rules
└── demo.gif                 # Demo animation

Contributing

Fork the repository
Create a feature branch: git checkout -b feature-name
Make your changes with proper testing
Follow code style guidelines (Black, Ruff)
Add type hints and docstrings
Submit a pull request with detailed description

Code Quality

Formatting: Black (line length: 88)
Linting: Ruff with comprehensive rule set
Type Checking: MyPy with strict configuration
Testing: Pytest for unit and integration tests

🌍 Platform Support

Windows

Windows 10/11 with modern UI styling
Enhanced visual design with hover effects
Segoe UI and Consolas font integration
Full keyboard navigation support

macOS

Native macOS experience
SF Pro Display system fonts
Proper window management and focus
Accessibility permission handling

Linux

Ubuntu/Debian compatible
Modern styling with system fonts
Cross-distribution GUI support
Minimal dependency requirements

📄 License

This project is licensed under the MIT License - see the LICENSE file for details.

🤝 Acknowledgments

Built with FastMCP framework
Uses Pydantic for data validation
Cross-platform GUI powered by tkinter
Inspired by the need for human-AI collaboration

🔗 Links

PyPI Package: https://pypi.org/project/hitl-mcp-server/
Repository: https://github.com/GongRzhe/Human-In-the-Loop-MCP-Server
Issues: Report bugs or request features
MCP Protocol: Learn about Model Context Protocol

📊 Usage Statistics

Cross-Platform: Windows, macOS, Linux
Python Support: 3.8, 3.9, 3.10, 3.11, 3.12+
GUI Framework: tkinter (built-in with Python)
Thread Safety: Full concurrent operation support
Response Time: < 100ms dialog initialization
Memory Usage: < 50MB typical operation

Made with ❤️ for the AI community - Bridging humans and AI through intuitive interaction

Available Tools

6 tools

get_multiline_inputA

Create a multi-line text input dialog for the user to enter longer text content.

This tool opens a GUI dialog box with a large text area where the user can input multiple lines of text. Perfect for getting detailed descriptions, code, or long-form content.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Title of the input dialog window
`prompt`	Yes	The prompt/question to show to the user
`default_value`	No	Default text to pre-fill in the text area

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must cover behavior. It mentions opening a GUI dialog but omits key details: whether it blocks, if cancellable, what happens on cancel/close, any side effects, or the return format. With output schema, return structure may be covered, but behavioral context is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two paragraphs: first defines purpose, second adds usage context. No wasted words, but slightly redundant. Could be more concise without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple dialog tool with 3 parameters and an output schema, the description is adequate but lacks behavioral details (e.g., modal/blocking, cancellation behavior). Sibling differentiation is implicit rather than explicit. Meets minimum but has gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with good descriptions. The tool description does not add meaning beyond the schema; it only restates 'title' and 'prompt' in usage context. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool creates a multi-line text input dialog for longer text, distinguishing it from siblings like get_user_input (single line) and get_user_choice.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Perfect for getting detailed descriptions, code, or long-form content,' which implies when to use, but lacks explicit when-not-to-use or alternative mentions. Sibling names provide implicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_user_choiceA

Create a choice dialog window for the user to select from multiple options.

This tool opens a GUI dialog box with a list of choices where the user can select one or multiple options. Perfect for getting decisions, preferences, or selections from the user.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Title of the choice dialog window
`prompt`	Yes	The prompt/question to show to the user
`choices`	Yes	List of choices to present to the user
`allow_multiple`	No	Whether user can select multiple choices

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It notes the tool opens a GUI dialog and supports single/multiple selection, but fails to disclose critical behaviors such as blocking nature, return format on cancel, or any side effects, leaving significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loading the purpose and then offering context. No unnecessary text; every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While an output schema exists (context signals), the description omits essential behavioral details like cancellation handling, blocking behavior, or return value structure, which are critical for a user-interaction tool with no annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with all parameters described. The description reiterates schema info (e.g., 'list of choices') without adding new semantic meaning. Baseline 3 is appropriate as the schema already documents the parameters adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a choice dialog for user selection from multiple options, with explicit mention of single or multiple selection, distinguishing it from sibling tools like get_user_input (free text) and show_confirmation_dialog (yes/no).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises it's 'perfect for getting decisions, preferences, or selections,' providing clear context for use. However, it lacks explicit guidance on when not to use it or mention of alternative tools for other input types.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_user_inputC

Create an input dialog window for the user to enter text, numbers, or other data.

This tool opens a GUI dialog box where the user can input information that the LLM needs. Perfect for getting specific details, clarifications, or data from the user.

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes	Title of the input dialog window
`prompt`	Yes	The prompt/question to show to the user
`input_type`	No	Type of input expected	text
`default_value`	No	Default value to pre-fill in the input field

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It mentions opening a GUI dialog but does not explain blocking behavior, cancellation handling, or error states. Critical transparency for an interactive tool is missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise but contains slight redundancy (the third sentence repeats the idea of getting user input). The main purpose is front-loaded, but could be sharper.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and simple parameters, the description covers basic functionality. However, it omits behavioral details like modal vs non-modal, which are important for a dialog tool. Adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema; it does not clarify the difference between integer and float input types or the purpose of default_value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates an input dialog for text, numbers, or other data. It distinguishes from siblings implicitly via input_type but does not explicitly contrast with get_multiline_input or get_user_choice.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use or when-not-to-use guidance is provided. The description says 'perfect for getting specific details' but does not mention alternatives or conditions. With sibling tools like get_multiline_input and get_user_choice, the lack of guidance is a significant gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

health_checkA

Check if the Human-in-the-Loop server is running and GUI is available.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and description does not disclose potential latency, error responses, or side effects. Minimal transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One concise sentence with no redundant information. Perfectly front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Description covers basic purpose but lacks detail on output format or error scenarios, though output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist (schema coverage 100%), and the description adds purpose beyond the empty schema, justifying baseline 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks server and GUI availability, using specific verb and resource. It distinguishes from sibling tools which handle user input/dialogs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use, but context implies it's a prerequisite check before interactive tools. Lacks explicit when-not or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

show_confirmation_dialogA

Show a confirmation dialog with Yes/No buttons.

This tool displays a message to the user and asks for confirmation. Perfect for getting approval before proceeding with an action.

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes	Title of the confirmation dialog
`message`	Yes	The message to show to the user

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so description carries full burden. It states functionality but does not disclose return value, blocking behavior, or what happens upon user interaction. Lacks important behavioral details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no fluff. Front-loaded purpose and immediate usage context. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple confirmation dialog with 2 params and existing output schema. Could improve by mentioning return value or modal behavior, but functional completeness is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions for both parameters. The tool description adds minimal extra meaning beyond 'get approval' context. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Show a confirmation dialog with Yes/No buttons' and 'displays a message to the user and asks for confirmation.' Distinct from siblings like get_user_input or show_info_message by focusing on binary approval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Perfect for getting approval before proceeding with an action,' providing clear when-to-use context. Does not explicitly exclude alternatives, but the purpose is well-defined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

show_info_messageA

Show an information message to the user.

This tool displays an informational message dialog to notify the user about something. The user just needs to click OK to acknowledge the message.

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes	Title of the information dialog
`message`	Yes	The information message to show to the user

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses that it displays a dialog and requires a click, which is key behavioral information. With no annotations, the description covers the essential behavior adequately.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two sentences that convey the purpose and user interaction. No fluff or unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple informational dialog, the description is fully complete. It explains the action and user response, and there's an output schema to handle return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Parameter descriptions are fully provided in the input schema, so the description adds no extra meaning beyond what the schema already conveys.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Show an information message to the user', using a specific verb and resource. Distinguishes well from sibling tools that handle user input or confirmations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context that the user clicks OK to acknowledge, implied usage. No explicit when-not-to-use or alternatives, but the tool's role is obvious from the name and sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.3Jul 12, 2026
- First observedget_multiline_input
- First observedget_user_choice
- First observedget_user_input
- First observedhealth_check
- First observedshow_confirmation_dialog
- First observedshow_info_message

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: multiline input, choice selection, single input, health check, confirmation dialog, and info message. There is no ambiguity or overlap.

Naming Consistency4/5

Most tools follow verb_noun pattern (get_*, show_*), but health_check deviates as a noun-only name. This minor inconsistency does not cause confusion.

Tool Count5/5

6 tools is well-scoped for a human-in-the-loop server. Each tool addresses a distinct user interaction need without being excessive or insufficient.

Completeness4/5

The set covers core human-in-the-loop operations: input (single, multiline, choices) and output (info, confirmation). Health check is a nice addition. Could add progress or file picker, but not essential.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Superforms B
co.superforms
Human-input bridge for AI agents with voice-first answer links, MCP tools, and HTTP APIs.
Agent Orchestration Speech Processing App Automation
112
SimSenseOAuth
ai.simsense
Deploy sims to any screen. Control your displays with Claude.
App Automation Virtualization OS Automation
2
SimStim
ai.simstim
Deploy sims to any screen. Control your displays with Claude.
App Automation Virtualization OS Automation
2
mcp
com.branderux
Turns any agent into a full agentic application — branded, interactive screens generated at runtime.
Agent Orchestration Autonomous Agents
1

Related MCP Servers

Implore MCP
App Automation Developer Tools
kerodkibatu
F
license
A
quality
D
maintenance
Enables AI assistants to request human input through interactive GUI dialogs with quiz-style questions, supporting multiple choice and free-form responses for clarification, decisions, and knowledge extraction.
Updated 10 months ago (2025-10-30 18:10 UTC)
1
-
Flag MCP
Developer Tools AI & Machine Learning
the-nine-nation
A
license
A
quality
D
maintenance
Enables human-in-the-loop interaction for AI coding workflows through native desktop dialogs that present route choices, text input, and image annotation capabilities when AI assistants encounter decision points.
Updated 5 months ago (2026-04-08 07:18 UTC)
1
2
MIT
Human-In-the-Loop MCP Server
App Automation
animalnots
A
license
A
quality
D
maintenance
Enables AI assistants to interact with humans through GUI dialogs for text input, choices, confirmations, and information display.
Updated 7 months ago (2026-02-18 16:31 UTC)
6
MIT
Ping Principal MCP
Developer Tools
willwillems
A
license
Not graded
quality
D
maintenance
Enables AI agents to request human input through native macOS dialogs for clarifying questions and user interactions.
Updated a year ago (2025-07-12 14:12 UTC)
13
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/GongRzhe/Human-In-the-Loop-MCP-Server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Human-In-the-Loop MCP Server

🚀 Features

💬 Interactive Dialog Tools

🎨 Modern Cross-Platform GUI

⚡ Advanced Features

📦 Installation & Setup

Quick Install with uvx (Recommended)

Manual Installation

Development Installation

🔧 Claude Desktop Configuration

Using uvx (Recommended)

Using pip installation

Configuration File Locations

Important Note for macOS Users

🛠️ Available Tools

1. get_user_input

2. get_user_choice

3. get_multiline_input

4. show_confirmation_dialog

5. show_info_message

6. health_check

📋 Response Format

🧠 Best Practices for AI Integration

When to Use Human-in-the-Loop Tools

Example Integration Patterns

File Operations

Content Creation

🔍 Troubleshooting

Common Issues

Debug Mode

🏗️ Development

Project Structure

Contributing

Code Quality

🌍 Platform Support

Windows

macOS

Linux

📄 License

🤝 Acknowledgments

🔗 Links

📊 Usage Statistics

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `get_user_input`

2. `get_user_choice`

3. `get_multiline_input`

4. `show_confirmation_dialog`

5. `show_info_message`

6. `health_check`