Resources · Claude connector

Claude PagerDuty connectorWhat Claude can do in your PagerDuty account.

The Claude PagerDuty connector exposes 64 tools. 42 read incidents, alerts, schedules, services and status pages, and 22 can open incidents, add responders, edit rotations or delete settings. Here: what each one does, what you approve, and which documentation to trust.

Verified Trustpilot reviews · AI, automation & growth agency

Overview

What changes when Claude can reach your PagerDuty

During an incident, nobody wants to click through five screens to learn who is on call or what was already tried. You ask Claude, it reads incidents, notes, schedules and change events in PagerDuty while it answers, and it can take the next step for you once you approve.

Get up to speed in the middle of the night. list_incidents shows what is open, list_incident_notes what responders already tried, and get_past_incidents or get_related_incidents whether this has happened before or is hitting other teams too.

Act without leaving the conversation. manage_incidents changes status, priority or assignees, add_responders brings more responders in, add_note_to_incident logs what you did, and create_status_page_post publishes a status page post.

Handle the rota. list_oncalls answers who is on call right now, and create_schedule_override covers a sick colleague's shift in one sentence.

Now what the directory sheet does not say. Its 64 tool names come from PagerDuty's self-hosted server, which PagerDuty has since archived; its current hosted server documents grouped tools instead. We explain that below. Nothing runs on its own either: no tool fires when an alert comes in. For wiring PagerDuty events into other apps, look at the PagerDuty n8n integration or the PagerDuty Make integration.

Vocabulary

The vocabulary in one minute

Five words you will meet while plugging PagerDuty into Claude.

Connector
The link you set up once between Claude and an account you already own, so Claude can work in that account while it answers you.
Tool
One named action a connector opens to Claude. It picks the ones it needs by itself, and the directory sheet lists them by name.
Authorization
The sign-in screen of the service itself, where you hand Claude the access it will use. Granted once per person, and you can take it back.
Approval
The confirmation Claude waits for before it goes through with something that changes your account, shown in the chat when it matters.
MCP
The shared standard connectors are built on. It is what lets an assistant like Claude talk to an outside service such as PagerDuty.
Connect

Connect PagerDuty to Claude in three steps

  1. 01

    Find PagerDuty in Claude

    In Claude, open Customize, then Connectors, and look for PagerDuty in the list. On a Team or Enterprise workspace, an Owner or Primary Owner has to switch the connector on first, before each member can sign in.

  2. 02

    Start the connection

    Click Connect on the PagerDuty row, then sign in to PagerDuty in the window PagerDuty opens itself. If the link ever breaks, use Disconnect and connect again from the same place.

  3. 03

    Read the authorization screen

    Read PagerDuty's authorization screen before you accept. It belongs to PagerDuty, not to Claude, and it sets what the access covers. You can take that access back later from your PagerDuty account.

Tools

The 64 Claude PagerDuty connector tools, by what they do

PagerDuty gives Claude 64 tools: 42 that read your account, 22 that change something in it.

Two groups: what Claude reads and what it can change. The read and write labels come from PagerDuty's own tool table for these exact names. Tool names stay as Claude shows them.

  • 42 read
  • 22 write

What Claude reads (42)

42 tools

Forty-two tools that look at incidents, alerts, schedules, services, orchestrations, status pages, teams and users.

get_alert_from_incident

Opens a single alert attached to an incident, the raw signal behind it.

When it helps
an incident bundles several alerts and you want the exact one that fired first.
Watch out
Claude needs the incident and the alert it should look at.

Sourcegithub.com · September 30, 2026 ↗

get_alert_grouping_setting

Shows one alert grouping setting, the rule that decides which alerts land together in a single incident.

When it helps
the team gets ten incidents for one outage and you want to see how grouping is set.
Watch out
reading the setting tells you nothing about how well it works in practice.

Sourcegithub.com · September 30, 2026 ↗

get_change_event

