MCP tools

feedback-mcp is an MCP server named feedback. It gives your agent the comments on your app with the source lines they point at, and lets it resolve them once the change is made. It reads the same comments as your dev server, and works when the dev server is not running, so your agent can read comments after you have stopped working.

Start the server

Run feedback-mcp init inside the app that has the package:

$ npx feedback-mcp init

$ pnpm exec feedback-mcp init

$ yarn feedback-mcp init

$ bunx feedback-mcp init

It prints the command for Claude Code and the JSON for any other client, both pointing at the copy installed in your project:

claude mcp add feedback -- node …/node_modules/@ontrackd/feedback/dist/mcp/cli.js --root …

{ "mcpServers": { "feedback": { "command": "node", "args": ["…/dist/mcp/cli.js", "--root", "…"] } } }

Cursor reads the JSON from .cursor/mcp.json. Do not start the server with npx @ontrackd/feedback: see Troubleshooting.

In a monorepo, run init in any one app. It finds the other apps that use the package and prints one server for all of them, with a --root per app. Add it from the repository root, so paths read as apps/web/src/…. Every tool then takes an optional project to narrow it to one app.

Comments from previews

list_feedback, search_feedback and get_feedback_tasks also fetch what reviewers left on your previews, each time they are called, at most every 20 seconds per app. For that, the app needs its project secret, FEEDBACK_SECRET, read from the environment first, then the app’s .env.local, then .env, then what feedback link saved. Nothing else names the project.

• A fetch that fails is reported at the top of the tool’s answer, and the comments the server already has are still shown.
• With no secret, previews’ comments are not included; when the list comes back empty, the answer says how to add the secret.
• FEEDBACK_CLOUD_SYNC=0 keeps the app local: nothing is fetched.

Connect your agent shows the setup.

list_feedback

The comments, each with the file:line it points at, its component, status and reply count. Read-only.

get_feedback_tasks

The work order, in markdown: a read plan naming the exact line ranges to open, where each change belongs, and the components and styles involved, so your agent does not search the repository. Threads collapse to their latest message. The work order is also saved in .feedback/tasks/. In a monorepo, it returns one work order per app, each saying which directory its paths are relative to.

resolve_feedback

Marks a comment resolved once its change is made. It drops out of list_feedback and future work orders. When the project is linked to the cloud, the dashboard and reviewers see it resolved too.

The server resolves only comments it has shown your agent in a list, a search or a work order, so text inside one comment cannot get others closed. force lifts that check; use it only when you asked for a specific id.

search_feedback

Case-insensitive search for literal text in comments, replies, routes, files, components and authors. It runs on your machine, over the comments the server has, previews’ included. Read-only.

The result says how many comments matched in total, and whether it was cut at limit.

get_feedback_context

The context of each app: its root and directory, the build id, the project id, the Git branch, the session, and whether comments sync to a Cloud project. Secrets are never returned. Read-only.