Interactive Feedback MCP
交互式反馈 MCP
由 Fábio Ferreira ( @fabiomlferreira ) 开发。请访问dotcursorrules.com了解更多 AI 开发增强功能。
简单的MCP 服务器,可在Cursor等 AI 辅助开发工具中实现人机交互工作流程。此服务器允许您运行命令、查看其输出,并直接向 AI 提供文本反馈。它还兼容Cline和Windsurf 。


快速工程
为了获得最佳效果,请将以下内容添加到您的 AI 助手中的自定义提示中,您应该将其添加到规则中或直接添加到提示中(例如,光标):
无论何时您想提问,请始终调用 MCP
interactive_feedback。
每当您要完成用户请求时,请调用 MCPinteractive_feedback而不是简单地结束该过程。如果反馈为空,您可以结束请求,并且不要循环调用 mcp。
这将确保您的 AI 助手在将任务标记为完成之前使用此 MCP 服务器来请求用户反馈。
Related MCP server: Spec-driven Development MCP Server
💡为什么要用这个?
通过引导助手与用户进行交互,而不是进行推测性、高成本的工具调用,该模块可以大幅减少 Cursor 等平台上的高级请求(例如 OpenAI 工具调用)数量。在某些情况下,它可以帮助将多达 25 个工具调用合并为一个反馈感知请求,从而节省资源并提高性能。
配置
此 MCP 服务器使用 Qt 的QSettings来存储每个项目的配置。其中包括:
要运行的命令。
是否在该项目下次启动时自动执行该命令(参见“下次运行时自动执行”复选框)。
命令部分的可见性状态(显示/隐藏)(切换时立即保存)。
窗口几何和状态(一般 UI 偏好设置)。
这些设置通常存储在特定于平台的位置(例如,Windows 上的注册表、macOS 上的 plist 文件、Linux 上~/.config或~/.local/share中的配置文件),组织名称为“FabioFerreira”,应用程序名称为“InteractiveFeedbackMCP”,每个项目目录都有一个唯一的组。
用户界面中的“保存配置”按钮主要用于保存当前在命令输入框中输入的命令,以及当前项目“下次运行时自动执行”复选框的状态。切换命令部分的可见性时,系统会自动保存该部分的可见性。常规窗口的大小和位置会在应用程序关闭时保存。
安装(光标)

