Blog

Giving AI coding agents your bug tracker: MCP for QA

2026-10-08 · An agent that can read the bug, see the error and the failed request, fix it, and run the covering tests before it says done. What the connection looks like and what to keep out of its hands.

Connect your bug tracker to your coding agent over MCP and the loop closes: the agent pulls the bug with its screenshot, console and network, fixes it, asks the test suite to run the covering tests, and reports back with evidence. The connection is a few lines of configuration. The design work is deciding what the agent may do on its own and what needs a person.

What MCP is, in one paragraph

The Model Context Protocol is how a coding agent (Claude Code, Cursor, and others) is given tools beyond its editor. A server exposes named tools with typed inputs; the agent decides when to call them. A bug tracker's MCP server might expose "search bugs", "get bug", "comment", "update status", and that is enough for the agent to work a ticket.

What the agent needs from a bug

The same four things a developer needs. The page and a screenshot, the steps that led there, the console error, and the request that failed with its status. A tracker that stores those with the bug can hand them over in one call. A tracker that stores "checkout broken, see attached video" cannot, and the agent will spend its first ten minutes trying to reproduce by guessing.

The loop, tool by tool

1. Search. "Open bugs on the billing page, highest severity first." The agent picks one.
2. Get. The full bug: the error text, the failed request's path and status, the trail of clicks, the screenshot.
3. Fix. The agent works in the repository as it would for any task.
4. Run the covering tests. If the tracker is paired with the test suite, the agent asks for the tests that cover the bug's page and waits for the result. A green here is the evidence; without it the agent is saying "trust me".
5. Comment and update. A note on the bug with the commit and the test result, and a status change to "fixed", or "needs a person" if the tests stayed red.

What to keep out of its hands

Give the agent read access to everything and write access to little. It should comment freely and change status within a range (open to fixed), but not close a bug, not delete, not change severity, and not touch other people's assignments. Closing is a person's call, made after the fix reaches a customer.

Keep secrets out of bugs entirely. A capture tool should blur on demand and never record a password field; if a bug holds a token in a request body, an agent with read access now holds it too.

A worked example

A composed example: the team, the timings and the counts show the shape of the work and are not measurements from one customer.

A support engineer captures a bug: on the invoices page, "Download PDF" does nothing. The capture holds the console line (TypeError: cannot read 'id' of undefined), the request that failed (GET /api/invoices/undefined/pdf, 404), the three clicks that led there, and a screenshot with the button circled.

A developer starts a Claude Code session with the tracker connected and says "fix the invoice download bug". The agent searches, finds it, reads the request path, and knows the invoice id is missing before it opens a file. It finds the list component passing the wrong prop, fixes it, and asks the test suite to run the tests covering the invoices page. Two tests run; both pass. The agent comments with the commit and the run, sets the bug to fixed, and stops. The developer reviews a two-line diff with a green run attached.

Setting it up

Most trackers that support MCP give you one URL and a token per workspace. Add it to the agent's configuration, grant a token with the permissions above, and try the loop on one real bug before you let it run on a queue.