An MCP server for user feedback connects your coding agent to the bug reports your users filed. The tools matter less than what they return when called. Most tools hand the agent a ticket title and a status. That is not enough to do anything useful.
This is what a user feedback MCP server should give the agent, how trust levels control what it can change, and how to start without granting more access than you need.
What "user feedback MCP" means
Two things use this name and they are not the same.
The first is "human in the loop MCP" (an MCP server that pauses agent execution mid-task to ask a human for confirmation). That is about agent safety, not feedback collection.
The second is what this post covers: an MCP server that gives a coding agent access to feedback submitted by your app's users. The agent can read reports, fetch the context around each one, and take actions on the inbox rather than waiting for someone to copy a Slack message into a prompt.
Both are valid. If you searched "user feedback MCP" looking for a way to pause and ask your users a question mid-agent-run, that is not what Quell or its competitors cover.
If you searched because your coding agent cannot see the bug reports sitting in your feedback inbox, read on.
What the agent should get
The value of a feedback MCP server is not the tool count. It is what the get_context tool (or its equivalent) returns.
A report that arrives as "the export button is broken" is useless to a coding agent. It cannot DM the user. It has no console, no request, no page URL. The agent will guess.
A report with the following is actionable:
- The user message
- The page URL and title at submission time
- Recent console output, including the full error and stack trace
- The failed network request with its status code
- A screenshot
Quell's quell_get_context tool returns this as structured Markdown from GET /api/feedback/:id/context. Here is what the agent reads (representative shape, not a specific customer incident):
The export button dies when I choose the last 30 days.
## Triage - Status: Open - Priority: High - Trust: identified
## Source - Page: https://app.example.com/reports?period=last_30d
## Console - [error] TypeError: Cannot read properties of undefined at ExportButton.handleClick (reports.js:284)
## Network - POST https://app.example.com/api/reports/export -> 500 (183ms)
The agent now has a concrete lead: a TypeError at reports.js:284 alongside a POST returning 500. That is enough to open the right file and test a hypothesis instead of guessing from the user's one sentence.
If your chosen MCP server does not return something close to this shape, the agent is working with a ticket title. Check what get_context actually returns before deciding the connection is useful.
Starting with read-only
Do not grant write permissions on the first connection. Start with feedback:read and confirm the context packets are genuinely useful before adding anything else.
Quell exposes scoped keys:
- <code>feedback:read</code>: list feedback and fetch context. Nothing changes in the inbox.
- <code>feedback:comment</code>: add an activity comment to an item. Visible to humans, not sent to the user.
- <code>feedback:write</code>: update triage fields (status, priority, assignee, category).
- <code>feedback:integrations</code>: create or link a GitHub or Linear issue.
An admin key is not required for any of this.
Trust levels control what routes automatically. Public feedback (no account, no identity) waits for human review by default. Identified users and trusted reporters carry more provenance. Agent and admin submissions come from managed credentials. None of that changes who can read the feedback; it controls what happens to it downstream.
Start with the read-only prompt:
If the summaries are useful, the connection is working. Add permissions one step at a time from there. The full trust model is in Why feedback trust levels matter for safe agent automation.
The category today
Several tools now market themselves as "MCP server for user feedback" or position around the same cluster.
Marker.io shipped an MCP server in March 2026. It surfaces developer-facing bug reports: screenshots, console logs, network requests from a Marker issue URL. Strong context quality, especially for internal QA workflows. The conversion path is "your agent can auto-resolve stale issues," which is the developer-team use case. If your users are developers filing issues through a browser extension, Marker is the most mature option in the category.
Quackback (Show HN, February 2026) is open-source and ships with a built-in MCP server for customer feedback: full read/write access to feedback from Claude Code or Cursor. The HN thread is the clearest evidence that demand for this specific thing exists. Worth watching, especially if you want to self-host the whole loop.
FasterFixes positions as a Marker alternative with its own MCP server, returning agent-readable Markdown repro bundles.
Quell covers the end-user feedback case (feedback submitted by your app's users, not your team), with a trust-level model that routes reports by their source provenance, flat seats at $4/seat, and no token tax. The MCP server is currently not an npm package; it runs from a built Quell checkout. The agents page lists all ten MCP tools.
None of these is wrong. They are targeting different points in the same pipeline: Marker for the dev-team bug workflow, Quackback for open-source customer feedback, Quell for the structured end-user-to-agent loop with routing controls.
The useful question is not "which one has an MCP server?" but "what does the agent actually get when it calls get_context?"
Frequently asked questions
What is the difference between a user feedback MCP and a human-in-the-loop MCP?
A user feedback MCP gives a coding agent access to feedback submitted by your app's users: bug reports, feature requests, and support queries. A human-in-the-loop MCP pauses agent execution mid-task to ask a human for a decision. The names are similar but the use cases are different. Quell is the former.
Does the MCP server need admin access?
No. A scoped API key with feedback:read is enough to list feedback and fetch full context. Write operations use separate scopes. An admin key is never required.
Which coding agents support MCP?
Claude Code, Claude Desktop, Cursor, VS Code (via the MCP extension), and Windsurf all support MCP stdio servers. The free MCP config generator writes the correct JSON for whichever client you use.
Is my feedback data used to train models?
Quell has no built-in AI. It captures, stores, routes, and exports feedback. Your chosen coding agent does the model work on your account and your tokens. The feedback data stays on your Quell instance. See No token tax: why Quell ships zero mandatory AI.
How is this different from just giving the agent a Slack message?
A copied Slack message loses the evidence that existed when the user hit the bug: the console error, the failed request, the page URL, the screenshot. The Quell widget captures that context automatically at submission time and keeps it attached to the report. The agent reads it as structured Markdown, not a transcribed conversation.