Which integrations are available for this server?

Allows GitHub Copilot in VS Code to present interactive popups for user input. Enables interactive popup-based user input collection when used with Ollama and compatible frontends.

How do I use mcp-popup-ui?

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., "@mcp-popup-ui Show me a popup to select my preferred JavaScript framework: React, Vue, or Svelte." 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.

mcp-popup-ui

by jens-duttke

Overview Schema Related Servers Score Discussions

TypeScript

Local

An MCP (Model Context Protocol) server that lets AI assistants ask you questions through a visual popup in your browser - instead of just printing text options.

MCP Popup UI in action with LM Studio

📢 A Note on the Future
This project started as an experimental solution to a gap in the MCP ecosystem: letting AI assistants collect user input through a visual interface rather than plain text. It works today with any MCP-compatible client.
The MCP specification now includes MCP Apps - an official extension that embeds interactive UIs directly in the chat conversation. This provides a better user experience (no browser popup, no context switching) and will eventually be the recommended approach.
For now, mcp-popup-ui remains useful because MCP Apps support is still limited to a few clients (Claude, VS Code Insiders, Goose, Postman, MCPJam). Once MCP Apps becomes widely available, consider migrating to an MCP Apps-based solution for the best experience.

What This Does

When you chat with an AI assistant (like GitHub Copilot, Claude, or a local LLM), the AI sometimes needs your input - for example, "Which framework do you want?" or "Select the features to include."

Without this tool, the AI would print a numbered list and ask you to type your choice. With mcp-popup-ui, a clean popup opens in your browser where you can click your selection directly.

Two tools are provided:

Tool	Purpose	UI Element
`ask_user`	Pick exactly one option	Radio buttons
`ask_user_multiple`	Pick one or more options	Checkboxes

Related MCP server: Interactive MCP

Installation

Install globally via npm:

npm install -g mcp-popup-ui

Or run directly without installing:

npx y- mcp-popup-ui

Requirements: Node.js 18 or higher.

Setup

Choose the setup guide for your AI application:

VS Code (GitHub Copilot)

Open your project folder in VS Code

Create or edit the file .vscode/mcp.json:

{
  "servers": {
    "popup-ui": {
      "command": "npx",
      "args": ["mcp-popup-ui"]
    }
  }
}

Restart VS Code or reload the window

LM Studio

Open LM Studio settings
Navigate to the MCP Servers section

Add a new server with these settings:

{
  "mcp-popup-ui": {
    "command": "npx",
    "args": ["mcp-popup-ui"]
  }
}

Enable the server and start a new chat

Ollama (via Open WebUI or similar)

Ollama itself does not natively support MCP. However, you can use it with frontends that support MCP, such as Open WebUI with MCP plugins. The configuration depends on your specific frontend - consult its documentation for adding MCP servers.

Claude Desktop

Add to your Claude Desktop configuration file:

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

{
  "mcpServers": {
    "popup-ui": {
      "command": "npx",
      "args": ["mcp-popup-ui"]
    }
  }
}

Restart Claude Desktop after saving.

Copilot Instructions (Optional)

To ensure the AI uses the popup tools automatically instead of listing options in text, add this to your project's .github/copilot-instructions.md:

## User Input Collection

Use MCP tools for user choices:

- `ask_user` - single selection (radio buttons)
- `ask_user_multiple` - multiple selection (checkboxes)

Use these tools when presenting options like framework choices, implementation approaches, or any list of alternatives.

Tool Reference

ask_user

Displays a popup with radio buttons. The user picks exactly one option.

Parameters:

Parameter	Required	Description
`options`	Yes	Array of options (minimum 2). Each option has a `label` (required), optional `description`, and optional `recommended` flag.
`title`	No	Heading displayed above the options
`description`	No	Additional text displayed below the title
`allow_other`	No	If `true`, adds a text field for custom input
`other_label`	No	Label for the custom input option (default: "Other")

Example call:

{
  "options": [
    { "label": "React", "description": "Component-based UI library" },
    { "label": "Vue", "description": "Progressive JavaScript framework" },
    { "label": "Svelte", "description": "Compile-time framework", "recommended": true }
  ],
  "title": "Choose a Frontend Framework",
  "description": "Select one framework for your project."
}

