The interesting question is not whether a language model can write a patch. It obviously can. The question is what has to be true around the model for that patch to be worth reviewing.
Most developers who ask it already have a capable agent open in a terminal. What that agent lacks is the production side: it never saw the error happen.
What the agent needs to see
A stack trace tells you where a program died. It rarely tells you why. Consider a TypeError: Cannot read properties of undefined on session.user.id. The trace points at the property access. The cause is thirty milliseconds earlier, in a token refresh that invalidated the session while a concurrent request was mid-read.
No amount of model quality recovers that from the trace alone. What recovers it is the rest of the record, assembled once and handed over:
- The issue: title, culprit, level, times seen, users affected, first and last seen.
- Sample events: real exceptions with their frames, the breadcrumbs leading in, tags, user and trace id.
- Connected errors: other issues whose events share a trace with this one.
- The trace tree: the transactions in the event's trace and the spans under each, with duration and status.
- Related logs: log records written under the same trace id.
That is the bundle Parsemend's get_issue_context returns. With the breadcrumbs and the trace in front of it, a race condition stops looking like a random null.
Two ways to get it to an agent
An agent the vendor runs
Sentry Seer analyses issues in Sentry's cloud and opens pull requests through a GitHub or GitLab app. As of July 2026 it costs $40 per active contributor per month, on top of the Sentry plan. Sentry does not document a way to choose the model or supply your own API key.
The trade is clear enough. You set nothing up on your machine, and in return the vendor needs your repository, picks the model, and bills per seat. The Seer cost breakdown has the arithmetic.
The agent you already use
Claude Code, Codex, Cursor and the other coding agents will fix a bug if you paste the trace in. Pasting carries the top of the stack and loses everything else: the breadcrumbs, the trace, the logs, and the question of which open issue deserves a session at all.
MCP closes that gap without moving the work off your machine. Parsemend's CLI runs a local MCP server over stdio:
npm install -g @parsemend/cli
parsemend login
claude mcp add parsemend -- parsemend mcp
Codex takes codex mcp add parsemend -- parsemend mcp; Cursor reads the standard mcpServers block from ~/.cursor/mcp.json. In a session you then say fix api-47, and the agent calls get_issue_context, reads the files the frames point at with its own tools, and edits your working copy. list_issues and get_issue_context make no model call and change nothing. The model doing the reasoning is the one you picked in the session, so Parsemend asks for no AI provider key, and it needs no access to your repository. Your source is never uploaded.
Errors reach Parsemend from the open-source SDK for your language (composer require sentry/sentry-laravel, npm install @sentry/node) and your project's DSN. Those packages are MIT-licensed client libraries; installing one creates no Sentry account.
Ask for the cause before the patch
A good session states a root cause in one sentence, then proposes a change, then writes code. Those are separate steps for a practical reason: correcting a wrong plan costs a sentence, and correcting a wrong diff costs a review.
A model asked to produce a patch will always produce a patch. With your own agent you can make it stop and explain first, and you can ask it to run your test suite against its change before you read the diff, because the suite is right there in the checkout. Parsemend runs no tests and no model on this path; it supplies the context.
Nothing should merge its own patch
Any vendor telling you their agent autonomously fixes production bugs is describing a review queue they have hidden from you, or a liability they have not met yet.
When the agent is yours, the change sits in your working copy until a person commits it. If you want the fix recorded next to the error, the agent calls post_back, which sends the git diff and a one-line summary to the issue. Its tool description tells the agent to ask you first, and it is the only tool that sends anything off your machine. It does not commit, push or open a pull request. You do the commit.
The honest limitation
MCP is a standard, so any MCP client can use it: Claude Code and Codex take one command; Cursor and the rest take the standard mcpServers block. Agent access is on the Developer plan (€9 a month, 50% off at launch); on Free, an alert sends you to the dashboard to read the issue yourself. More on the mechanism at bring your own agent and the MCP server.