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 pick a framework from React, Vue, 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 animalnots

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

A4.5/5.0

Behavior5/5

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

No annotations provided, but the description accurately describes the tool's behavior (opens a GUI dialog box with a large text area) without contradiction. The tool is simple and non-destructive.

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, front-loaded with the core purpose, no unnecessary words. Efficient and clear.

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?

The description is complete for a simple dialog tool: it states purpose, use cases, and behavior. The schema covers all parameters, and an output schema exists (though not shown). No 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 descriptions for all 3 parameters. The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline for high coverage.

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 it creates a multi-line text input dialog for longer text content. It distinguishes from siblings like get_user_input (single line) and get_user_choice (selection).

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 provides explicit use cases ('perfect for getting detailed descriptions, code, or long-form content'), implying when to use. It does not explicitly mention when not to use, but the context is clear.

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

get_user_choiceB

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

B3.3/5.0

Behavior2/5

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

No annotations exist, so description must fully disclose behavior. It mentions 'opens a GUI dialog box' but omits critical details like blocking behavior, cancellation handling, timeouts, or return format. The agent gains little insight into the tool's runtime effects.

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 sentences efficiently convey the purpose and typical use. No extraneous text, but front-loading could be improved by leading with the primary action.

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?

Given the tool's interactivity (dialog), the description lacks expected details: blocking vs async, return value structure (confirmed by output schema existence), and cancellation behavior. This gap is significant for an agent deciding between this and siblings like show_confirmation_dialog.

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%, so the baseline is 3. The description's mention of 'multiple options' echoes the allow_multiple parameter but adds no new constraints or format details beyond the schema.

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, specifying the verb 'Create' and resource 'choice dialog window'. It implicitly distinguishes from siblings like get_user_input (text) and show_confirmation_dialog (yes/no) by focusing on multiple options.

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?

The description says 'Perfect for getting decisions, preferences, or selections', giving broad context but no explicit when-to-use or when-not-to-use compared to alternatives. No exclusions or alternative recommendations are provided.

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

get_user_inputB

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
`default_value`	No	Default value to pre-fill in the input field
`input_type`	No	Type of input expected	text

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/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 mentions a GUI dialog box and user interaction but does not disclose behavioral traits such as whether it blocks execution, timeout behavior, or what happens if the user cancels.

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?

The description is concise with a clear front-loaded purpose. However, the second line ('This tool opens a GUI dialog box...') slightly repeats the first sentence, making it minimally less efficient.

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 full parameter documentation, the description covers the basic purpose adequately. But it lacks details on error handling, cancellation, or return format, which is a gap for a user-interaction tool.

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%, and the schema documents each parameter well. The description adds no extra context beyond the schema, so it meets the baseline but does not enhance understanding.

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 identifies the tool as creating an input dialog for user data entry, using a specific verb and resource. It distinguishes from siblings like get_user_choice and get_multiline_input by mentioning text, numbers, and other data, but does not explicitly contrast them.

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?

The description states it's 'Perfect for getting specific details, clarifications, or data from the user,' which implies suitable use cases but does not specify when not to use it or provide alternatives like get_multiline_input for multi-line input.

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

A4.2/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It mentions non-destructive behavior, but doesn't disclose potential timeouts, network dependencies, or error states. Adequate for simple read but incomplete.

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?

Single sentence, no fluff, perfectly front-loaded. Every word 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?

Description covers core purpose. With an output schema present (though not provided), it needn't detail return values. Lacks mention of typical response format (e.g., boolean, status code) but sufficient for a health check.

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?

The input schema has 0 parameters, so no param info needed. Baseline 4 applies. Description adds no param details, but none are required.

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, with a specific verb and resource. It distinguishes from sibling tools that 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 Guidelines4/5

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

Implied usage as a prerequisite before other HITL interactions, but lacks explicit when-to-use or when-not-to-use guidance. Could be improved with a note like 'Use before other HITL tools to ensure availability.'

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 provided; description says it 'displays and asks' but omits details like whether it blocks, response format, or 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.

Conciseness5/5

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

Three efficient sentences, front-loaded purpose, no redundancy.

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?

Sufficient for a simple tool given presence of output schema; could mention blocking behavior or return value structure.

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 covers 100% of parameters; description adds no new meaning beyond repeating schema descriptions.

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 it shows a confirmation dialog with Yes/No buttons, distinct from sibling tools like get_multiline_input or 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.

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' but does not mention when not to use or compare directly to siblings.

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.1/5.0

Behavior4/5

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

Without annotations, the description explains that the tool displays a dialog and the user clicks OK to acknowledge. This provides sufficient transparency for a simple, non-destructive tool, though it could mention that no permanent changes occur.

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 sentences, with the main purpose stated first. Every word is essential; there is no redundancy or padding.

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 tool with 2 required parameters and an output schema, the description covers the essential behavior—displaying a message and requiring OK. It is complete and leaves no significant 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 description coverage is 100% (both parameters have descriptions). The tool description does not add new meaning beyond the schema; it only states that there are title and message parameters. Baseline score of 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?

The description clearly states the tool's function: 'Show an information message to the user.' It specifies a verb (show) and a resource (information message), and the mention of clicking OK distinguishes it from sibling tools like show_confirmation_dialog which require a decision.

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?

The description implies usage for informational messages that require only acknowledgement, but does not explicitly state when to use this tool versus alternatives like get_user_input or show_confirmation_dialog. It lacks explicit when-not or alternative guidance.

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.3May 28, 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.9/5.0

Disambiguation5/5

Each tool serves a clearly distinct purpose: input types (single-line, multi-line, choice), display (info, confirmation), and health check. No overlap in functionality.

Naming Consistency4/5

Most tools follow verb_noun pattern (get_*, show_*), but health_check deviates slightly. Overall pattern is clear and predictable.

Tool Count5/5

With 6 tools, the set is well-scoped for human-in-the-loop interactions, covering essential input, output, and status checking without excess.

Completeness4/5

Covers all core HITL interactions (input, choice, confirmation, info display). Minor gaps like file selection or progress indicators, but sufficient for typical use.

Maintenance

ActivityInactive

ResponsivenessNo issues

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

mcp A
com.googleapis.design
Provides UX capabilities to enhance the design output and understanding of AI systems.
Design Tools AI & Machine Learning Software Architecture
52
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
MeatSpace A
io.github.zmarten
Human-in-the-loop for AI agents. Submit choices, get a human decision.
Agent Orchestration
32
FlowstepOAuth
ai.flowstep
Generate, inspect, and manage Flowstep UI designs directly from your AI assistant.
Design Tools Developer Tools
2

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
Autonomous Agents
GongRzhe
A
license
A
quality
F
maintenance
Enables AI assistants like Claude to interact with humans through intuitive GUI dialogs, supporting text input, choices, confirmations, and information displays.
Updated a year ago (2025-06-18 07:37 UTC)
6
163
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/animalnots/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`