Response:

{
  "action": "submit",
  "selection": "Svelte"
}

If the user clicks Skip:

{
  "action": "skip"
}

ask_user_multiple

Displays a popup with checkboxes. The user picks one or more options.

Parameters:

Parameter	Required	Description
`options`	Yes	Array of options (minimum 2). Each option has a `label` (required), optional `description`, and optional `recommended` flag.
`title`	No	Heading displayed above the options
`description`	No	Additional text displayed below the title
`allow_other`	No	If `true`, adds a text field for custom input
`other_label`	No	Label for the custom input option (default: "Other")

Example call:

{
  "options": [
    { "label": "TypeScript", "recommended": true },
    { "label": "ESLint" },
    { "label": "Prettier" },
    { "label": "Jest" }
  ],
  "title": "Select Project Features",
  "description": "Choose all features to include."
}

Response:

{
  "action": "submit",
  "selections": ["TypeScript", "ESLint", "Prettier"]
}

Additional Features

Skip button: Users can skip any question without selecting an option
Comments field: Users can add additional notes with their selection
Explanation request: Users can ask for more details about an option before deciding
Markdown support: Option descriptions support Markdown formatting

Documentation

Tool Design Best Practices - Research on LLM tool design patterns

Contributing

See CONTRIBUTING.md for development setup and guidelines.

License

MIT

Available Tools

2 tools

ask_userA

Ask the user to choose exactly ONE option from a list. Use this tool instead of listing options in your text response whenever you need the user to make a decision.

WHEN TO USE THIS TOOL:

You are about to list numbered options and ask "which do you prefer?"
You need user confirmation on a specific choice before proceeding
The user must pick one mutually exclusive option (e.g., "Which approach should I implement?", "Which file should I modify?", "What framework do you want?")

EXAMPLES OF WHEN TO USE:

"Should I use Option A, B, or C?" → Use this tool
"Which implementation approach?" → Use this tool
"What programming language?" → Use this tool
"Pick a template to scaffold" → Use this tool

⚠️ CRITICAL: Each parameter MUST be passed SEPARATELY. Do NOT combine them!

❌ WRONG (options contains title/description - WILL FAIL): options: [{"label": "A"}, {"label": "B"}], "title": "...", "description": "..."

✅ CORRECT (each parameter separate): options: [{"label": "A"}, {"label": "B"}] title: "Pick one" description: "Choose your preference"

PARAMETERS:

options (REQUIRED): Array of objects, each with "label" (required) and optional "description", "recommended"
title (optional): String displayed above options
description (optional): String displayed below title
allow_other (optional): Boolean to allow custom input

The tool opens a popup in the user's browser and waits for their selection. If allow_other is true, users can enter custom text if predefined options don't fit. Returns the selected option as a string, or indicates if the user skipped.

ParametersJSON Schema

Name	Required	Description	Default
`title`	No	Optional title displayed above the selection. Use to provide context or ask a question.
`options`	Yes	List of options for the user to choose from. Each option must have a label property. Use description for additional context (pros/cons, code examples). The user will see these in a popup and select one.
`allow_other`	No	If true, adds an "Other" option that allows the user to enter custom text. Use when the predefined options might not cover all possibilities.
`description`	No	Optional description text displayed below the title. Use for additional instructions or clarification.
`other_label`	No	Custom label for the "Other" option. Only used when allow_other is true.	Other

Output Schema

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Whether the user submitted a selection, skipped, or requested an explanation for an option
`comments`	No	Additional comments provided by the user (only present if allow_comments was true and user entered text)
`selection`	No	The selected option (only present if action is "submit")
`explainOption`	No	The option for which explanation was requested (only present if action is "request_explanation")
`explainMessage`	No	A pre-formatted message asking for explanation (only present if action is "request_explanation")

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full transparency burden. It discloses that the tool 'opens a popup in the user's browser and waits for their selection,' describes the behavior for allow_other, and states the return value (selected option or skip indication). It omits potential timeout/cancellation behavior, but the disclosed core interaction is clearly explained.

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 longer than average but well-structured with headings, examples, and a prominent warning. It front-loads the core purpose and usage. Some repetition exists (e.g., multiple examples of single-choice questions), but each section serves a distinct role, so the length is justified.

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?