Retrieves one of the events PagerDuty logs when someone alters a service, such as a release, with its details.

When it helps
an incident started right after a release and you want the exact record of that release.
Watch out
it covers one event; the list tools give the wider picture.

Sourcegithub.com · September 30, 2026 ↗

get_escalation_policy

Returns a specific escalation policy, the chain of people PagerDuty pages when the first responder does not answer.

When it helps
you want to know who gets paged next if the on-call engineer misses an alert tonight.
Watch out
a policy shows levels and targets, not who is actually on call right now.

Sourcegithub.com · September 30, 2026 ↗

get_event_orchestration

Reads a specific event orchestration, the routing logic PagerDuty applies to incoming events.

When it helps
a noisy integration keeps paging the wrong team and you want to see the orchestration behind it.
Watch out
the router, service and global rules each have their own tool.

Sourcegithub.com · September 30, 2026 ↗

get_event_orchestration_global

Brings back the global rules of an orchestration, the ones applied to every event before any routing.

When it helps
you suspect a global rule is silently dropping some events.
Watch out
these rules touch everything that enters, so read them with care before suggesting anything.

Sourcegithub.com · September 30, 2026 ↗

get_event_orchestration_router

Displays the router configuration of an orchestration, the part that decides which service each event reaches.

When it helps
events from a new monitoring tool land on the wrong service and you want to know why.
Watch out
only the router is shown here, not the rules each service applies afterwards.

Sourcegithub.com · September 30, 2026 ↗

get_event_orchestration_service

Fetches the orchestration rules attached to one service, applied once an event has been routed to it.

When it helps
you want to know why low-priority events on the payments service still page someone.
Watch out
name the service clearly, many look alike in large accounts.

Sourcegithub.com · September 30, 2026 ↗

get_incident

Pulls one incident by its ID, with the details responders look at first.

When it helps
you join a call late and want a summary of the incident everyone is discussing.
Watch out
you need the incident ID or enough context for Claude to find it.

Sourcegithub.com · September 30, 2026 ↗

get_incident_workflow

Shows the details of one incident workflow, a predefined sequence of steps PagerDuty can run during an incident.

When it helps
before a drill, you want to check what the major incident workflow actually does.
Watch out
reading it runs nothing; starting a workflow is a separate tool.

Sourcegithub.com · September 30, 2026 ↗

get_log_entry

Retrieves a single entry from the log, the audit trail of what happened in the account.

When it helps
you want to know exactly who acknowledged an incident at 3 a.m.
Watch out
Claude needs to know which entry you mean, usually from the list first.

Sourcegithub.com · September 30, 2026 ↗

get_outlier_incident

Provides PagerDuty's outlier analysis for an incident, telling you whether it looks unusual compared with past ones.

When it helps
you want to know if tonight's database alert is routine or something new.
Watch out
the analysis is PagerDuty's, Claude only reports it.

Sourcegithub.com · September 30, 2026 ↗

get_past_incidents

Finds past incidents similar to a given one, so you can reuse what worked last time.

When it helps
the same error is back and you want to know how the team solved it before.
Watch out
similar does not mean identical; read the old notes before copying a fix.

Sourcegithub.com · September 30, 2026 ↗

get_schedule

Opens a specific on-call schedule, so Claude can explain the rotation in plain words.

When it helps
you want to see how next month's rotation looks for the platform team.
Watch out
a schedule is the plan; the current on-call list is another tool.

Sourcegithub.com · September 30, 2026 ↗

get_service

Returns the details of a specific service, the unit PagerDuty attaches alerts and incidents to, with its current configuration.

When it helps
you want to know which escalation policy the checkout service uses.
Watch out
name the service exactly, similar names are common.

Sourcegithub.com · September 30, 2026 ↗

get_status_page_post

Reads a single post from a status page, the public or internal notice about an incident or maintenance.

When it helps
a customer quotes your status page and you want the exact wording that was published.
Watch out
it reads the post, not the follow-up messages attached to it.

