MCP Feedback Enhanced: human checkpoints for long-running AI coding tasks

What problem mcp-feedback-enhanced solves, and for whom

An agent working on a multi-step task has no cheap way to stop and ask a question. It either guesses and keeps going, or it finishes and hands you a diff you have to unpick. This project is an MCP server that gives the agent a tool it can call when it wants input: the call opens a browser page or a desktop window, you pick a prompt, type a reply, optionally attach an image, and the answer goes back over a WebSocket so the agent continues with your correction in hand.

The README is explicit about who this is for and, more usefully, about who it is no longer for. The original project it forks, noopstudios/interactive-feedback-mcp, was sold on consolidating multiple round-trips into a single Cursor request to save quota. The README states that Cursor moved to token-based usage pricing in June 2025, so that premise no longer holds, and points at issues #115 and #200. The positioning now is narrower: insert human checkpoints into long-running tasks. If you were looking for a quota-saving trick, the maintainer has already told you it is not one.

The supported clients are listed as Cursor, Cline, Windsurf, Augment and Trae. The interface is deliberately boring, which is the point: prompt management with usage statistics, a timer that auto-submits after a configurable delay, session history stored locally, and image upload by drag-and-drop or clipboard paste. Nothing here is trying to be an IDE.

How the feedback loop actually works

The flow is a loop between the MCP client and a local server. The agent calls the mcp-feedback-enhanced tool. The server launches an interface, either the browser Web UI or the Tauri desktop application, depending on configuration. You interact with it: choose a prompt, type text, attach an image, or let the auto-submit timer fire. A WebSocket connection carries that response back to the agent, which then adjusts its behaviour or ends the task. Sessions and statistics are written to local files along the way.

The architectural decision worth noticing is that the desktop application is a Tauri shell loading the same Web UI. The README says both interfaces provide exactly the same functional experience, and that the Web UI is the primary maintained interface. That is a sensible split for remote work: a browser page needs no GUI stack, so it survives SSH sessions and WSL, while the desktop shell exists for people who want a native window on Windows, macOS or Linux.

Since v2.8.0 the desktop application is maintenance-only, with no new features, and the README says it is scheduled for removal in v3. That is a real signal about where effort goes. If you are choosing an interface today, choose the Web UI.

The dependency list in pyproject.toml is pinned with upper bounds, and the comment above it explains why: fastmcp 4 depends on mcp>=2,<3, so the two must be upgraded together or resolution fails, and a Starlette TemplateResponse signature change previously caused the Web UI to return 500. The verified combination recorded there is fastmcp 4.0.3, mcp 2.1.1, fastapi 0.141.1, starlette 1.6.0, uvicorn 0.52.4, jinja2 3.1.6 and websockets 17.0.1. Python 3.11 or newer is required.

Installing mcp-feedback-enhanced and running a first session

The README gives uvx as the way to run it, which means no clone and no virtualenv of your own. The maintenance notice tells existing users to upgrade to v2.6.1 or later, and shows this exact command:

uvx mcp-feedback-enhanced@latest

Running it starts the server. You then point your MCP client at it. The repository ships two example configuration files, examples/mcp-config-web.json and examples/mcp-config-desktop.json, one per interface. The Web UI example is the one to copy if you are on a remote host, since it does not need a GUI.

{
  "mcpServers": {
    "mcp-feedback-enhanced": {
      "command": "uvx",
      "args": ["mcp-feedback-enhanced@latest"]
    }
  }
}

After the client restarts and loads the server, ask the agent to call the feedback tool. What you should see is a browser page opening on the local machine, with a prompt selector, a text box, an image drop area and a submit control. Type a reply and submit it; the agent should continue from that point rather than restarting the task.

For development work rather than use, the repository has a Makefile. The targets listed in its help output include install, install-dev, install-hooks, lint, format, type-check, test, test-cov, test-fast, test-func, test-web and test-desktop-func. If you are only consuming the server, you do not need any of them.

The command-execution removal is the reason to pin a version

Version 2.6.1 removed command execution entirely, and the README explains the reasoning in unusual detail. Issue #219 covered an unauthenticated WebSocket that could execute arbitrary programs. The old blocklist only caught shell metacharacters, but because execution used shell=False, metacharacters were never the risk: cat, curl, wget and python passed straight through, and auto-command was enabled by default. The feature is gone for good, and SECURITY.md is cited as the reference.

The same release fixed cross-site WebSocket hijacking, reported privately as GHSA-cmr5-gpm3-79vf and GHSA-2wx7-r4rh-f663. Browsers are not restricted by the same-origin policy when opening a WebSocket, so a malicious page could make your browser connect to the local /ws endpoint. Origin is now validated before accept(), and cross-origin attempts are rejected with 403. Two other fixes landed alongside: the Starlette breaking change that made the Web UI return 500, tracked across issues #213, #217, #221 and #228, and image serialization, fixed by switching to standard mcp.types.ImageContent.