先决条件:
Python 3.11 或更新版本。
uv (Python 包管理器)。使用以下命令安装:
Windows:
pip install uvLinux/Mac:
curl -LsSf https://astral.sh/uv/install.sh | sh
获取代码:
克隆此存储库:
git clone https://github.com/noopstudios/interactive-feedback-mcp.git或者下载源代码。
导航到目录:
cd path/to/interactive-feedback-mcp
安装依赖项:
uv sync(这将创建一个虚拟环境并安装包)
运行 MCP 服务器:
uv run server.py
在游标中配置:
Cursor 通常允许在其设置中指定自定义 MCP 服务器。您需要将 Cursor 指向此正在运行的服务器。具体机制可能有所不同,因此请参阅 Cursor 的文档以了解如何添加自定义 MCP。
手动配置(例如,通过
mcp.json) 记得将/Users/fabioferreira/Dev/scripts/interactive-feedback-mcp路径更改为您在系统上克隆存储库的实际路径。{ "mcpServers": { "interactive-feedback-mcp": { "command": "uv", "args": [ "--directory", "/Users/fabioferreira/Dev/scripts/interactive-feedback-mcp", "run", "server.py" ], "timeout": 600, "autoApprove": [ "interactive_feedback" ] } } }在 Cursor 中配置时,您可以使用类似
interactive-feedback-mcp服务器标识符。
适用于 Cline / 风帆冲浪
类似的设置原则也适用。您可以在相应工具的 MCP 设置中配置服务器命令(例如, uv run server.py ,并使用正确的--directory参数指向项目目录),并使用interactive-feedback-mcp作为服务器标识符。
发展
要以开发模式运行服务器并使用 Web 界面进行测试:
uv run fastmcp dev server.py这将打开一个 Web 界面并允许您与 MCP 工具进行交互以进行测试。
可用工具
以下是 AI 助手如何调用interactive_feedback工具的示例:
<use_mcp_tool>
<server_name>interactive-feedback-mcp</server_name>
<tool_name>interactive_feedback</tool_name>
<arguments>
{
"project_directory": "/path/to/your/project",
"summary": "I've implemented the changes you requested and refactored the main module."
}
</arguments>
</use_mcp_tool>致谢及联系方式
如果您发现此交互式反馈 MCP 有用,表达赞赏的最好方式是在X @fabiomlferreira上关注 Fábio Ferreira。
如果您有任何问题、建议,或者只是想分享您的使用方式,请随时通过 X 联系!
此外,请访问dotcursorrules.com获取有关增强 AI 辅助开发工作流程的更多资源。
Available Tools
1 toolinteractive_feedbackB
Request interactive feedback for a given project directory and summary
| Name | Required | Description | Default |
|---|---|---|---|
| project_directory | Yes | Full path to the project directory | |
| summary | Yes | Short, one-line summary of the changes |
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 of behavioral disclosure. It fails to explain what 'interactive feedback' entails—whether it blocks, returns data, requires user input, or has side effects. This is insufficient for an agent to understand the tool's behavior.
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 a single, clear sentence with no extraneous information. While concise, it could benefit from additional structure or brevity, but it effectively communicates the core purpose without waste.
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?
The tool has a simple parameter set (2 strings) and no output schema, but the description omits critical context: what does 'interactive feedback' mean? Is feedback returned or is it a blocking interaction? The minimalism leaves an agent guessing about the tool's complete behavior.
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 covers 100% of parameters with descriptions. The tool description merely restates 'project directory and summary', adding no extra meaning. Schema coverage is high, so baseline 3 is appropriate.
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 verb 'Request', the resource 'interactive feedback', and the context 'for a given project directory and summary'. It is specific and unambiguous, leaving no doubt about the tool's core function.
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 by stating 'Request interactive feedback' but provides no explicit guidance on when to use this tool or any alternatives. Since there are no sibling tools, differentiation is not needed, but the description lacks contextual cues for optimal use.
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.
1 tool update
v1.0.0- First observed
interactive_feedback
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion between tools. The single tool 'interactive_feedback' serves a unique purpose.
The single tool name follows a clear verb_noun pattern ('interactive_feedback'), and there are no other names to compare for inconsistency.
The server is dedicated to interactive feedback, and one tool is perfectly scoped for this narrow purpose. Adding more tools would be unnecessary.
For the stated purpose of requesting interactive feedback on a project directory and summary, this single tool fully covers the expected functionality with no obvious gaps.
Maintenance
Related MCP Connectors
MCP server that lets your AI assistant build and deploy apps, hosting each one at a live URL.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
MCP server for building and testing AI agents with multi-model experimentation and insights.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Related MCP Servers
- FlicenseBqualityDmaintenanceMCP server that enables human-in-the-loop workflow in AI-assisted development tools by allowing users to provide direct feedback to AI agents without consuming additional premium requests.11-
- AlicenseBqualityDmaintenanceAn MCP server that enables AI-powered IDEs to implement a structured development workflow from requirements gathering to code implementation, guiding users through goal collection, requirements specification, design documentation, task planning, and execution.96 npm21MIT
- AlicenseCqualityCmaintenanceA Node.js MCP server that enables human-in-the-loop workflow for AI development tools, allowing users to run commands, view output, and provide textual feedback directly to AI assistants.128MIT
- AlicenseAqualityAmaintenanceA feedback-oriented MCP server with a Web UI for AI development workflows, enabling interactive confirmations and reducing speculative tool calls.287 PyPI3MIT