Sourcegithub.com · September 30, 2026 ↗

get_team

Displays a specific PagerDuty team and its details, the group that owns services, schedules and escalation policies in your account.

When it helps
you want to check how the database team is set up before handing it a new service.
Watch out
membership has its own list tool.

Sourcegithub.com · September 30, 2026 ↗

get_user_data

Retrieves the information of the user who is connected, in other words you as PagerDuty sees you.

When it helps
Claude needs to know who is asking before it filters incidents assigned to you.
Watch out
some filters, such as incidents assigned to you, only work with user-level access, according to PagerDuty.

Sourcegithub.com · September 30, 2026 ↗

list_alert_grouping_settings

Lists every alert grouping setting in the account.

When it helps
you are auditing alert noise and want the full picture of how grouping is configured.
Watch out
a long list is easier to read if you ask about one service at a time.

Sourcegithub.com · September 30, 2026 ↗

list_alerts_from_incident

Lists the alerts that belong to one incident, the individual signals grouped under it.

When it helps
an incident has been open for an hour and you want to know how many alerts it has swallowed.
Watch out
give Claude the incident, it lists alerts one incident at a time.

Sourcegithub.com · September 30, 2026 ↗

list_change_events

Lists the events PagerDuty records across all services when something is released or altered.

When it helps
you want to know what shipped in the last hour before a spike of errors.
Watch out
a busy account returns a lot, so give a time window.

Sourcegithub.com · September 30, 2026 ↗

list_escalation_policies

Lists all escalation policies in the account.

When it helps
you want to find services still attached to the policy of a team that no longer exists.
Watch out
the list does not say who is on call now, only how paging escalates.

Sourcegithub.com · September 30, 2026 ↗

list_event_orchestrations

Lists the event orchestrations set up in your account, each one a set of routing rules for incoming events.

When it helps
you are new on the team and want an inventory of how events are routed.
Watch out
open one orchestration for its rules; the list gives names and IDs.

Sourcegithub.com · September 30, 2026 ↗

list_incident_change_events

Returns the service events PagerDuty links to a given incident, such as releases just before it started.

When it helps
you want to know whether a release happened shortly before the outage.
Watch out
a link is a clue, not proof of cause.

Sourcegithub.com · September 30, 2026 ↗

list_incident_notes

Lists the notes written on an incident by responders.

When it helps
you take over an incident at the end of someone's shift and want the timeline of what was tried.
Watch out
notes are only as good as what responders bothered to record.

Sourcegithub.com · September 30, 2026 ↗

list_incident_workflows

Lists the incident workflows available in your account, the ready-made response sequences your admins prepared for serious incidents.

When it helps
you want to know which workflows exist before a major incident drill, and what each one is called.
Watch out
listing them runs nothing.

Sourcegithub.com · September 30, 2026 ↗

list_incidents

Lists incidents with filters, the main way to ask what is happening right now or what happened last week.

When it helps
Monday morning, you want every high-urgency incident from the weekend.
Watch out
PagerDuty notes that filtering by team or by assignee needs user-level access.

Sourcegithub.com · September 30, 2026 ↗

list_log_entries

Lists log entries, PagerDuty's audit trail of actions in the account.

When it helps
after an incident review, you want the sequence of who acknowledged, escalated and resolved what.
Watch out
the trail can be long; give Claude an incident or a time range.

Sourcegithub.com · September 30, 2026 ↗

list_oncalls

Shows the current on-call assignments across the account.

When it helps
a customer escalation just came in and you need to know who is on call for payments right now.
Watch out
it reflects the current state as PagerDuty reports it.

Sourcegithub.com · September 30, 2026 ↗

list_schedule_users

Lists the users on a schedule for a given time range.

When it helps
you are planning holidays and want to know who covers the last week of December.
Watch out
give a date range, otherwise the answer is hard to read.

Sourcegithub.com · September 30, 2026 ↗

list_schedules

