在视觉小说和 Galgame 中，“Flag”（フラグ）是指一个选择触发新故事分支的时刻。一个决定可以改变一切。
Flag MCP 将同样的力量带到了 AI 辅助编码中。当你的 AI 助手遇到十字路口时，它不会盲目猜测 —— 而是会插下一面旗帜，等待你选择路线。
🎮 你是主角。 AI 会在每一个分支点等待你的指令。
💎 每一面旗帜都决定了路线。 不再需要反复进行推测性的重写。
🚀 丰富的交互。 文本、截图、标注 —— 你的全套工具库。
这让 AI 编码从“祈祷它能运行”转变为由你掌控全局的叙事过程。
适用范围：
按请求计费的编码方案。
希望掌控 AI 行为的开发者。
Related MCP server: Human-In-the-Loop MCP Server
❌ 没有 Flag MCP | ✅ 使用 Flag MCP |
AI 猜测 → 代码错误 → 痛苦的重构 | AI 插旗 → 你来选择 → 代码正确 |
多轮“等等，你是什么意思？”的沟通 | 一次结构化的对话，清晰明了 |
焦虑：“AI 到底要干什么？！” | 自信：每一个动作都由你确认 |
无助的乘客 | 你是路线的制定者 |
🖥️ 深色主题 UI — 适配你工作流的精美原生桌面对话框
✅ 路线选择 — 结构化的预定义选项（复选框样式）
💬 自由文本 — 当预定义路线不够用时，编写你自己的脚本
📷 丰富的媒体工具库
从剪贴板粘贴图像
选择本地文件
截图 + 内置标注工具（矩形、圆形、箭头、画笔、文本、裁剪）
🖼️ 提示图像 — AI 可以向你展示图像（本地路径、file://、http(s)://）
🔒 安全第一 — 远程图像经过验证、大小限制并异步加载
🎨 macOS 优化 — 正确的图标处理和视觉润色
Python >= 3.11
uv (推荐) 或 pip
git clone https://github.com/pauoliva/interactive-feedback-mcp.git
cd interactive-feedback-mcp
uv sync添加到你的 MCP 客户端配置中：
Cursor (mcp.json) / Claude Desktop (claude_desktop_config.json)：
{
"mcpServers": {
"interactive-feedback": {
"command": "uv",
"args": [
"--directory",
"/path/to/interactive-feedback-mcp",
"run",
"server.py"
],
"timeout": 900000,
"autoApprove": ["interactive_feedback"]
}
}
}⚠️ 注意：Cursor 的超时时间单位为毫秒（
900000= 15 分钟）。某些客户端使用秒，请相应调整。
interactive_feedback 工具参数 | 类型 | 描述 |
|
| 要显示的问题/提示 |
|
| 可选。用于快速决策的路线选项 |
|
| 可选。要显示的图像（本地/远程 URL） |
来自用户的文本反馈
可选的图像附件（作为 MCP 图像内容块）
将其添加到你的 AI 助手自定义指令中：
If requirements are unclear, call interactive_feedback before implementing.
Present predefined options whenever possible — give the user clear route choices.
Before finishing a task, call interactive_feedback once more for final confirmation.变量 | 默认值 | 描述 |
|
| UI 进程的最大生命周期 |
| — | 自定义应用图标路径 |
|
| 远程图像获取超时时间 |
|
| 远程图像最大大小 (10MB) |
✅ 远程图像通过内容类型 (image/*) 进行验证
✅ 大负载通过大小上限进行拦截
✅ 异步获取保持 UI 响应
✅ 本地文件仅在明确引用时读取
MIT 许可证 — 随意分叉、插旗、交付。
🚩 插下你的旗帜。书写你自己的路线。
献给那些拒绝在自己的代码库中充当 NPC 的开发者，用心制作 💜。
Request interactive feedback from the user. Supports text and image attachments. 使用方式:
当你通过此工具询问用户时,务必说明需要用户确定的内容。
请在完成用户布置的工作后调用该工具时,提供"结束"的选项,如果用户选择,则本次请求结束. 使用技巧:
请给出可选项,让用户选择,选项中请包涵你最推荐的选项,并说明理由.
针对每个选项,请给出对应的描述,让用户了解每个选项的含义. 什么时候使用:
每当你全部工作完成时，请调用此工具，而非直接结束流程.
每当你遇到需要用户确定的点时(例如进行需求讨论,或者执行任务中遇到重要分岔路口时),务必调用此工具.
| Name | Required | Description | Default |
|---|---|---|---|
| message | No | The specific question for the user | |
| predefined_options | No | Predefined options for the user to choose from (optional) | |
| message_images | No | Image paths to render in the prompt area (optional) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the interaction pattern (blocking request for user input, option-based responses) but lacks technical behavioral traits such as timeout behavior, session persistence, or data handling. It covers 'how to use' but omits 'what happens under the hood' details expected for a user-input tool.
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 uses clear structural headers (Usage method, Usage tips, When to use) but is verbose due to extensive bilingual content. The Chinese examples, while helpful for behavior modeling, make the description longer than necessary for agent consumption, and the language mixing reduces structural coherence.
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 presence of an output schema, the description appropriately focuses on behavioral guidance rather than return values. It comprehensively covers invocation patterns and option structuring, though it would benefit from mentioning timeout handling or error conditions for full completeness.
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?
Schema coverage is 100%, establishing a baseline of 3. The description adds semantic value beyond the schema by specifying in the Chinese text that predefined_options should include a recommended choice with rationale and an 'end' option, providing substantive usage guidance for parameter population that the raw schema lacks.
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 opening sentence clearly states the tool requests interactive feedback and supports text/image attachments. However, the extensive Chinese instructions, while useful, create a bilingual structure that slightly reduces immediate clarity for agents parsing primarily English content.
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 Chinese text under '什么时候使用' (when to use) provides explicit when/when-not guidance, specifically stating to invoke this tool when work is completed instead of directly ending the process, and when encountering decision points requiring user confirmation. It also explicitly references '使用方式' (usage method) and '使用技巧' (usage tips) for detailed alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1interactive_feedbackScored across 1 tool
With only one tool available, there is no ambiguity or risk of tool misselection. The single tool has a clear, distinct purpose that does not overlap with any other tools.
The single tool follows a clear snake_case naming convention. While 'interactive' is an adjective rather than a verb, there are no other tools to create inconsistency, so the naming pattern is uniform.
A single tool is insufficient for the apparent 'Flag' domain suggested by the server name. Even for a minimal utility server, one generic feedback tool represents a severely undersized tool surface that likely cannot fulfill the server's intended purpose.
The server named 'Flag MCP' implies a feature flag or flagging domain, yet provides only a generic user feedback tool with no flag creation, management, querying, or lifecycle operations. This represents a severely incomplete surface for the stated purpose.
Human-in-the-loop for AI coding agents — ask questions, get approvals via Slack.
Give any AI agent a way to ask a person — for approval, a decision, an answer or a review.
Build and edit app screen mockups and clickable prototypes from your AI assistant.
Adaptive plan/build/review cycles for AI coding assistants, persisted across sessions.
