MCP servers for customer feedback: what they are for
What MCP changes about the gap between a user bug report and a fix, and what a feedback MCP server should and should not expose.
Most of the MCP servers people install connect an agent to a system that agent already had an API for. A feedback MCP server is more interesting than that, because the thing it removes is not an API call — it is you, sitting in the middle, retyping.
The copy-paste tax
The current workflow for fixing a user-reported bug with an AI coding assistant is remarkably manual. You open the report. You copy the description. You copy the stack trace. You add the browser, because the model cannot see your other tab. You describe the steps in your own words, which introduces exactly the reconstruction error the automatic capture was meant to remove.
Then the agent starts work — on your summary of the evidence, not the evidence.
What MCP actually changes
Model Context Protocol is a standard way for an AI client to call tools and read data from an outside system. In practice it means the agent asks for the report itself, and gets the whole thing: description, reporter, page, browser and viewport, the exceptions with their stack frames, the numbered steps, a screenshot link.
The agent is now working from the same artifact you would have read, without a lossy step in between. That is the entire pitch, and it is enough.
What a feedback MCP server should expose
Three tools is roughly the right number, and the constraint is worth being deliberate about — this is a system that talks to your customers.
List. Reports newest first, filtered by type, status, age and free text. One line each, so an agent can scan a week without spending its context on twenty full reports.
Read one. The complete report from a short reference. This is where the value is: everything the browser captured, in one call.
Change status. Narrow, permission-checked, and quiet by default. Moving a report to completed is a reasonable thing for an agent to do after landing a fix. Emailing the customer about it is not something that should happen as a side effect.
What it should not expose
No tool that deletes anything. No tool that sends mail unless explicitly asked. No tool that can reach a project the connection was not scoped to — put the project in the endpoint URL rather than in an argument, and the question of an agent addressing the wrong project stops existing.
And permissions should be the same ones the dashboard applies. If a member cannot change a status by hand, the tool that changes statuses should not be registered for them at all: an agent that is never offered a capability plans better than one that is refused halfway through.
OAuth, not an API key
Most MCP servers ask you to paste a token into a JSON file. That file then wants to be in .gitignore, which means it cannot be shared with your team, which means everyone configures it separately and one of them commits it anyway.
Browser-based authorisation avoids the whole category. The config contains a URL and nothing secret, the approval happens once, and the agent acts as you with exactly your permissions.
Where this goes
The interesting property is not that an agent can read a bug report. It is that the report was assembled by the browser at the moment of failure, which makes it a far better input than anything a human writes after the fact.
Automatic capture and agent-readable output are the same idea seen from two ends: keep the evidence intact from the moment it exists to the moment something acts on it, and remove every place a person has to retype it in between.