Given the tool's interactive nature and five parameters, the description is remarkably complete. It covers what the tool does, when to use it, how to pass parameters correctly, what the popup does, and what it returns. The sibling distinction is implicit via 'exactly ONE,' and the output behavior is addressed, making it adequate even with the output schema present.

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 already covers all parameters at 100% coverage, so the baseline is 3. The description adds genuine value with its CRITICAL warning that parameters must be passed separately, including explicit wrong and correct examples. This clarifies a common misuse that the schema alone does not fully convey, elevating it to 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's purpose: 'Ask the user to choose exactly ONE option from a list.' It explicitly contrasts with text-based listing and the sibling tool by emphasizing 'exactly ONE,' making the tool's role and scope unambiguous.

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 extensive when-to-use guidance, including concrete triggers and examples like 'Should I use Option A, B, or C?' It does not explicitly mention the sibling tool ask_user_multiple by name or state 'do not use when multiple selections are needed,' but the emphatic 'exactly ONE' and mutual-exclusivity wording imply the exclusion.

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

ask_user_multipleA

Ask the user to choose ONE OR MORE options from a list. Use this tool instead of listing options in your text response whenever the user can select multiple items.

WHEN TO USE THIS TOOL:

You are about to list items and ask "which ones do you want?" or "select all that apply"
The user can pick multiple non-exclusive options (e.g., "Which features to include?", "Which files to modify?", "What languages do you know?")
You need to gather multiple preferences at once

EXAMPLES OF WHEN TO USE:

"Which features do you want?" → Use this tool
"Select the files to include" → Use this tool
"What integrations should I add?" → Use this tool
"Pick all applicable tags" → Use this tool

⚠️ CRITICAL: Each parameter MUST be passed SEPARATELY. Do NOT combine them!

❌ WRONG (options contains title/description - WILL FAIL): options: [{"label": "A"}, {"label": "B"}], "title": "...", "description": "..."

✅ CORRECT (each parameter separate): options: [{"label": "A"}, {"label": "B"}] title: "Select features" description: "Choose all that apply"

PARAMETERS:

options (REQUIRED): Array of objects, each with "label" (required) and optional "description", "recommended"
title (optional): String displayed above options
description (optional): String displayed below title
min_selections (optional): Minimum selections required
max_selections (optional): Maximum selections allowed
allow_other (optional): Boolean to allow custom input

The tool opens a popup in the user's browser and waits for their selections. If allow_other is true, users can add custom text if predefined options don't fit. Returns an array of selected options, or indicates if the user skipped.

ParametersJSON Schema

Name	Required	Description	Default
`title`	No	Optional title displayed above the selection. Use to provide context or ask a question.
`options`	Yes	List of options for the user to choose from. Each option must have a label property. Use description for additional context (pros/cons, features). The user will see these in a popup and can select multiple.
`allow_other`	No	If true, adds an "Other" option that allows the user to enter custom text. The "Other" text will be included in the results array if selected.
`description`	No	Optional description text displayed below the title. Use for additional instructions or clarification.
`other_label`	No	Custom label for the "Other" option. Only used when allow_other is true.	Other

Output Schema

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Whether the user submitted selections, skipped, or requested an explanation for an option
`comments`	No	Additional comments provided by the user (only present if allow_comments was true and user entered text)
`selections`	No	The selected options (only present if action is "submit")
`explainOption`	No	The option for which explanation was requested (only present if action is "request_explanation")
`explainMessage`	No	A pre-formatted message asking for explanation (only present if action is "request_explanation")

TDQS

A3.9/5.0