Lists all on-call schedules in your account, the rotations that decide who gets paged, day and night.

When it helps
you want an inventory of every rotation before reorganizing teams next quarter.
Watch out
each schedule's detail comes from the single-schedule tool.

Sourcegithub.com · September 30, 2026 ↗

list_service_change_events

Returns the release and alteration events recorded for a specific service, a quick way to see what moved on it recently.

When it helps
the search service slowed down this afternoon and you want what was shipped to it today.
Watch out
name the service exactly.

Sourcegithub.com · September 30, 2026 ↗

list_services

Lists all services in your PagerDuty account, each one being a unit that receives alerts and opens incidents.

When it helps
you want to spot services with no owner team before an audit.
Watch out
large accounts have many services, so ask for a filter or a team.

Sourcegithub.com · September 30, 2026 ↗

list_status_page_impacts

Lists the impact options available on a status page, the labels you pick when describing how bad an incident is.

When it helps
you are drafting a notice and want the exact impact labels your page offers.
Watch out
these are options, not current incidents.

Sourcegithub.com · September 30, 2026 ↗

list_status_page_post_updates

Lists the follow-up messages posted under a status page post, in order.

When it helps
you want the full timeline your customers saw during yesterday's outage.
Watch out
it reads what was published; adding a message is a separate tool with its own approval.

Sourcegithub.com · September 30, 2026 ↗

list_status_page_severities

Lists the severity levels configured for a status page, the scale your notices use to say how serious an incident is.

When it helps
you want to make sure the notice uses the severity your team agreed on.
Watch out
severities differ from one status page to another.

Sourcegithub.com · September 30, 2026 ↗

list_status_page_statuses

Lists the status options a status page offers, such as the states an incident notice can be in.

When it helps
you are preparing a notice and want the exact status wording available.
Watch out
they are options to choose from, not the live state.

Sourcegithub.com · September 30, 2026 ↗

list_status_pages

Lists all status pages in your account, public or internal, with the names your customers or colleagues see.

When it helps
you run a public page and an internal one and want to be sure which is which.
Watch out
the posts on each page come from other tools.

Sourcegithub.com · September 30, 2026 ↗

list_team_members

Lists the members of a team, the people PagerDuty groups under it for services and schedules.

When it helps
you want to check who is in the SRE team before assigning a new service.
Watch out
it shows membership, not who is on call tonight.

Sourcegithub.com · September 30, 2026 ↗

list_teams

Lists all teams in your PagerDuty account, the groups that own services, schedules and escalation policies.

When it helps
you are reorganizing the on-call structure and want every team name in one place first.
Watch out
open a team for its details.

Sourcegithub.com · September 30, 2026 ↗

list_users

Lists all users in the account, the people who can be paged or who sign in to PagerDuty.

When it helps
you want to spot accounts of people who left the company.
Watch out
it lists people; it does not tell you their permissions in detail.

Sourcegithub.com · September 30, 2026 ↗

What Claude can change (22)

22 tools

Twenty-two tools that open, add, edit, publish or delete. No source describes a confirmation of their own: the general rule below applies.

add_note_to_incident

Approval: see the rule

Adds a note to an incident, the running log responders share.

What Claude asks for
no source describes a confirmation for this tool, so the general rule of the approvals section applies.
When it helps
you want Claude to log what you just tried so the next responder does not repeat it.
Watch out
notes stay on the incident for the post-mortem, so keep them factual.

Sourcegithub.com · September 30, 2026 ↗

add_responders

Approval: see the rule

Adds responders to an incident, bringing more people into the response.

What Claude asks for
nothing specific is documented here; see the general rule further down.
When it helps
the database team needs to join a checkout outage now.
Watch out
check the names of the people added before you approve.

Sourcegithub.com · September 30, 2026 ↗

add_team_member

Approval: see the rule

Adds a user to a team.

