Igor Yussupov
A bug report that says "the export is broken" gives a coding agent nothing to work with. A report that carries the element, the console error and the failing request gives it the same material a developer would open DevTools to find. This walkthrough shows how a bug that a client reported gets fixed from Cursor or Claude Code over MCP: connecting once, asking the agent to fix a bug by its key, reviewing the change, and closing the loop so the client hears it is fixed.
The bug used below, SHOP-142, is an example, not a real customer report. The tools and commands are the ones SnagRelay documents.
Connect your agent once
The SnagRelay MCP server is at https://mcp.snagrelay.com/v1. You sign in through the browser; there is no token to copy. Add it to your agent:
- Cursor: use the Add to Cursor button, or add the URL as a remote MCP server.
- Claude Code: run
claude mcp add --transport http snagrelay https://mcp.snagrelay.com/v1, then run/mcpand choose Authenticate. - Codex: run
codex mcp add snagrelay --url https://mcp.snagrelay.com/v1, thencodex mcp login snagrelay.
Your agent opens a SnagRelay page in the browser. Sign in and click Allow. MCP is included on every plan, including Free. The MCP server page has the full list of tools and the install options for VS Code.
To check the connection, ask the agent which account it is connected to. It calls whoami, which reports the account and project.
Ask it to fix a bug by key
Every report gets a key from the tracker or from SnagRelay, for example SHOP-142, #88 or a ticket URL. That is all you need to type:
fix SHOP-142The agent recognises the key and calls get_issue_context. You do not need to paste the ticket, a screenshot or a log into the chat.
What the agent reads
For the example, say a client tested a checkout page and reported that the order total was wrong. get_issue_context returns the evidence in the report, not just the sentence the client wrote:
- The element they pointed at, named in the words of the page (for example the "Order total" label), not just a CSS selector.
- What they wrote in their own words.
- Console errors with the file and line.
- Requests that ran around the report, with their status, and request and response bodies available on demand.
- The steps before the report, from the session.
- A screenshot, on paid plans, with the client's markup.
- URL, browser, OS and window width.
Full request and response bodies are fetched on demand: when the agent needs the whole response of one request, it asks for exactly that with get_issue_payload.
In the example, the agent sees that the total comes from a request that returned 200 with a discount of null, followed by a console error in the cart code. That is a very different starting point from "the total is wrong". It is also what makes a human fix fast: a developer reading the same report skips the round of questions about browser and steps.
Earlier bugs like it
Before changing code, the agent can call get_related_history. It returns similar earlier bugs and the changes that fixed them. If the same kind of fault was fixed before, the agent sees how, and you see whether the new fix is consistent with the old one. If nothing similar exists, it carries on.
To work through several reports, find_issues searches and lists the open bugs for a project, so you can ask "what is open for the checkout page?" and then fix them one at a time.
The fix, and your review
With the evidence in hand, the agent edits the code, and while it works it can post a status update to the report with report_progress. When it finishes, you get a normal change in your editor or a branch.
This is the point where a person takes over. Read the diff, run the tests and try the page. SnagRelay's guidance for agents is explicit: do not push, open a pull request or resolve the report until the developer has reviewed the fix. The agent made a proposal from a good report. It did not prove the bug is gone.
Close the loop
When you are satisfied, tell the agent to resolve the report. It calls mark_issue_resolved, and the person who reported the bug gets a "fixed" email. The client does not have to ask whether anyone looked at it, and nobody on your team has to write the follow-up by hand.
The whole sequence for the example is: fix SHOP-142, the agent reads the report, checks related history, edits the code, you review, and the agent marks it resolved.
Keeping it safe
- Limit what the agent can touch. Each project's Agent tab shows a project-only URL (
/v1/<project>) and a read-only URL that hides the tools that write. - Use a token only where there is no browser. For CI or scripts, create an API token in your account settings and send it as a Bearer header. For everyday use, sign in through the browser.
- Review before resolving. Resolving sends an email to a real person. Do it after the fix is checked.
- Reports are redacted at the source. Passwords, tokens, cookies, authorization headers and emails are removed in the browser before anything is sent. See Security.
FAQ
Which coding agents work with SnagRelay over MCP?
Cursor, Claude Code and Codex are the documented clients. The server is a standard remote MCP server, and there is also a VS Code install command on the MCP server page.
Do I need a paid plan to use the MCP server?
No. MCP is included on every plan, including Free. Screenshots with markup are a paid-plan feature, so a Free report arrives without the rendered screenshot but with the element, console errors, requests and steps.
Does the agent fix the bug on its own?
It proposes the fix from the report, and a developer reviews it. Resolving the report, which emails the reporter, is a step you tell it to take after the review.
Can the agent see the passwords or tokens from the session?
No. Passwords, tokens, cookies, authorization headers and emails are redacted in the browser before the report is sent, so they are not in what the agent reads.
What if my developers do not use a coding agent?
Then the report is an ordinary ticket in your tracker, with the same evidence attached. The agent is optional.