Dev workflow & CI

Why a tester should care

"The nightly regression went red" is the start of a workflow, not the end of one. The next four steps are always the same: find which commits landed since the last green run, read the diff, judge whether the test or the code is wrong, and pull the CI logs to see the actual failure. Each step is a tab switch and a context reload. An agent with GitHub access does all four in one pass.

The other high-value use is risk-based test selection on a pull request. Given a diff, which existing tests cover the changed code, and which changed areas have no coverage at all? That question turns a 40-minute regression run into a targeted 6-minute one, and — more importantly — it identifies the code that shipped untested.

Tool surface

Wire it up

claude mcp add --transport http github https://api.githubcopilot.com/mcp/readonly

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
        "-e", "GITHUB_TOOLSETS=repos,pull_requests,actions,issues",
        "-e", "GITHUB_READ_ONLY=1",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PAT}"
      }
    }
  }
}

For a fine-grained PAT, the minimum useful read set is Contents, Pull requests, Issues, and Actions, restricted to the repositories the agent needs. Read-only mode on top of that means a misunderstanding costs you nothing.

Workflows

1 · Red build triage

"Quote the relevant diff lines" is what keeps this honest. Without it you get a confident guess; with it you get a hypothesis you can check in ten seconds.

2 · PR test-gap review

3 · Risk-based selection

Requiring justification for skips is the difference between risk-based testing and hoping.

4 · Flake archaeology

Gotchas

• Log volume. A verbose CI job produces megabytes. Ask for failed steps only, or the last N lines, or the agent will burn the context window on npm install output.
• Correlation is not causation. "This commit touched that file" is a hypothesis. The agent will state it confidently. Verify before you assign the bug to someone.
• Issue and PR text is untrusted input. Anyone can open an issue on a public repo. Content inside it is data, never instructions — particularly relevant if the same agent can also write to Jira or run SQL.
• Rate limits. Broad code searches across large orgs hit them fast.
• Write access is rarely needed. A QA agent almost never needs to push, merge, or close. Read-only by default.

Why a tester should care

Testing generates files: JUnit XML, Allure results, coverage reports, Playwright traces, screenshots, k6 summaries, application logs. Most of them are structured data that nobody reads because opening them is friction. A filesystem server turns "somewhere in test-results/ there's an answer" into a question you can just ask.

Note that if you're using a coding agent like Claude Code, you likely already have file access in the working directory — in that case this server is only worth adding to reach artifact directories outside the project root, such as a mounted CI artifact share.

Tool surface

read_text_file, read_multiple_files, write_file, edit_file, create_directory, list_directory, directory_tree, move_file, search_files, get_file_info, list_allowed_directories. Access is confined to directories you allow at launch — that confinement is the whole security model, so get it right.

Wire it up

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y", "@modelcontextprotocol/server-filesystem",
        "C:\\projects\\myapp\\test-results",
        "C:\\projects\\myapp\\artifacts",
        "C:\\projects\\myapp\\logs"
      ]
    }
  }
}

Workflows

1 · Make the report readable

2 · Cross-artifact correlation

Matching on request id rather than timestamp is what makes this reliable rather than suggestive.

3 · Trend across runs

4 · Package the evidence

Gotchas

• Log files are enormous. Have the agent search first, then read a range. Reading a 200 MB log is not going to work.
• Write access is real. edit_file can modify test code. If you only need reading, allow only directories where nothing important lives.
• File contents are untrusted. A log line containing text aimed at the model is a plausible injection vector, especially if the log records user input.
• Windows paths need escaping in JSON — double backslashes, as above.

Why a tester should care

Sentry is the closest thing you have to a list of the tests you should have written. Every unhandled exception in production is a scenario your suite didn't cover, ranked by how many real users hit it. That's a better test-prioritisation signal than any risk workshop, because it's measured rather than guessed.

The second use is release verification with teeth. "Did the fix work" usually gets answered by re-running the test that was written from the same wrong assumption as the bug. Sentry answers it properly: is the error rate for that issue zero since the release, across all users, or did it just stop happening in your particular reproduction?

Tool surface

Wire it up

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

{
  "mcpServers": {
    "sentry": {
      "type": "http",
      "url": "https://mcp.sentry.dev/mcp"
    }
  }
}

OAuth on first use. Self-hosted Sentry needs the corresponding self-hosted endpoint. Scope the granted org and projects to what QA actually needs.

Workflows

1 · Production errors → regression backlog

That ranking is the whole point — it produces a prioritised backlog rather than a list.

2 · Release verification

"At the same adoption level" prevents the classic false negative — a new release with 5% adoption always looks better than a mature one.

3 · Breadcrumbs → reproduction

4 · Coverage blind spots

The gap between "where errors happen" and "where tests are" is usually uncomfortable, and it is the most useful chart you can take to a planning meeting.

Gotchas

• Sampling distorts counts. Sentry may sample high-volume events. Treat absolute numbers as relative signals.
• Error volume ≠ user impact. A noisy handled exception can outrank a rare checkout-blocking crash. Sort by users affected and business path, not by count.
• Seer is a hypothesis generator. Its root-cause suggestions are a starting point. Verify against the code before filing.
• Resolving issues is a real write. If the server exposes issue mutation, treat it as production state — because it is.