Behavior4/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 discloses the popup interaction ('opens a popup in the user's browser and waits for their selections'), the 'Other' option behavior, and the return value ('Returns an array of selected options, or indicates if the user skipped'). This is adequate, though it could explain the skip signal in more detail.

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 well-structured with clear sections (WHEN TO USE, EXAMPLES, CRITICAL, PARAMETERS) and front-loaded with the core purpose. The warning about parameter separation with wrong/correct examples is valuable but slightly verbose. Overall, each section earns its place.

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?

The description covers behavior, usage contexts, and return values, but it fails to align with the actual schema by listing parameters that don't exist (min_selections, max_selections). This mismatch creates a completeness gap. Core interaction is explained, but the inaccuracies prevent a higher score.

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

Parameters2/5

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

Schema description coverage is 100%, so baseline is 3. However, the description introduces parameters 'min_selections' and 'max_selections' that do not exist in the input schema, potentially misleading the agent. The description largely restates schema fields (label, description, recommended) and the 'CRITICAL' warning, while adding no genuinely useful parameter semantics beyond schema. The presence of non-existent parameters lowers the score.

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 verb and resource: 'Ask the user to choose ONE OR MORE options from a list.' It explicitly distinguishes from sibling tool 'ask_user' by emphasizing multiple selections ('whenever the user can select multiple items'). Examples reinforce the purpose without ambiguity.

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 a dedicated 'WHEN TO USE THIS TOOL' section with specific scenarios and examples ('Which features do you want?', 'Select the files to include'). It clearly implies single-selection cases are not for this tool, but it does not explicitly name the sibling tool or state exclusions, so it stops short of a 5.

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

Install Server

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

TDQS

A4.1/5.0

Disambiguation5/5

The two tools are clearly differentiated by singular vs. plural selection. Ask_user restricts to exactly one option, while ask_user_multiple allows multiple selections, with descriptions emphasizing this distinction.

Naming Consistency5/5

Both tools follow a consistent snake_case verb_noun pattern: ask_user and ask_user_multiple. The naming clearly communicates the shared purpose and the single/multiple distinction.

Tool Count3/5

With only 2 tools, the server feels thin, especially given the broader 'popup-ui' name. The two selection modes cover a narrow niche, and while they are well-defined, the overall surface is minimal.

Completeness3/5

The tools handle single and multiple choice popups, but other common popup interactions such as free-form text input, simple confirmations, or informational dialogs are missing. Agents must rely on allow_other for custom input, which is not ideal, leaving notable gaps.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

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

Skyvern
io.github.Skyvern-AI
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Browser Automation Web Scraping App Automation
222,924
browserbasehq-mcp-browserbaseOAuth
ai.smithery
Provides cloud browser automation capabilities using Stagehand and Browserbase, enabling LLMs to i…
Browser Automation Web Scraping Agent Orchestration
23,406
MeatSpace A
io.github.zmarten
Human-in-the-loop for AI agents. Submit choices, get a human decision.
Agent Orchestration
32
seltz-ai-seltz-mcp
ai.seltz
Provides AI assistants with access to Seltz's powerful Web Search capabilities.
Search Browser Automation Web Scraping
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
Interactive MCP
Developer Tools App Automation
raz-labs
A
license
Not graded
quality
C
maintenance
Enables AI assistants to request user input through interactive popups in VS Code, supporting button selections, text inputs, and confirmation dialogs. This system allows for seamless human-in-the-loop interactions without interrupting the conversational flow.
Updated a year ago (2025-08-04 01:37 UTC)
4
The Unlicense
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
interactive-choice-mcp
App Automation Command Line
Sighthesia
F
license
A
quality
F
maintenance
Enables AI to present options and launch an interactive web or terminal interface for user selection, then return the results to the AI.
Updated 8 months ago (2026-01-13 04:10 UTC)
2
4

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/jens-duttke/mcp-popup-ui'

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

mcp-popup-ui

What This Does

Installation

Setup

VS Code (GitHub Copilot)

LM Studio

Ollama (via Open WebUI or similar)

Claude Desktop

Copilot Instructions (Optional)

Tool Reference

ask_user

ask_user_multiple

Additional Features

Documentation

Contributing

License

Available Tools

Output Schema

TDQS

Output Schema

TDQS

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Implore MCP

Interactive MCP

Human-In-the-Loop MCP Server

interactive-choice-mcp

Latest Blog Posts

MCP directory API