Skip to main content
Glama
teacat99

gl-mcp-feedback

by teacat99

gl-mcp-feedback(交互反馈 MCP)

PyPI GitHub

基于: Fábio Ferreirainteractive-feedback-mcp ⭐ 和 Minidoracatmcp-feedback-enhanced UI 设计参考: sanshao85/mcp-feedback-collector

🎯 核心概念

这是一个 MCP 服务器,建立反馈导向的开发工作流程,提供 Web UI 界面,完美适配本地、SSH 远程开发环境WSL (Windows Subsystem for Linux) 环境。通过引导 AI 与用户确认而非进行推测性操作,可将多次工具调用合并为单次反馈导向请求,大幅节省平台成本并提升开发效率。

支持平台: Cursor | Cline | Windsurf | Augment | Trae

🔄 工作流程

  1. AI 调用gl-mcp-feedback 工具

  2. 界面启动 → 自动打开浏览器界面

  3. 智能交互 → 提示词选择、文字输入、图片上传、自动提交

  4. 即时反馈 → WebSocket 连接即时传递信息给 AI

  5. 会话追踪 → 自动记录会话历史与统计

  6. 流程继续 → AI 根据反馈调整行为或结束任务

Related MCP server: mcp-feedback-enhanced

🌟 主要功能

🌐 Web UI 界面

  • 轻量级浏览器界面:无需额外 GUI 依赖,适合各种环境

  • 环境自动检测:智能识别 SSH Remote、WSL 等特殊环境

  • 跨平台支持:Windows、macOS、Linux 全平台兼容

📝 智能工作流程

  • 提示词管理:常用提示词的 CRUD 操作、使用统计、智能排序

  • 自动定时提交:1-86400 秒弹性计时器,支持暂停、恢复、取消,新增暂停/开始按钮控制

  • 自动执行命令(v2.6.0):新建会话和提交后可自动执行预设命令,提升开发效率

  • 会话管理追踪:本地文件存储、隐私控制、历史导出(支持 JSON、CSV、Markdown 格式)、即时统计、弹性超时设定

  • 连接监控:WebSocket 状态监控、自动重连、品质指示

  • AI 工作摘要 Markdown 显示:支持丰富的 Markdown 语法渲染,包含标题、粗体、代码区块、列表、链接等格式,提升内容可读性

🎨 现代化体验

  • 响应式设计:适配不同屏幕尺寸,模块化 JavaScript 架构

  • 音效通知:内建多种音效、支持自定义音效上传、音量控制

  • 系统通知(v2.6.0):重要事件(如自动提交、会话超时等)的系统级即时提醒

  • 智能记忆:输入框高度记忆、一键复制、设置持久化

  • 多语言支持:简体中文、英文、繁体中文,即时切换

🖼️ 图片与媒体

  • 全格式支持:PNG、JPG、JPEG、GIF、BMP、WebP

  • 便捷上传:拖拽文件、剪贴板粘贴(Ctrl+V)

  • 无限制处理:支持任意大小图片,自动智能处理

🌐 界面预览

Web UI 界面

Web UI 界面 - 提供提示词管理、自动提交、会话追踪等智能功能

快捷键支持

  • Ctrl+Enter(Windows/Linux)/ Cmd+Enter(macOS):提交反馈(主键盘与数字键盘皆支持)

  • Ctrl+V(Windows/Linux)/ Cmd+V(macOS):直接粘贴剪贴板图片

  • Ctrl+I(Windows/Linux)/ Cmd+I(macOS):快速聚焦输入框 (感谢 @penn201500)

🚀 快速开始

1. 安装与测试

# 安装 uv(如果尚未安装)
pip install uv

2. 配置 MCP

基本配置(适合大多数用户):

{
  "mcpServers": {
    "gl-mcp-feedback": {
      "command": "uvx",
      "args": ["gl-mcp-feedback@latest"],
      "timeout": 600,
      "autoApprove": ["interactive_feedback"]
    }
  }
}

进阶配置(需要自定义环境):

