Show HN: Remarc Feedback via MCP
Remarc is metedata's open-source macOS project for leaving contextual feedback that a coding agent can read via MCP. Chat is a clumsy place to point at a sentence, a screenshot, or a UI detail and say exactly what should change. Contextual feedback becomes much more useful when it travels with the thing you saw, but the MCP boundary should start narrow and mostly read-only. For readers tracking AI coding governance, Remarc is a concrete example of guardrails moving closer to the developer's actual review moment.
See the exact thing the agent should fix
Remarc runs from the Mac menu bar and lets you comment on selected text, screenshots, web elements, or voice notes. Remarc is a feedback layer between a human reviewer and an AI coding agent, with the original context attached to each comment.
That sounds small until you try to review agent output in a real product repo. A chat message like change the third paragraph is ambiguous. A comment tied to the exact paragraph, the source app, and the review note is not.
The project documents text, screenshot, web-element and voice feedback in its README. This article evaluates that workflow rather than claiming a hands-on product test.
Watch for to treat contextual feedback as a prettier chat UI. The useful part is not the annotation itself. It is the preserved reference: the quote, screenshot, source app, web context, or recording that keeps the agent from guessing what you meant.
Send comments through MCP, not another inbox
Model Context Protocol, introduced by Anthropic is a standard way for AI clients and agents to connect to external context and tools through servers. In Remarc's case, MCP is the bridge that lets the agent read the feedback instead of forcing the human to retype it into a prompt.
That changes the day-to-day loop. You can review a draft plan, circle a missing hover state, leave a note on awkward copy, and then ask the agent to resolve the open feedback. The agent gets closer to the same evidence you had when you made the comment.
This is especially useful when the target is not only code. A design bug might live in a screenshot. A docs issue might live in a browser selection. A confusing implementation plan might live in a Markdown file or a task tracker. Remarc's bet is that agent feedback should attach to those surfaces directly.
Watch for to assume MCP means write access. It does not have to. An MCP server can expose context, tools, prompts, or resources, and the safe first version of a feedback integration should expose comments as context before it exposes anything that mutates a repository, issue tracker, or production system.
Review agent output without replaying the whole conversation
The strongest use case is the boring one: review. Not code review as a ceremony, but the five-minute pass where you notice the agent misunderstood a sentence, overbuilt a component, or missed a visual state.
Imagine a Codex session in OpenAI's Codex CLI that generated a new onboarding card. The UI mostly works, but the secondary button has no hover state and the help text is too formal. Instead of writing a long prompt, you mark the button in a screenshot, select the sentence in the browser or editor, and leave two short comments.
Then the next Codex prompt can be small:
Read the open Remarc comments through MCP.
Fix only the missing button hover state and the selected help-text sentence.
Run npm test and npm run lint.
Stop and report if the requested change touches auth, billing, migrations, or secrets.
That is a better prompt because it has a boundary. The context comes from Remarc. The scope comes from the human. The verification comes from the repo.
The same pattern shows up in the broader question of whether agentic coding feels more like management than typing. The useful move is not to become vague and managerial; it is to make the handoff concrete enough that the agent can act and the human can verify. That is the thread running through Does AI Coding Feel Like Leadership?, and Remarc gives it a very literal surface.
Keep the first integration narrow
Remarc's interesting idea is context, not autonomy. The first safe boundary is to let the agent read feedback and propose changes, while the repository rules still decide what can be edited and how verification works.
A small repo rule can make that boundary visible:
# AGENTS.md
MCP boundary:
- Treat Remarc comments as review input, not approval.
- Use Remarc context when resolving UI copy, screenshot, and plan-review feedback.
- Do not change auth, billing, migrations, security policy, or secrets from a Remarc note alone.
- After edits, run the repo verification commands and report the exact output in the handoff.
This is the practical line: comments can guide work, but they are not permission slips. A screenshot with a circled button should not let an agent rewrite routing, alter analytics, or touch payments unless the task already asked for that.
The limitation is that context can be sensitive. Screenshots may include customer data. Browser selections may include private docs. Voice notes may capture more than intended. If you wire a tool like this into a coding workflow, the first security question is not whether the agent is clever. It is what feedback objects the MCP server exposes and which clients can read them.
Try it safely with a tiny boundary table
Use Remarc as a small experiment, not as a new command center. Pick one repo, one agent client, and one kind of feedback that is already annoying in chat.
| Decision | Start with | Keep out at first | Why |
|---|---|---|---|
| Feedback source | Selected text and screenshots | Raw private windows and broad desktop capture | The agent needs the reviewed object, not your whole workspace. |
| MCP access | Read comments and attached context | Tools that write files, close tickets, or push commits | Reading feedback is lower risk than acting outside the repo. |
| Repo scope | UI copy, docs, small component fixes | Auth, billing, migrations, secrets, policy files | Visual and wording feedback is where pointing helps most. |
| Verification | Codex CLI runs tests, lint, and a human-readable handoff | Silent edits with no command output | Context helps the agent start; verification proves it finished. |
| Retention | Review history and deletion controls after the task | Permanent archives of every screenshot and recording | Feedback data can be more sensitive than it looks. |
Permission-boundary note to copy:
Remarc MCP permission boundary:
The agent may read Remarc comments and attached context for the current task.
The agent may not treat a Remarc comment as approval to expand scope.
Any change outside the mentioned file, component, or screenshot area needs an explicit human confirmation.
The final response must include files changed, Remarc comments resolved, and verification commands run.
Resolving a comment is a workflow status, not deletion. The current README says deleted comments move into searchable History. Check actual retention and permanent-deletion behavior before capturing sensitive material.
For a hover-state or layout change, render the changed page and inspect the state visually. Passing lint and unit tests alone cannot establish that the screenshot feedback was resolved.
Watch for to start with the hardest workflow. Do not begin with production incident response or large refactors. Start with a hover state, a docs paragraph, or a component screenshot where the feedback object is obvious and the verification loop is cheap.
Further reading
One next step
Try the smallest possible loop: capture one screenshot comment, let the agent read it through MCP, and require the relevant tests plus a visual check before accepting a UI change. If that feels useful, add the AGENTS.md boundary before making the workflow broader.
Editorial update
Updated 20 September 2026: checked the current Remarc workflow, corrected retention advice, and required visual verification.