What Claude asks for
no dedicated confirmation is described, the default approval rule covers it.
When it helps
a new engineer joins the platform team and should appear in its rotation planning.
Watch out
joining a team can bring them into that team's escalations.

Sourcegithub.com · September 30, 2026 ↗

append_event_orchestration_router_rule

Approval: see the rule

Appends a new rule to an orchestration router, changing where some incoming events are sent.

What Claude asks for
no confirmation of its own is described; the general rule applies.
When it helps
events from a new monitoring tool should reach the payments service.
Watch out
a bad rule can send alerts to the wrong people; test it on a quiet day.

Sourcegithub.com · September 30, 2026 ↗

create_alert_grouping_setting

Approval: see the rule

Creates a new alert grouping setting, a rule for bundling alerts into fewer incidents.

What Claude asks for
nothing tool-specific is documented, so the approvals section's general rule holds.
When it helps
one outage produces twenty incidents and you want them grouped next time.
Watch out
grouping too widely can hide a second, unrelated problem.

Sourcegithub.com · September 30, 2026 ↗

create_incident

Approval: see the rule

Opens a new incident in PagerDuty, on the service you name.

What Claude asks for
no source describes a confirmation for it; the default rule covers it.
When it helps
a customer reports a bug your monitoring missed and you want the on-call team on it.
Watch out
check the service and the wording before you approve.

Sourcegithub.com · September 30, 2026 ↗

create_schedule

Approval: see the rule

Sets up a new on-call schedule.

What Claude asks for
no source describes a confirmation for this tool, so the general rule of the approvals section applies.
When it helps
a new team starts covering nights next month.
Watch out
check the time zone and the rotation start before you approve.

Sourcegithub.com · September 30, 2026 ↗

create_schedule_override

Approval: see the rule

Adds an override to a schedule, a temporary swap of who is on call.

What Claude asks for
nothing specific is documented here; see the general rule further down.
When it helps
a colleague is sick tonight and you take their shift.
Watch out
an override wins over the normal rotation, so check the exact hours.

Sourcegithub.com · September 30, 2026 ↗

create_service

Approval: see the rule

Registers a new service in PagerDuty, the unit that will receive alerts.

What Claude asks for
no dedicated confirmation is described, the default approval rule covers it.
When it helps
the team ships a new API and wants alerts for it from day one.
Watch out
say which team and escalation policy it should use.

Sourcegithub.com · September 30, 2026 ↗

create_status_page_post

Approval: see the rule

Publishes a new post on a status page, the notice your customers or colleagues read.

What Claude asks for
no confirmation of its own is described; the general rule applies.
When it helps
an outage is confirmed and you want a first notice out quickly.
Watch out
on a public page, everyone sees it; read the wording before you approve.

Sourcegithub.com · September 30, 2026 ↗

create_status_page_post_update

Approval: see the rule

Adds a follow-up message to an existing status page post.

What Claude asks for
nothing tool-specific is documented, so the approvals section's general rule holds.
When it helps
the fix is deployed and you want to tell customers the service is recovering.
Watch out
each follow-up is public on a public page.

Sourcegithub.com · September 30, 2026 ↗

create_team

Approval: see the rule

Adds a brand-new team to PagerDuty.

What Claude asks for
no source describes a confirmation for it; the default rule covers it.
When it helps
a reorganization splits the platform team in two.
Watch out
members and services still have to be attached afterwards.

Sourcegithub.com · September 30, 2026 ↗

delete_alert_grouping_setting

Approval: see the rule

Deletes an alert grouping setting.

What Claude asks for
no source describes a confirmation for this tool, so the general rule of the approvals section applies.
When it helps
an old grouping rule merges unrelated alerts and you want it gone.
Watch out
without it, the alerts it bundled come back as separate incidents.

Sourcegithub.com · September 30, 2026 ↗

delete_team

Approval: see the rule

Deletes a team from your account.

What Claude asks for
nothing specific is documented here; see the general rule further down.
When it helps
a team was dissolved months ago and still clutters the list.
Watch out
check first which services and policies still point to it.