{
  "mcpServers": {
    "gl-mcp-feedback": {
      "command": "uvx",
      "args": ["gl-mcp-feedback@latest"],
      "timeout": 600,
      "env": {
        "MCP_DEBUG": "false",
        "MCP_WEB_HOST": "127.0.0.1",
        "MCP_WEB_PORT": "8765",
        "MCP_LANGUAGE": "zh-CN"
      },
      "autoApprove": ["interactive_feedback"]
    }
  }
}

3. 快捷使用

安装并配置完成后,在 Cursor 中输入以下命令即可启动交互反馈:

/user-gl-mcp-feedback/chat

AI 会自动调用 interactive_feedback 工具,打开 Web UI 并等待你的反馈。

提示:为获得最佳效果,建议在 AI 助手的规则中添加:

注意在任务完成前根据 gl-mcp-feedback 工具的要求进行工具调用

⚙️ 高级设置

环境变量

变量

用途

默认

MCP_DEBUG

调试模式

true/false

false

MCP_WEB_HOST

Web UI 主机绑定

IP 地址或主机名

127.0.0.1

MCP_WEB_PORT

Web UI 端口

1024-65535

8765

MCP_LANGUAGE

强制指定界面语言

zh-TW/zh-CN/en

自动检测

MCP_WEB_HOST 说明

  • 127.0.0.1(默认):仅本地访问,安全性较高

  • 0.0.0.0:允许远程访问,适用于 SSH 远程开发环境

MCP_LANGUAGE 说明

  • 用于强制指定界面语言,覆盖系统自动检测

  • 支持的语言代码:

    • zh-TW:繁体中文

    • zh-CN:简体中文

    • en:英文

  • 语言检测优先顺序:

    1. 用户在界面中保存的语言设置(最高优先级)

    2. MCP_LANGUAGE 环境变量

    3. 系统环境变量(LANG、LC_ALL 等)

    4. 系统默认语言

    5. 回退到默认语言(繁体中文)

测试选项

# 版本查询
uvx gl-mcp-feedback@latest version       # 检查版本

# 界面测试
uvx gl-mcp-feedback@latest test --web    # 测试 Web UI (自动持续运行)

# 调试模式
MCP_DEBUG=true uvx gl-mcp-feedback@latest test

# 指定语言测试
MCP_LANGUAGE=en uvx gl-mcp-feedback@latest test --web    # 强制使用英文界面
MCP_LANGUAGE=zh-TW uvx gl-mcp-feedback@latest test --web  # 强制使用繁体中文
MCP_LANGUAGE=zh-CN uvx gl-mcp-feedback@latest test --web  # 强制使用简体中文

开发者安装

git clone https://github.com/youjunxiaji/gl-mcp-feedback.git
cd gl-mcp-feedback
uv sync

本地测试方式

# 功能测试
make test-func                                           # 标准功能测试
make test-web                                            # Web UI 测试 (持续运行)

# 或直接使用指令
uv run python -m mcp_feedback_enhanced test              # 标准功能测试
uvx --no-cache --with-editable . gl-mcp-feedback test --web   # Web UI 测试 (持续运行)

# 单元测试
make test                                                # 运行所有单元测试
make test-fast                                          # 快速测试 (跳过慢速测试)
make test-cov                                           # 测试并生成覆盖率报告

# 代码质量检查
make check                                              # 完整代码质量检查
make quick-check                                        # 快速检查并自动修复

测试说明

  • 功能测试:测试 MCP 工具的完整功能流程

  • 单元测试:测试各个模块的独立功能

  • 覆盖率测试:生成 HTML 覆盖率报告到 htmlcov/ 目录

  • 质量检查:包含 linting、格式化、类型检查

🆕 版本更新记录

📋 完整版本更新记录: RELEASE_NOTES/CHANGELOG.zh-CN.md

最新版本亮点(v2.6.0)

  • 🚀 自动执行命令: 新建会话和提交后可自动执行预设命令,提升工作效率

  • 📊 会话导出功能: 支持将会话记录导出为多种格式,方便分享和存档

  • ⏸️ 自动提交控制: 新增暂停和开始按钮,让用户更好控制自动提交时机

  • 🔔 系统通知: 新增系统级通知功能,重要事件即时提醒

  • ⏱️ 会话超时机制优化: 重新设计会话管理,提供更弹性的设置选项

  • 🌏 多语系强化: 重构多语系架构,通知系统也完整支持多语言

  • 🎨 界面简化: 大幅简化用户界面,提升使用体验

