MCP Feedback Collector
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@MCP Feedback Collectorcollect feedback on my latest UI design mockup"
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反馈收集器
一个现代化的 Model Context Protocol (MCP) 服务器,为AI助手提供交互式用户反馈收集功能。
在cursor规则中可以下面这样配置
"Whenever you want to ask a question, always call the MCP .
Whenever you're about to complete a user request, call the MCP instead of simply ending the process. Keep calling MCP until the user's feedback is empty, then end the request. mcp-feedback-collector.collect_feedback "
Related MCP server: Enhanced Interactive Feedback MCP Server
✨ 主要特性
🎨 现代化界面 - 美观的700x800像素GUI,支持中文界面
📷 多图片支持 - 同时选择多张图片,支持文件选择和剪贴板粘贴
💬 灵活反馈 - 支持纯文字、纯图片或文字+图片组合反馈
⚡ 零配置安装 - 使用uvx一键安装,无需复杂配置
🔧 智能超时 - 可配置的对话框超时时间,避免操作中断
🚀 快速开始
1. 安装uvx
pip install uvx2. 配置Claude Desktop
在 claude_desktop_config.json 中添加:
{
"mcpServers": {
"mcp-feedback-collector": {
"command": "uvx",
"args": ["mcp-feedback-collector"],
"env": {
"PYTHONIOENCODING": "utf-8",
"MCP_DIALOG_TIMEOUT": "600"
}
}
}
}3. 重启Claude Desktop
配置完成后重启Claude Desktop即可使用。
🧪 快速验证页面修改效果
修改代码后,可以通过以下三种方式快速验证界面效果:
方法1:直接运行服务器(推荐)
# 安装依赖
pip install fastmcp pillow
# 直接运行主服务器
python -m mcp_feedforward.server
# 或者运行测试脚本
python -c "
from mcp_feedforward.server import collect_feedback
result = collect_feedback('🎨 界面测试', 30)
print(f'测试完成,收集到 {len(result)} 项反馈')
"方法2:使用测试工具验证GUI
# 运行单独的GUI测试
python -c "
import tkinter as tk
from mcp_feedforward.gui import FeedbackDialog
root = tk.Tk()
root.withdraw()
dialog = FeedbackDialog(
work_summary='🎨 GUI界面测试\n\n测试当前的界面效果和功能',
timeout_seconds=60
)
result = dialog.run()
print('测试结果:', result)
"方法3:模拟MCP调用环境
# 模拟完整的MCP环境
python -c "
import sys
import asyncio
from mcp_feedforward.server import app
# 模拟工具调用
async def test_mcp():
tools = app.list_tools()
print('可用工具:', [tool.name for tool in tools])
# 测试collect_feedback工具
result = await app.call_tool('collect_feedback', {
'work_summary': '🧪 MCP环境测试',
'timeout_seconds': 30
})
print('MCP测试结果:', result)
asyncio.run(test_mcp())
"🐛 本地MCP调试完整指南
步骤1:设置开发环境
# 克隆项目
git clone https://github.com/your-repo/mcp-feedback-collector.git
cd mcp-feedback-collector
# 创建虚拟环境
python -m venv venv
source venv/bin/activate # Linux/Mac
# 或者 venv\Scripts\activate # Windows
# 安装开发依赖
pip install -e .
pip install fastmcp pillow步骤2:配置本地MCP服务器
创建本地配置文件 local_claude_config.json:
{
"mcpServers": {
"mcp-feedback-collector-dev": {
"command": "python",
"args": ["-m", "mcp_feedforward.server"],
"cwd": "/path/to/your/project",
"env": {
"PYTHONPATH": "/path/to/your/project",
"PYTHONIOENCODING": "utf-8",
"MCP_DEBUG": "true",
"MCP_DIALOG_TIMEOUT": "300"
}
}
}
}步骤3:启用调试模式
# 设置调试环境变量
export MCP_DEBUG=true
export PYTHONPATH=$PWD
# 运行调试服务器
python -m mcp_feedforward.server --debug
# 或者使用详细日志
python -m mcp_feedforward.server --log-level DEBUG步骤4:使用MCP Inspector调试
# 安装MCP Inspector
npm install -g @modelcontextprotocol/inspector
# 启动Inspector
mcp-inspector python -m mcp_feedforward.server
# 在浏览器中访问 http://localhost:5173
# 测试所有MCP工具功能步骤5:实时代码调试
在VS Code中创建 .vscode/launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "Debug MCP Server",
"type": "python",
"request": "launch",
"module": "mcp_feedforward.server",
"console": "integratedTerminal",
"env": {
"PYTHONPATH": "${workspaceFolder}",
"MCP_DEBUG": "true"
},
"args": ["--debug"]
}
]
}📦 打包发布完整指南
阶段1:准备发布环境
# 更新版本号
# 编辑 pyproject.toml 中的 version
# 清理旧的构建文件
rm -rf dist/ build/ *.egg-info/
# 安装构建工具
pip install build twine阶段2:构建发布包
# 构建源码包和wheel包
python -m build
# 验证构建结果
ls dist/
# 应该看到:
# mcp_feedback_collector-2.0.0-py3-none-any.whl
# mcp_feedback_collector-2.0.0.tar.gz
# 检查包内容
twine check dist/*阶段3:测试安装包
# 在新环境中测试安装
python -m venv test_env
source test_env/bin/activate
# 从本地包安装
pip install dist/mcp_feedback_collector-2.0.0-py3-none-any.whl
# 测试安装结果
python -c "
from mcp_feedforward.server import collect_feedback
print('✅ 安装测试成功')
"阶段4:发布到PyPI
# 发布到测试PyPI(推荐先测试)
twine upload --repository testpypi dist/*
# 从测试PyPI安装验证
pip install -i https://test.pypi.org/simple/ mcp-feedback-collector
# 发布到正式PyPI
twine upload dist/*
# 验证正式发布
pip install mcp-feedback-collector🔄 多种安装方式完整指南
方式1:uvx安装(推荐,零配置)
# 安装uvx
pip install uvx
# 一键安装和使用
uvx mcp-feedback-collector
# Claude Desktop配置
{
"mcpServers": {
"mcp-feedback-collector": {
"command": "uvx",
"args": ["mcp-feedback-collector"]
}
}
}方式2:pip全局安装
# 全局安装
pip install mcp-feedback-collector
# Claude Desktop配置
{
"mcpServers": {
"mcp-feedback-collector": {
"command": "python",
"args": ["-m", "mcp_feedforward.server"]
}
}
}方式3:pipx隔离安装
# 安装pipx
pip install pipx
# 使用pipx安装
pipx install mcp-feedback-collector
# Claude Desktop配置
{
"mcpServers": {
"mcp-feedback-collector": {
"command": "pipx",
"args": ["run", "mcp-feedback-collector"]
}
}
}方式4:conda环境安装
# 创建conda环境
conda create -n mcp-feedback python=3.9
conda activate mcp-feedback
# 安装包
pip install mcp-feedback-collector
# Claude Desktop配置(需指定conda路径)
{
"mcpServers": {
"mcp-feedback-collector": {
"command": "/path/to/conda/envs/mcp-feedback/bin/python",
"args": ["-m", "mcp_feedforward.server"]
}
}
}方式5:Docker容器安装
# Dockerfile
FROM python:3.9-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
RUN pip install -e .
EXPOSE 8000
CMD ["python", "-m", "mcp_feedforward.server"]# 构建和运行
docker build -t mcp-feedback-collector .
docker run -p 8000:8000 mcp-feedback-collector
# Claude Desktop配置(网络模式)
{
"mcpServers": {
"mcp-feedback-collector": {
"command": "curl",
"args": ["-X", "POST", "http://localhost:8000/mcp"]
}
}
}方式6:源码开发安装
# 克隆源码
git clone https://github.com/your-repo/mcp-feedback-collector.git
cd mcp-feedback-collector
# 开发模式安装
pip install -e .
# 或使用poetry
poetry install
poetry shell
# Claude Desktop配置
{
"mcpServers": {
"mcp-feedback-collector": {
"command": "python",
"args": ["-m", "mcp_feedforward.server"],
"cwd": "/path/to/mcp-feedback-collector"
}
}
}🛠️ 核心功能
collect_feedback()
收集用户反馈的主要工具,AI可以汇报工作内容,用户提供文字和图片反馈。
# AI调用示例
result = collect_feedback("我已经完成了代码优化工作...")pick_image()
快速图片选择工具,用于单张图片选择场景。
get_image_info()
获取图片文件的详细信息(格式、尺寸、大小等)。
🖼️ 界面预览
🎯 工作完成汇报与反馈收集
┌─────────────────────────────────────────┐
│ 📋 AI工作完成汇报 │
│ ┌─────────────────────────────────────┐ │
│ │ [AI汇报的工作内容显示在这里] │ │
│ └─────────────────────────────────────┘ │
└─────────────────────────────────────────┘
┌─────────────────────────────────────────┐
│ 💬 您的文字反馈(可选) │
│ ┌─────────────────────────────────────┐ │
│ │ [多行文本输入区域] │ │
│ └─────────────────────────────────────┘ │
└─────────────────────────────────────────┘
┌─────────────────────────────────────────┐
│ 🖼️ 图片反馈(可选,支持多张) │
│ [📁选择文件] [📋粘贴] [❌清除] │
│ [图片缩略图预览区域] │
└─────────────────────────────────────────┘
[✅ 提交反馈] [❌ 取消]⚙️ 配置说明
超时设置
MCP_DIALOG_TIMEOUT: 对话框等待时间(秒)默认:300秒(5分钟)
建议:600秒(10分钟)
复杂操作:1200秒(20分钟)
支持的图片格式
PNG、JPG、JPEG、GIF、BMP、WebP
💡 使用场景
✅ AI完成任务后收集用户评价
✅ 收集包含截图的详细反馈
✅ 获取用户对代码/设计的意见
✅ 收集bug报告和改进建议
🔧 技术栈
MCP框架: FastMCP
GUI: tkinter + PIL
多线程: threading + queue
图片处理: Pillow
📝 更新日志
v2.0.0 (2025-05-28)
🎨 全新现代化UI设计
📷 多图片同时提交支持
🖼️ 横向滚动图片预览
💫 彩色按钮和图标
🔧 优化用户体验
📄 许可证
MIT License - 详见 LICENSE 文件
🤝 贡献
欢迎提交Issue和Pull Request!
让AI与用户的交互更高效直观! 🎯
Available Tools
3 toolscollect_feedbackA
收集用户反馈的交互式工具
AI可以汇报完成的工作内容,用户可以提供文字和/或图片反馈
Args:
work_summary: AI完成的工作内容汇报
timeout_seconds: 对话框超时时间(秒),默认300秒(5分钟)
Returns:
包含用户反馈内容的列表,可能包含文本和图片
| Name | Required | Description | Default |
|---|---|---|---|
| work_summary | No | ||
| timeout_seconds | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the interactive dialog behavior with timeout functionality and mentions that feedback may include text and images. However, it doesn't address important behavioral aspects like authentication requirements, rate limits, error conditions, or what happens when timeout occurs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with clear sections (purpose, args, returns). Each sentence adds value, though the structure could be slightly more front-loaded by moving the purpose statement before the bilingual formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an interactive feedback collection tool with 2 parameters, no annotations, and no output schema, the description provides adequate basic information but lacks details about the interactive dialog implementation, error handling, or what specific format the returned feedback list contains. It's minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides meaningful semantic context for both parameters: work_summary is explained as 'AI完成的工作内容汇报' (AI's work completion report) and timeout_seconds as '对话框超时时间' (dialog timeout time) with default value context. This compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '收集用户反馈的交互式工具' (collect user feedback interactive tool) and specifies that AI can report completed work while users can provide text and/or image feedback. This is a specific verb+resource combination, though it doesn't explicitly differentiate from sibling tools like get_image_info or pick_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('AI可以汇报完成的工作内容' - AI can report completed work content) and mentions the interactive dialog nature, but provides no explicit guidance on when to use this tool versus alternatives or any exclusion criteria. The usage is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_image_infoB
获取指定路径图片的信息(尺寸、格式等)
Args:
image_path: 图片文件路径
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it implies a read-only operation ('get information'), it doesn't specify whether this requires file system access, what happens with invalid paths, error conditions, or performance characteristics. The description adds minimal behavioral context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences: one stating the purpose and another documenting the parameter. The structure is clear and front-loaded with the main functionality, though the Chinese-to-English translation creates minor redundancy in the parameter documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read operation with no output schema, the description provides adequate basic information about what the tool does and what parameter it requires. However, it lacks details about return values, error handling, and behavioral constraints that would be helpful given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly documents the single parameter 'image_path' and its purpose ('图片文件路径' meaning 'image file path'), adding meaningful semantics beyond the schema which has 0% description coverage. This fully compensates for the schema gap for this single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '获取指定路径图片的信息(尺寸、格式等)' translates to 'Get information about the specified image path (dimensions, format, etc.)'. This provides a specific verb ('get information') and resource ('image'), though it doesn't explicitly differentiate from sibling tools like 'pick_image'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'pick_image' or 'collect_feedback'. It simply states what the tool does without context about appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pick_imageB
弹出图片选择对话框,让用户选择图片文件或从剪贴板粘贴图片。 用户可以选择本地图片文件,或者先截图到剪贴板然后粘贴。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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 describes the tool's behavior as popping up a dialog for user interaction, which is useful. However, it doesn't disclose critical traits like whether this is a blocking operation, what happens on user cancellation, error handling, or UI constraints (e.g., supported image formats). For a user-interactive tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: two sentences that clearly state the tool's function and user options. Every sentence adds value without redundancy, making it front-loaded and easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (user-interactive dialog) and lack of annotations or output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., image data, file path, or error), how it handles edge cases, or any dependencies. For a tool with no structured data to supplement, this leaves key contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description appropriately doesn't discuss parameters, which is efficient. Baseline is 4 for 0 parameters, as it avoids unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '弹出图片选择对话框,让用户选择图片文件或从剪贴板粘贴图片' (pop up an image selection dialog to let users choose image files or paste from clipboard). It specifies the action (pop up dialog) and resource (image files/clipboard images), though it doesn't explicitly differentiate from sibling tools like 'get_image_info' or 'collect_feedback'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning '用户可以选择本地图片文件,或者先截图到剪贴板然后粘贴' (users can choose local image files or first screenshot to clipboard then paste), suggesting when to use it for image input. However, it lacks explicit guidance on when to use this vs. alternatives like 'get_image_info' (which might retrieve image metadata) or 'collect_feedback' (which might involve user input beyond images).
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.
3 tool updates
- First observed
collect_feedback - First observed
get_image_info - First observed
pick_image
TDQS
Scored across 3 tools
The three tools have distinct primary purposes—collecting feedback, getting image info, and picking an image—but there is some overlap between get_image_info and pick_image since both handle images. An agent might occasionally misselect between them when the task involves image processing, though their descriptions clarify the difference.
The tool names follow a consistent verb_noun pattern (collect_feedback, get_image_info, pick_image), which is clear and predictable. There are no deviations in naming style, making it easy for an agent to parse and understand the tool functions.
With only 3 tools, the server feels thin for a 'Feedback Collector' domain, as it lacks tools for managing or analyzing feedback (e.g., list_feedback, delete_feedback). However, the tools cover basic collection and image handling, so it's borderline but not severely lacking.
The server is incomplete for its stated purpose of collecting feedback. It provides tools to collect and handle images but lacks essential operations like storing, retrieving, or summarizing feedback. This creates significant gaps that could cause agent failures in feedback management workflows.
Maintenance
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
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
An MCP server that automatically collects feedback on your MCP server.
MCP server for building and testing AI agents with multi-model experimentation and insights.
A Model Context Protocol server for Wix AI tools
Related MCP Servers
- AlicenseBqualityDmaintenanceA powerful MCP server that provides interactive user feedback and command execution capabilities for AI-assisted development, featuring a graphical interface with text and image support.144MIT
- AlicenseBqualityDmaintenanceAn advanced MCP server that provides interactive feedback mechanisms with support for various feedback types, multi-language capabilities, and team collaboration features for AI tools like Cursor, Cline, and Windsurf.41MIT
- -licenseBqualityNot gradedmaintenanceA Model Context Protocol server that enables AI assistants to request user feedback at critical points during interactions, improving communication and reducing unnecessary tool calls.13-
- AlicenseAqualityCmaintenanceA lightweight MCP server that enables AI assistants to collect interactive user feedback via a browser window with full Markdown rendering and syntax highlighting.11613MIT