Sourcegithub.com · September 30, 2026 ↗

manage_incidents

Approval: see the rule

Changes an incident's status, priority or assignees, for instance to acknowledge, resolve or reassign it.

What Claude asks for
no dedicated confirmation is described, the default approval rule covers it.
When it helps
the fix is confirmed and you want the incident resolved with the right priority for the report.
Watch out
resolving the wrong incident closes a live problem; name it clearly.

Sourcegithub.com · September 30, 2026 ↗

remove_team_member

Approval: see the rule

Removes a user from a team.

What Claude asks for
no confirmation of its own is described; the general rule applies.
When it helps
an engineer moved to another department and should leave the team's roster.
Watch out
check whether they still sit in a schedule or escalation of that team.

Sourcegithub.com · September 30, 2026 ↗

start_incident_workflow

Approval: see the rule

Triggers an incident workflow, running its predefined steps on an incident.

What Claude asks for
nothing tool-specific is documented, so the approvals section's general rule holds.
When it helps
a major incident is declared and your workflow opens the war room and notifies stakeholders.
Watch out
workflows can page or notify many people at once; know what it does before starting it.

Sourcegithub.com · September 30, 2026 ↗

update_alert_grouping_setting

Approval: see the rule

Modifies an alert grouping setting.

What Claude asks for
no source describes a confirmation for it; the default rule covers it.
When it helps
the grouping window is too short and related alerts still split into several incidents.
Watch out
the new rule applies to future alerts, test it before a busy period.

Sourcegithub.com · September 30, 2026 ↗

update_event_orchestration_router

Approval: see the rule

Edits the router of an event orchestration, which decides where incoming events go.

What Claude asks for
no source describes a confirmation for this tool, so the general rule of the approvals section applies.
When it helps
the routing still points to a service that was retired.
Watch out
a router mistake can silence alerts for a whole service.

Sourcegithub.com · September 30, 2026 ↗

update_schedule

Approval: see the rule

Updates an existing on-call schedule.

What Claude asks for
nothing specific is documented here; see the general rule further down.
When it helps
the team moves from weekly to fortnightly rotations.
Watch out
people plan their lives around the rota; announce the change.

Sourcegithub.com · September 30, 2026 ↗

update_service

Approval: see the rule

Updates a service's configuration.

What Claude asks for
no dedicated confirmation is described, the default approval rule covers it.
When it helps
the checkout service should now page the payments team's escalation policy.
Watch out
a wrong escalation policy means the wrong people get woken up.

Sourcegithub.com · September 30, 2026 ↗

update_team

Approval: see the rule

Updates a team's details.

What Claude asks for
no confirmation of its own is described; the general rule applies.
When it helps
the team was renamed and PagerDuty should reflect it.
Watch out
PagerDuty's one-line description does not list which details can change.

Sourcegithub.com · September 30, 2026 ↗

Approvals

What Claude asks you before it acts

By default, Claude stops and asks for your go-ahead before each action it takes on an account for you. The request shows up in the chat, at the moment it matters.

On Team and Enterprise workspaces, owners decide whether members may let some actions through without being asked every time. They can also limit what a connector may do across the whole organization, for example keep reading open and close writing. That setting applies to everyone and nobody overrides it from their own account. And Claude works with your rights and nothing more: it acts through the PagerDuty access you authorized. In an incident, approvals come fast; read what the action does before you say yes.

Plans

Which plans it is available on

Out of the 819 sheets in the official directory, not one shows availability by plan. The per-connector answer is published nowhere: it is a real hole in the catalogue.

The general rule is published, though. Remote connectors are open to all users on Claude, Cowork, Claude Desktop and mobile, and desktop extensions install on Claude Desktop. On Team and Enterprise, an Owner or Primary Owner switches the connector on for the organization before each member can connect. For the current state on your account, the connector's own sheet in the official directory is the place to check.

Limits

