Your agent has read every line of the repo.
It has never seen the browser.

A coding agent is fluent in your codebase and completely blind to the twenty seconds before the failure. The evidence it needs existed — in the reporter's browser — and the only route it has ever had into the context window is you, retyping it.

The problem

A model that cannot observe the failure has to invent a reproduction, and an invented reproduction is where a confident wrong patch begins. So a person becomes the transcription layer: pasting a stack trace, cropping a screenshot, writing out the click order from memory, guessing at which request was the one that mattered. Every step of that is lossy, and the parts that get lost are exactly the parts a model is worst at recovering — the request that failed silently, the console error nothing surfaced, the state the page was in when it happened. The result is an agent working from a summary of the bug rather than the bug, and a reviewer who has to check not only the change but whether the thing being changed was ever the problem.

How Snag helps

Snag puts the captured evidence where an agent can ask for it. One call returns the workspace's open, unresolved reports, newest first, with the resolved ones filtered out so nothing is re-fixed; another returns everything captured for a single report as structured fields rather than as prose to be parsed. The instruction to stay grounded in that evidence, and not to fill gaps with invention, travels with the tool itself, so it applies on every call rather than depending on how somebody worded a prompt. The boundary is the point: the server hands out evidence and writes nothing back but the link to a pull request your agent has already opened, so it can change nothing in your repository, and your agent goes on doing the parts it was already doing there. Connecting is a token and a URL over standard MCP — no SDK, no webhook, nothing to host.

What you get back

Your agent's input stops being your account of the bug and becomes the recorded one, and the pull request it raises is still raised by your agent, in your repository, with your credentials on it. What travels back the other way is deliberately thin and short-lived: the links to raw artifacts, replays and video are signed and stop working after fifteen minutes, so nothing here becomes a standing URL into a user's session, and every call re-checks the workspace's entitlement rather than trusting a token that was issued once. The tool reference lists exactly what comes back for a bug, field by field.

Questions people actually ask

Can the server write anything into our repository or our workspace?

It cannot, because no tool exists that would let it. The server hands out evidence and does nothing else, so branching, committing and opening the pull request all happen where they already happen: inside your own repository, on your own infrastructure, under your own credentials. Snag never touches your code.

What does the agent actually receive for one bug?

The report's title and description, the page it happened on with its route, a timestamped summary of the steps, the console, network and error artifacts captured at the time, a link to the replay, and the tracker key if the report was routed. The tool's own description instructs the agent to ground its fix in that material and not to invent details that are not in it.

How much work is connecting it?

A workspace token from the dashboard and a server URL in your client's config. It is standard MCP over Streamable HTTP, so there is no SDK to install, no webhook to receive and nothing to host. Access is included from the Capture plan upwards, and the founding workspaces have it for the life of the workspace.

Where these details come from

This page makes no claim about another product — every detail on it is Snag's own. Something out of date? Email admin@dvcllc.io and we will fix it.