🐛 常见问题

🌐 SSH Remote 环境问题

Q: SSH Remote 环境下浏览器无法启动或无法访问 A: 提供两种解决方案:

方案一:环境变量设置(v2.5.5 推荐) 在 MCP 配置中设置 "MCP_WEB_HOST": "0.0.0.0" 允许远程访问:

{
  "mcpServers": {
    "gl-mcp-feedback": {
      "command": "uvx",
      "args": ["gl-mcp-feedback@latest"],
      "timeout": 600,
      "env": {
        "MCP_WEB_HOST": "0.0.0.0",
        "MCP_WEB_PORT": "8765"
      },
      "autoApprove": ["interactive_feedback"]
    }
  }
}

然后在本地浏览器打开:http://[远程主机IP]:8765

方案二:SSH 端口转发(传统方法)

  1. 使用默认配置(MCP_WEB_HOST: 127.0.0.1

  2. 设置 SSH 端口转发:

    • VS Code Remote SSH: 按 Ctrl+Shift+P → "Forward a Port" → 输入 8765

    • Cursor SSH Remote: 手动添加端口转发规则(端口 8765)

  3. 在本地浏览器打开:http://localhost:8765

详细解决方案请参考:SSH Remote 环境使用指南

Q: 为什么没有接收到 MCP 新的反馈? A: 可能是 WebSocket 连接问题。解决方法:直接重新刷新浏览器页面。

Q: 为什么没有调用出 MCP? A: 请确认 MCP 工具状态为绿灯。解决方法:反复开关 MCP 工具,等待几秒让系统重新连接。

Q: Augment 无法启动 MCP A: 解决方法:完全关闭并重新启动 VS Code 或 Cursor,重新打开项目。

🔧 一般问题

Q: 如何使用旧版 PyQt6 GUI 界面? A: v2.4.0 版本已完全移除 PyQt6 GUI 依赖。如需使用旧版 GUI,请指定 v2.3.0 或更早版本:uvx gl-mcp-feedback@2.3.0 注意:旧版本不包含新功能(提示词管理、自动提交、会话管理、桌面应用程序等)。

Q: 出现 "Unexpected token 'D'" 错误 A: 调试输出干扰。设置 MCP_DEBUG=false 或移除该环境变量。

Q: 中文字符乱码 A: 已在 v2.0.3 修复。更新到最新版本:uvx gl-mcp-feedback@latest

Q: 多屏幕环境下窗口消失或定位错误 A: 已在 v2.1.1 修复。进入「⚙️ 设置」标签页,勾选「总是在主屏幕中心显示窗口」即可解决。特别适用于 T 字型屏幕排列等复杂多屏幕配置。

Q: 图片上传失败 A: 检查文件格式(PNG/JPG/JPEG/GIF/BMP/WebP)。系统支持任意大小的图片文件。

Q: Web UI 无法启动 A: 检查防火墙设置或尝试使用不同的端口。

Q: UV Cache 占用过多磁盘空间 A: 由于频繁使用 uvx 命令,cache 可能会累积到数十 GB。建议定期清理:

# 查看 cache 大小和详细信息
python scripts/cleanup_cache.py --size

# 预览清理内容(不实际清理)
python scripts/cleanup_cache.py --dry-run

# 执行标准清理
python scripts/cleanup_cache.py --clean

# 强制清理(会尝试关闭相关程序,解决 Windows 文件占用问题)
python scripts/cleanup_cache.py --force

# 或直接使用 uv 命令
uv cache clean

详细说明请参考:Cache 管理指南

Q: AI 模型无法解析图片 A: 各种 AI 模型(包括 Gemini Pro 2.5、Claude 等)在图片解析上可能存在不稳定性,表现为有时能正确识别、有时无法解析上传的图片内容。这是 AI 视觉理解技术的已知限制。建议:

  1. 确保图片质量良好(高对比度、清晰文字)

  2. 多尝试几次上传,通常重试可以成功

  3. 如持续无法解析,可尝试调整图片大小或格式

🙏 致谢

🌟 支持原作者

Fábio Ferreira - X @fabiomlferreira 原始项目: noopstudios/interactive-feedback-mcp

如果您觉得有用,请:

设计灵感

sanshao85 - mcp-feedback-collector

贡献者

penn201500 - GitHub @penn201500

  • 🎯 自动聚焦输入框功能 (PR #39)

leo108 - GitHub @leo108

  • 🌐 SSH 远程开发支持 (MCP_WEB_HOST 环境变量) (PR #113)

Alsan - GitHub @Alsan

  • 🍎 macOS PyO3 编译配置支持 (PR #93)

fireinice - GitHub @fireinice

  • 📝 工具文档优化 (LLM 指令移至 docstring) (PR #105)

社群支援

📄 授权

MIT 授权条款 - 详见 LICENSE 档案

📈 Star History

Star History Chart


🌟 欢迎 Star 并分享给更多开发者!

Available Tools

2 tools
get_system_infoA

获取系统环境信息

Returns: str: JSON 格式的系统信息

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the burden. It states the return type (str in JSON format) but does not disclose any behavioral traits like side effects, permissions, or rate limits. Since it is a simple getter, the lack of negative traits is mildly handled.

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 extremely concise (two sentences) and front-loaded with the purpose. There is no wasted text; every word contributes to understanding the tool's function and output.

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 tool has no parameters and an output schema exists, the description provides sufficient information to understand what the tool does and returns. However, it could be more explicit about the nature of the 'system environment information' and whether it includes sensitive data. Overall, it is minimally complete.

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?

There are no parameters, and the input schema is empty with 100% coverage. According to rules, baseline for 0 parameters is 4. The description adds no param info, but that is acceptable as there are none to describe.

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 retrieves system environment information, using a specific verb 'get' and a resource 'system_info'. It is unambiguous and distinguishes from the sibling 'interactive_feedback' which serves a different purpose.

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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any preconditions or context. The sibling tool is different but not compared.

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

interactive_feedbackA

Open a Web UI to collect interactive feedback from the user.

This tool is the PRIMARY communication channel with the user. Route substantive content (analyses, plans, code summaries, questions needing confirmation) through this tool's summary parameter rather than the Cursor chat, because the Web UI renders Markdown far better.

MANDATORY call scenarios — do NOT end the turn without calling: 1. After any code modification — summarize the change, wait for the user to test. 2. Before implementing a new requirement — explain your understanding and approach, wait for confirmation. 3. When a tool call is cancelled/interrupted — ask the user the next step. 4. When this MCP call times out — immediately re-call; do not assume the user has left. 5. When the user explicitly skips without giving feedback — immediately re-call and ask why they skipped. 6. At the end of any multi-step task stage — check in. 7. Whenever you would otherwise ask the user a question in plain chat — route it through this tool's summary instead.

STRICT PROHIBITIONS: - While this tool is available, DO NOT invoke Cursor's built-in AskQuestion / question-picker tool. Every question to the user MUST go through this tool's summary (ask with a numbered list inside the Markdown). - DO NOT end your turn with a plain-text reply when you still have output intended for the user to read. Put that output into summary and call this tool instead. - Allowed parameters: project_directory, summary, title, timeout. title is OPTIONAL — pass a short headline (≤30 chars) for the Web UI's tab title and summary header. Names such as question, choices, options belong to AskQuestion — NEVER forward them to this tool. Passing any other keyword argument will cause the call to fail schema validation on the server.

Only stop calling when the user explicitly says 结束 / 不用了 / stop / done or an equivalent termination phrase.

summary writing rules: - Write in the same language the user is currently using. - Use Markdown: headings (##), lists, tables, code fences for snippets, bold for key decisions. - Include modified file paths, key trade-offs, and explicit questions for the user when applicable. - NEVER pass an empty string or the placeholder phrase 我已完成了您请求的任务。. The tool rejects such values at runtime and returns a correction notice that you must follow by re-calling with a real summary.

title writing rules: - Optional. Leave empty when summary is self-explanatory. - Keep concise (≤30 chars) — it's a headline, not a sentence. - Use the same language as the user. - Examples: 需要你提供更多信息 / 修复完成,请验证 / 实现方案确认 / Need more context.

Args: project_directory: Absolute or relative project path. Defaults to cwd. summary: Required. Markdown summary of the AI's current work / plan / question. No empty string, no placeholder phrase. title: Optional short headline shown in the Web UI tab and summary header. Leave empty if there's no concise headline. timeout: Seconds to wait for user feedback. Keep >= 600.

Returns: ToolResult: TextContent with the user's text feedback plus MCPImage objects for any uploaded images. An empty result means the user skipped — you MUST re-call this tool to ask why.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_directoryNoProject directory path..
summaryNoMarkdown summary of the AI's current work / plan / question, rendered in the Web UI. MUST be filled in with substantive content; empty strings and placeholder phrases (e.g. "我已完成了您请求的任务。") are rejected at runtime.
titleNoOptional short headline (max ~30 chars) for this feedback round, displayed in the browser tab and at the top of the AI summary panel. Should be concise (e.g. "需要你提供更多信息", "修复完成,请验证"). Leave empty when there's no good headline.
timeoutNoSeconds to wait for user feedback. Keep >= 600.

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries full burden and transparently discloses all behavioral traits: it opens a Web UI, expects user feedback, requires re-calling on skip/timeout, rejects empty strings and placeholder phrases, and validates schema strictly. It also explains return format (TextContent with feedback and images) and failure cases.

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 long but well-structured with headings, numbered lists, and bold for emphasis. It front-loads the core purpose. While every sentence is informative, it could be more concise as some details (e.g., specific failure messages) are verbose. For the high information density, it earns a 4.

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 has 4 parameters and no output schema, the description covers all necessary context: return type (TextContent with feedback images), empty result meaning skip, runtime rejection of empty summary, and schema validation failure on unknown params. It is complete for an interactive feedback tool.

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

Parameters5/5

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

Schema coverage is 100%, yet the description adds significant value: detailed 'summary' writing rules (language, Markdown, what to include, what to avoid), 'title' writing rules (optional, ≤30 chars, examples), 'timeout' minimum (≥600), and a warning against passing 'question'/'choices' etc. It also notes that passing unknown param names causes schema validation failure.

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 opens a Web UI for collecting interactive feedback, and positions it as the PRIMARY communication channel. It distinguishes from the sibling tool 'get_system_info' by its role. The verb 'open' and resource 'Web UI to collect interactive feedback' are specific and unambiguous.

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

Usage Guidelines5/5

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

The description provides extensive, explicit when-to-use and when-not-to-use guidelines. It lists seven mandatory call scenarios, strict prohibitions (e.g., not using AskQuestion or ending with plain text), and a termination condition. It also names the alternative 'AskQuestion' and explicitly instructs to route questions through this tool instead.

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

TDQS

A4.2/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: `get_system_info` retrieves environment information, while `interactive_feedback` collects user feedback via a Web UI. There is no overlap or potential for confusion between them.

Naming Consistency5/5

Both tools follow a consistent `verb_noun` pattern with snake_case: `get_system_info` and `interactive_feedback`. The naming style is uniform and predictable.

Tool Count3/5

With only two tools, the server feels minimal. While the `interactive_feedback` tool is heavily featured, the overall surface may be too narrow for a general-purpose feedback server. A few more utility tools (e.g., `store_feedback`, `configure`) could improve scope.

Completeness4/5

For its stated purpose (collecting user feedback), the tool set is fairly complete. `interactive_feedback` handles all communication and feedback, and `get_system_info` provides context. There is a minor gap in persistence or configuration, but core workflows are covered.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • F
    license
    A
    quality
    C
    maintenance
    MCP server providing feedback-oriented development workflows with a Web UI and desktop application for interactive user confirmation, session tracking, and smart prompt management.
    2
  • F
    license
    A
    quality
    A
    maintenance
    MCP server that establishes feedback-oriented development workflows with dual Web UI and desktop application interfaces, enabling AI to confirm with users via prompts and real-time feedback to reduce speculative operations and improve efficiency.
    2
  • F
    license
    A
    quality
    C
    maintenance
    A feedback-oriented MCP server with a Web UI for AI development workflows, enabling interactive confirmations and reducing speculative tool calls.
    2
    3

Latest Blog Posts

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/teacat99/gl-mcp-feedback'

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