Practically, this means the version you install is a security decision, not a preference. Anything before v2.6.1 carries the unauthenticated execution path. The maintenance notice states the current scope plainly: security issues, and compatibility breaks that make installs unusable. Feature requests are decided from community feedback in the pinned discussion. Read that as a project that will keep your install working but will not grow new capabilities on request.

Where mcp-feedback-enhanced is the wrong tool

The README makes an argument against itself that is worth taking seriously. MCP clients now natively support Elicitation, server-initiated requests for user input, and MCP Apps, tools that return interactive UI. If native capabilities cover your needs, the README says to just use those. That is not marketing hedging; it is the maintainer telling you the built-in path may be sufficient.

The second limitation is the maintenance scope. Security fixes and install-breaking compatibility breaks are in scope. Everything else waits on community demand. A project in that mode will not add a new interface, a new storage backend or a new client integration because one team asked. The Desktop application is already frozen and slated for removal in v3.

The third is dependency fragility. The pyproject.toml comment records that fastmcp 4 requires mcp>=2,<3 and the pair must move together, and that a Starlette signature change once broke the Web UI outright. Upper bounds protect you from upstream breakage, but they also mean you are pinned to a tested combination rather than tracking the ecosystem. The package is classified as Development Status 4 - Beta in pyproject.toml.

Finally, the tool is a checkpoint mechanism, not an automation mechanism. If your goal was to let the agent run commands on your behalf through this server, that capability was deliberately deleted.

Alternatives and how they differ in approach

The most direct alternative is the project this one forks: noopstudios/interactive-feedback-mcp, credited in the README as the original by Fábio Ferreira. The difference is scope of maintenance rather than concept. The fork exists because the original's premise, batching Cursor requests to save quota, stopped applying when Cursor moved to token-based pricing in June 2025. Choosing the original means choosing the codebase that did not go through the v2.6.1 security work described in this fork's README.

The second alternative is not a competing server at all: it is your MCP client's own Elicitation and MCP Apps support. The mechanism differs in where the UI comes from. Elicitation is the client rendering the prompt; mcp-feedback-enhanced is a separate local server rendering its own page and pushing the answer back over WebSocket. The native route has no extra process, no port and no dependency pinning, but you get whatever UI the client decides to provide, with no prompt library, no session history export to JSON, CSV or Markdown, and no auto-submit timer.

The third is UI design reference sanshao85/mcp-feedback-collector, cited in the README. The README credits it for UI design rather than describing it as a functional replacement, so treat it as a source of interface ideas rather than a drop-in swap.

If you need the prompt library, the local session history and the timer, the separate server earns its process. If you need a single question answered mid-run, the client's native path is less machinery.

Licence, upgrade cost and what to check before adopting

pyproject.toml declares an MIT classifier, License :: OSI Approved :: MIT License, and the repository has a LICENSE file at the top level. GitHub reports the licence as NOASSERTION, which means its detector could not match the file to a known template. The two are not necessarily in conflict, but they are not the same statement either, and only the LICENSE file itself settles what terms apply. That is a question for whoever handles licensing where you work, not something to infer from a classifier string.

Upgrade cost is low if you stay on the uvx path. The README's instruction is a single command with @latest, and the maintenance scope is defined around keeping installs working. The cost shows up when upstream moves: the pinned combination in pyproject.toml means a fastmcp or mcp major bump has to be handled by the maintainer before you can take it, and the comment records that the two must be upgraded together. A Starlette signature change already caused a Web UI 500 once.

Before adopting, verify three things. That your client is one of Cursor, Cline, Windsurf, Augment or Trae, since those are the listed platforms. That the version you install is v2.6.1 or later, because earlier versions carry the unauthenticated command-execution path. And that you are comfortable with the Web UI being the long-term interface, since the Desktop application is maintenance-only from v2.8.0 and scheduled for removal in v3.

Editorial conclusion

Adopt it if you run long agent tasks in Cursor, Cline, Windsurf, Augment or Trae and want a browser-based checkpoint that works over SSH and WSL. Skip it if native Elicitation or MCP Apps already gives your client the prompt-and-answer loop you need, and skip it if you wanted the old auto-command execution: that code was removed in v2.6.1 and the README says the feature is gone for good. Before installing, confirm your client supports MCP servers at all, then run uvx mcp-feedback-enhanced@latest and check the version string, because anything older than v2.6.1 still carries the unauthenticated WebSocket command-execution path described in SECURITY.md. Expect the Desktop shell to disappear in v3, so build your workflow around the Web UI.

Frequently asked questions

Official sources

1. Issues
2. Minidoracat/mcp-feedback-enhanced on GitHub
3. README
4. Releases