How do I give my coding agent access to production errors?

Three ways agents get production errors today

Your coding agent runs on your laptop or in CI. Production errors happen on another machine. Something has to carry them across, and the choice decides what the agent can see.

• You paste the stack trace into the chat. It works for one error, but the agent gets no request, no breadcrumbs and no count, and it has no way to check whether the error stopped after the fix.
• You give the agent shell access to production logs. Now an agent holds credentials to your servers, and it greps unsorted text across thousands of lines to find one failure. Most teams stop here for good reasons.
• You connect an error tracker over MCP. Errors arrive grouped, counted and in full, and the agent calls tools such as "recent errors" or "get this error" without any access to your servers.

What the agent needs to see to fix the bug

• The error type, message and stack frames, so it can open the right file and line.
• How often it happens, since when, and in which release, so it fixes the error that matters first.
• The request (method, URL, headers with secrets removed) and the breadcrumbs before the crash, so it can reproduce it.
• A way to mark the error fixed, so a regression shows up as the same error reopening instead of a new mystery.

Runheed stores all of that per error group. The MCP server has nine tools: six read, three change an error's status (resolve, ignore, unignore).

Set it up in two steps

Install the SDK in the app that throws the errors and initialize it once at startup. Uncaught exceptions and unhandled rejections are reported from then on.

npm install https://runheed.com/dl/runheed-0.1.0.tgz
# or, for Python
pip install https://runheed.com/dl/runheed-0.1.0-py3-none-any.whl

import runheed from 'runheed';

runheed.init({
  dsn: process.env.RUNHEED_DSN!,
  environment: 'production',
  release: process.env.GIT_SHA, // optional: lets the agent match errors to a deploy
});

import os, runheed

runheed.init(dsn=os.environ["RUNHEED_DSN"], environment="production")

Then connect your agent. In Claude Code it is one command, followed by /mcp and Authenticate to sign in:

claude mcp add --transport http runheed https://runheed.com/api/mcp

Cursor, Codex, VS Code, ChatGPT and claude.ai take the same server URL; Windsurf, Zed, Gemini CLI and Cline use the local server with an agent key. Each client has its own page under Connect your agent. Framework specifics (Next.js instrumentation.ts, Express middleware, FastAPI, Django, Flask) are under setup by framework.

What to ask once it is connected

• "What broke in production since the last deploy?" (recent errors and trends)
• "Show me the stack trace and breadcrumbs for the top error." (one error in full)
• "Did errors go up after yesterday's release?" (24 hour, 7 day and 30 day trends)
• "Fix it, then resolve it with the commit hash." (resolve with a note; it reopens if it happens again)

What the agent cannot do

Runheed has no access to your servers or your code. The agent edits code in your editor under the permissions you gave it there, and its key can only read errors and change their status. Authorization, cookie and API-key headers are redacted when an event arrives. More in is it safe to let a coding agent read your production errors.