Where the Claude PagerDuty connector stops

A connector is not an automation. Claude calls these tools while it answers you: nothing starts when an alert fires, an incident escalates or a shift begins.

This page rests on PagerDuty's own documentation only: no Claude help article covers this connector. The tool list is an observed floor, not a promise, since an admin can open actions that no public sheet shows. The directory's partner badge is not a security audit either, and Anthropic says so on every sheet: it does not pick the tools a publisher exposes and does not vouch that they behave as announced. Connect what comes from a publisher you trust, here PagerDuty itself. For another connector where official sources disagree, read the Claude gmail connector page.

Two official sources disagree

Which tool list describes the PagerDuty connector Claude uses?

What this page followsThe directory sheet still carries the tool names of the self-hosted server, while PagerDuty's knowledge base of September 2026 describes grouped tools on the hosted server. This page takes each tool's read or write label from the archived table, the only source that covers these exact names. What counts for your account is the list the connector shows once connected.

Need help

Need help connecting PagerDuty to Claude?

A person reads every message.

FAQ

Claude PagerDuty connector: frequent questions

01What can Claude do with the Claude PagerDuty connector?
Claude can follow and act on your PagerDuty incidents from a conversation. The directory lists 64 tools: 42 read incidents, alerts, notes, schedules, on-call assignments, services, orchestrations, status pages, teams and users, and 22 open incidents, add responders, manage status and priority, edit schedules and services, publish status page posts or delete settings. In practice you can ask who is on call, what was tried on an open incident, or for an override tonight.
02Can Claude open, resolve or delete things in PagerDuty?
Yes, twenty-two documented tools change your account. Claude can create incidents, manage their status, priority or assignees, add notes and responders, start incident workflows, create or edit schedules, overrides, services and teams, publish status page posts, and edit routing rules. Two tools delete: one removes an alert grouping setting, the other a team. The default approval rule of Claude covers all of them, and Claude only works with the rights of the person who connected PagerDuty.
03Does Claude ask before it pages someone in PagerDuty?
By default, yes: Claude asks for confirmation before each action it takes on an account for you. No source describes a confirmation specific to one PagerDuty tool, so that default rule is what covers new incidents, added responders and started workflows. On Team and Enterprise, owners decide whether members may skip some confirmations and can restrict the connector to reading. On PagerDuty's side, a Scoped OAuth client limits which tools succeed.
04Which plans is it available on?
No official source publishes availability by plan for individual connectors, and none of the 819 directory sheets shows it. The general rule says remote connectors are open to all users on Claude, Cowork, Claude Desktop and mobile. On Team and Enterprise, an Owner or Primary Owner enables the connector for the organization before members connect one by one. The connector's sheet in the official directory is the only place that shows the current state for your account.
05Does Claude see everything in our PagerDuty account?
Claude reaches what the PagerDuty access you authorized can reach, and no more. PagerDuty adds that some tools and filters need user-level access, so an account-level connection may not answer every question the same way. A Scoped OAuth client on PagerDuty's side can narrow which tools succeed. On Claude's side, an owner of a Team or Enterprise workspace can restrict what the connector may do for everyone, and members cannot lift that limit.
06Why don't the PagerDuty tools in Claude match PagerDuty's docs?
Because two official lists exist. The directory sheet shows 64 detailed tool names that match PagerDuty's self-hosted server, which PagerDuty has archived. PagerDuty's current knowledge base describes its hosted server with grouped tools, one to browse and one to manage each area. This page follows the directory names and takes their read or write label from PagerDuty's archived table. Check the list your connected account shows to see what you actually get.
07Claude or an automation tool for PagerDuty?
They do different jobs, so it depends on the use. Claude works during a conversation: you ask about an incident, it calls a tool, you approve and check. An automation tool runs in the background when something happens, such as a new incident that should open a ticket elsewhere. The connector has no tool that starts by itself. For event-driven links with other apps, an automation platform is the right trade.