TestingOps.ai

MCP tools for agents · MCP tool for agents

PagerDuty and TestingOps: check incidents before filing defects

Connect PagerDuty's MCP server and TestingOps agents can see whether a service was already in an incident when your test failed.

  • MCP tool for agents
  • Available with limits
Request a demo PagerDuty MCP server
Connection
MCP tool for agents
Writes back
Only after a person approves
Last checked
7 Nov 2026

In short

PagerDuty and TestingOps in short

The PagerDuty connection is an MCP tool for TestingOps agents: with a PagerDuty API key, agents can call PagerDuty's MCP server for the US service region while they analyse a failed run.

Agents can check whether a service the test depends on had an open incident at that time, so a known outage is not filed again as a new defect.

Use a read-only key, because PagerDuty's server also offers tools that change incidents; TestingOps asks for approval before each such call, but an approved call still changes your account.

What it does

What it does for your testing

  1. 1

    A known outage, not a new defect

    Input
    A failed run and the services it touched
    TestingOps
    Agents can look for incidents on those services at the time of the failure
    Output
    A failure linked to an existing incident instead of a duplicate defect
  2. 2

    A timeline next to the run

    Input
    Incidents during the run's time window
    TestingOps
    Agents can list which incidents opened and resolved while the run was going
    Output
    A timeline to compare with the order of the failures

Step by step

How it works

  1. Create a read-only keyIn PagerDuty, an admin creates a General Access key with Read-only API Key ticked, or a user creates a user API token; user tokens need PagerDuty's Advanced Permissions feature.
  2. Connect it in TestingOpsPick PagerDuty under Extra tools your agents may use in Integrations → API & MCP, paste the key into PagerDuty API key and select Connect.
  3. TestingOps sends PagerDuty's headerThe key goes to PagerDuty's MCP server in PagerDuty's Authorization: Token token= form and stays on the TestingOps server.
  4. Agents check incidents while analysingWhen an agent analyses a failed run, it can ask PagerDuty about incidents on the affected services.

EU accounts use a different PagerDuty address. Your own MCP server takes only an address, so an EU account cannot send its key there yet.

Connect

Setup

  1. In PagerDuty, an admin opens Integrations → Developer Tools → API Access Keys and creates a General Access key with Read-only API Key ticked; alternatively open My Profile → User Settings → API Access and select Create API User Token.
  2. Copy the key, which is shown in full only once.
  3. In TestingOps, as customer admin, open Integrations → API & MCP and pick PagerDuty under Extra tools your agents may use (outgoing, over MCP).
  4. Paste the key into PagerDuty API key and select Connect.

Documentation: PagerDuty MCP server

Where you connect it in TestingOps: Integrations → API & MCP → Extra tools your agents may use → PagerDuty

Use cases

Use cases

Avoid duplicate defects during an outage

Trigger
Many cases fail at once in a nightly run
Uses
Incidents on the services those cases depend on
Agent activity
Can check for open incidents in the failure window
Result
Failures grouped under the incident instead of a defect per case

Decide when to rerun

Trigger
A run failed while an incident was open
Uses
The incident's status
Agent activity
Can check whether the incident has been resolved
Result
A rerun planned after the resolution rather than straight away
Condition
Rerunning is a separate decision; the tool provides the status

Give developers the incident context

Trigger
A failure turns out to be a real defect that appeared during an incident
Uses
The incident's service and time
Agent activity
Can mention the related incident in its analysis
Result
A defect report that says what else was happening at the time

Capabilities

Capabilities and limits

What is read

Incidents and services in your PagerDuty account, as far as the key allows

What is produced

Context for agents' failure analysis; nothing is stored in TestingOps by the tool itself

Where it can write

  • PagerDuty's server also offers tools that create or update incidents, services and schedules
  • A read-only key makes PagerDuty refuse them. With a broader key, tools such as manage… ask for approval first, like every tool that is not marked read-only or named for reading

How it connects

PagerDuty's hosted MCP server for the US service region (https://mcp.pagerduty.com/mcp) with the key in an Authorization: Token token= header

Account and permissions

  • A read-only General Access key, or a user API token (needs Advanced Permissions)
  • Customer admin (or Manage integrations) rights in TestingOps; the tool is visible only to agents working on your organisation's projects

Limits

  • US service region only; EU accounts cannot be connected yet
  • Approvals for write tools are answered on the request by people in your organisation with Manage integrations rights, or by the TestingOps team
  • Agents running on Grok receive no MCP tools

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

At night a regression run on staging fails in twelve cases that all call the account service. With PagerDuty connected through a read-only key, the analysing agent can find an open incident on the staging account service that started minutes before the run.

Instead of twelve defects, the analysis links the failures to that incident and suggests rerunning the cases once it is resolved.

Frequently asked questions

Why recommend a read-only key?

PagerDuty's MCP server includes tools that change incidents and schedules. TestingOps asks for approval before each such call, but an approved call still changes your account; a read-only key makes PagerDuty refuse such changes outright.

Our account is in PagerDuty's EU region. Can we connect?

Not yet. The PagerDuty entry is the US region, and Your own MCP server cannot send PagerDuty's Token token= header.

Will agents acknowledge or resolve incidents?

That is not what this connection is for. Use it to read incident status; with a read-only key, PagerDuty refuses changes.

Does a user token work?

Yes, if your PagerDuty plan includes Advanced Permissions, which user tokens need. A read-only General Access key avoids tying the connection to one person.

Next step

Request a demo to see how incident status can shape what agents report after a failed run.

Request a demoMore mcp tools integrations