PagerDuty MCP. Manage Outages and Incident Response from Anywhere.
Gemini Works with every AI agent you already use
…and any MCP-compatible client
Just plug in your AI agents and start using Vinkius.
PagerDuty connects your AI agent directly to mission-critical incident management. Use it to list active incidents, check service health configurations, and manage on-call rotations in real time.
Trigger alerts, acknowledge outages, or resolve issues without leaving your IDE—all via natural conversation.
What your AI agents can do
Create incident
Logs a new service incident using the provided email, service ID, and title.
Get incident
Fetches full details about an existing PagerDuty incident via its unique ID.
Get service
Retrieves the full configuration and status for a specific monitored service.
Retrieves a list of every service monitored by PagerDuty.
Identifies the current primary and secondary contacts based on active schedules.
Retrieves all information (status, service, severity) for a specific incident ID.
Automatically logs and creates a new incident on a specified service.
Changes an existing incident's state (e.g., acknowledge, resolve) programmatically.
Displays the defined path and timeouts for how an alert routes through multiple teams.
Ask AI about this MCP
Supported MCP Clients
OAuth 2.0 Compatible Gemini Waiting for input…
PagerDuty MCP Server: 11 Tools for Incident & Service Mgmt
These tools let your agent manage the entire incident lifecycle. You can create, read, update incidents, and pull deep operational data on services and users.
Make your AI actually useful.
Add this MCP to Claude, Cursor, or Windsurf and your AI stops guessing. It gets real tools to look things up, take action, and handle the stuff you keep doing by hand.
Start using PagerDuty on Vinkius019d75eecreate incident
Logs a new service incident using the provided email, service ID, and title.
019d75eeget incident
Fetches full details about an existing PagerDuty incident via its unique ID.
019d75eeget service
Retrieves the full configuration and status for a specific monitored service.
019d75eeget user
Gets detailed profile information, including contact methods, for a specified user account.
019d75eelist escalation policies
Lists all defined escalation chains to understand incident routing rules.
019d75eelist incidents
Retrieves a list of incidents, allowing optional filtering by their status (triggered, acknowledged, resolved).
019d75eelist oncalls
Shows who is currently assigned as on-call across all active schedules.
019d75eelist schedules
Lists all available rotation schedules and their associated teams.
019d75eelist services
Retrieves a complete catalog of every service monitored by PagerDuty.
019d75eelist users
Outputs a list of all users configured within the PagerDuty account.
019d75eeupdate incident
Changes an incident's status—you can acknowledge, resolve, or reassign it programmatically.
Choose How to Get Started
Build a custom MCP for your own tools, or connect a ready-made integration from our catalog.
Build Your Own
Turn any API into an MCP. Import a spec, define Agent Skills, or deploy with MCPFusion.
- Import from OpenAPI, Swagger, or YAML specs
- Create Agent Skills with progressive disclosure
- Deploy to edge with MCPFusion framework
- Built in DLP, auth, and compliance on every call
- Real time usage dashboard and cost metering
- Publish to catalog or keep private
Make Your AI Do More
Start with PagerDuty, then connect any of our 4,800+ other servers whenever your AI needs more. One click, no limits.
- Use this MCP plus 4,800+ others, all in one place
- Add new capabilities to your AI anytime you want
- Every connection is secured and compliant automatically
- Track usage and costs across all your servers
- Works with Claude, ChatGPT, Cursor, and more
- New servers added to the catalog every week
Independent Platform Disclaimer: Vinkius is an independent platform and is not affiliated with, endorsed by, sponsored by, verified by, or otherwise authorized by PagerDuty. All third-party trademarks, logos, and brand names are the property of their respective owners. Their use on this website is strictly for informational purposes to identify service compatibility and interoperability.
VINKIUS INFRASTRUCTURE
Cloud Hosted
Managed infra
V8 Isolated
Sandboxed per request
Zero-Trust Proxy
No stored credentials
DLP Enforced
Policy on every call
GDPR Compliant
EU data residency
Token Compression
~60% cost reduction
Works with Claude, ChatGPT, Cursor, and more
The Model Context Protocol standardizes how applications expose capabilities to LLMs. Instead of operating in isolation, your AI gains direct access to external platforms, live data, and real-world actions through secure, standardized connections.
This server provides 11 capabilities that interface natively with Claude, ChatGPT, Cursor, and any MCP client. No middleware. No custom integration required.
Responding to an outage usually means switching five tabs and running three separate queries.
Today, when the system breaks, you jump into the dashboard, click 'Service A,' then open a new tab for 'On-Call Schedules.' You copy the incident ID from one page to paste it into another tool just to check who was supposed to be handling it. It's manual data wrangling that adds minutes—minutes that cost real money.
With this MCP server, your agent handles the entire sequence. Give it an alert and ask: 'Who owns this service and what's its status?' The agent runs `list_services`, finds the ID, calls `get_service` for details, checks `list_oncalls` for personnel, and gives you a single, comprehensive answer right in your chat window.
The PagerDuty MCP Server: Get instant operational control.
Manual steps that disappear include checking the 'Incident Status' page, opening the 'Service Config' tab to check integrations, and then manually cross-referencing a contact list for the right engineer. Each step is a potential point of failure or delay.
Now, you talk to your agent. You tell it what needs fixing, not what needs looking up. It executes `get_incident` and runs `list_oncalls` in sequence. The process isn't just faster; it’s fundamentally safer because every call is verifiable via the tool manifest.
What you can do with this MCP connector
You're gonna connect your AI agent right into PagerDuty. This server gives your client full control over incident management, so you don't gotta jump between dashboards just to fix something. You can manage services and respond to outages straight from where you're coding.
Incident Management Tools
The list_incidents tool lets you pull up a list of every open outage, letting you filter that rundown by status—you can see everything triggered, what's acknowledged, or what's already resolved. If you need the deep dive on one specific event, use get_incident with its unique ID; it’ll hand back all the full details: the current status, the affected service, and how bad things are.
Don't wanna wait for an alert? You can proactively log a new outage using create_incident, giving it an email address, the specific service ID, and a title right away. When an incident pops up that needs attention, you use update_incident to change its state—you can acknowledge it as a known problem or resolve it when you fix the underlying mess.
Service Monitoring & Discovery
To see what services are even getting monitored, run list_services; it gives you the complete catalog of every single thing PagerDuty tracks. Once you know which service is giving you grief, get_service grabs its full configuration and current health status. It shows you exactly how that specific service is set up to monitor itself.
On-Call and Team Structure
To figure out who's supposed to be fixing this, the system has a few tools for people. list_oncalls tells you right now who’s primary and secondary contacts across all active schedules. You can also see all available rotation plans using list_schedules, which shows every schedule name and the teams tied to it.
If you need details on the actual users, run list_users; that outputs a list of everyone configured in the PagerDuty account. For a deep dive into one specific person, use get_user to pull detailed profile information, including all their contact methods.
Workflow and Escalation Logic
You can map out how alerts flow through the company's structure using list_escalation_policies. This tool displays every defined escalation chain, so you understand the routing rules and time limits for an alert. You also get a clear picture of who’s doing what with list_users, which outputs all configured users in the system.
Summary Action Flow
Your agent can take this information and act on it. It'll list every service you need to check, then pull up the current escalation rules for that service. If things look bad, your agent knows who’s on call from list_oncalls, and it can log a brand-new incident using create_incident. You can track all open incidents by calling list_incidents or get granular status updates by fetching details with get_incident.
When the crisis is over, you use update_incident to mark it resolved. It’s everything in one place.
019d75ee-2ade-73c6-b403-b225ff91edf1 
How PagerDuty MCP Works
- 1 Subscribe to this server, then enter your PagerDuty REST API Key under Configuration > API Access.
- 2 Your AI client calls the
list_servicestool to get a list of all monitored services and their IDs. - 3 You pass an incident ID or service name to tools like
get_incidentorcreate_incidentto start managing the event.
The bottom line is: you use your AI client to run specific, state-changing commands against PagerDuty's live data feed.
Who Is PagerDuty MCP For?
This is for Site Reliability Engineers and DevOps teams who are sick of context switching during an outage. If you're the ops engineer staring at a dozen dashboards trying to figure out who owns what, this tool lets your agent handle the API calls so you can focus on fixing the code.
Uses get_incident and update_incident to quickly triage alerts, acknowledge outages, and resolve tickets without leaving their primary coding environment.
Runs list_services and list_escalation_policies to map out system dependencies and ensure the runbook covers every failure mode.
Uses list_oncalls to get an instant, accurate view of who is covering which services right now, minimizing coordination delays.
What Changes When You Connect
- Immediate Status Checks: Use
list_incidentsto pull a list of currently triggered alerts. You don't have to manually check the dashboard; your agent pulls the data instantly. - Know Who To Call: The
list_oncallstool gives you real-time coverage visibility. Stop wasting time emailing people whenlist_oncallstells you exactly who is on duty and until when. - Control Incident State: When an alert pops up, use
update_incidentto acknowledge it or mark it resolved directly through conversation. This is critical for maintaining the incident timeline. - Deep Service Context: Calling
get_serviceprovides more than just a name; you get deep configuration data, including integrations and auto-resolve timings, which informs your fix strategy. - Map Out Failures: Reviewing
list_escalation_policieshelps you predict how an incident will flow. You see the full chain—Level 1 to Level 2—before it actually breaks. - Fast Triage Cycle: The combination of
list_usersandget_userlets your agent quickly pull contact details for key personnel involved in a specific service or incident.
Real-World Use Cases
The Critical Outage
An alert hits: 'High latency on Auth API.' The agent runs list_incidents and finds the ID. It then calls get_service for that service to see its integrations (Datadog, Sentry). Finally, it uses update_incident to acknowledge the issue, giving immediate visibility into the problem's scope.
Onboarding a New Team Member
A new engineer needs to know the current on-call rotation. They ask their agent, which runs list_oncalls. The response shows exactly who is covering the platform and when they hand off. This saves them 15 minutes of checking internal wikis.
Pre-Mortem Planning
Before a major deployment, an SRE needs to verify service dependencies. They run list_services to get the full catalog. Then they use get_service on three key components to audit their respective escalation policies and required integrations.
Investigating User Roles
An incident requires contacting a specific user role, but the agent doesn't know the ID. The engineer runs list_users, finds the correct profile name, and then uses get_user to get the necessary contact methods.
The Tradeoffs
Assuming current status is enough
A developer sees an incident listed in a dashboard but doesn't know if it was already acknowledged or resolved by another team. They just assume the alert means 'active.'
→
Don't guess the state. Always call get_incident first using the ID. This tool gives you the current, authoritative status of the incident before any action is taken.
Creating incidents manually for everything
An engineer sees a minor warning and runs create_incident without checking if an alert already exists or who owns the service. This clogs up the system with noise.
→
Before creating, always run list_incidents and filter by 'triggered' status. Confirm no equivalent incident exists. If necessary, then call create_incident.
Over-relying on general knowledge
A developer knows the 'payments service' is important but doesn't know its precise ID or current owners. They start troubleshooting based on assumption.
→
Start by calling list_services to get all IDs, then use that ID in conjunction with get_service to pull reliable, structured data for the payments service.
When It Fits, When It Doesn't
Use this server if your primary task involves managing state transitions during an active outage or requiring comprehensive visibility into operational roles. The tools are ideal when you need to read current incident status (get_incident), update that status (update_incident), or determine who is accountable (list_oncalls).
Don't use this if you simply want a list of all services and don't care about their health, or if your process relies on reading documentation outside of the live API state. For simple catalog browsing without action, a basic data lookup tool might suffice, but for active incident response, PagerDuty is non-negotiable.
Common Questions About PagerDuty MCP
How do I check if an incident already exists using the PagerDuty MCP Server? +
You use the list_incidents tool. This lets you search across services and filter by status (triggered, acknowledged, etc.) without having to guess IDs or dashboards.
Can I acknowledge an alert using the PagerDuty MCP Server? +
Yes, use update_incident. This tool allows your agent to change the incident's state (acknowledge, resolve) programmatically. It keeps the official record updated automatically.
What is the best way to find out who is currently on call? PagerDuty MCP Server? +
Run list_oncalls. This tool pulls real-time data showing current coverage levels, including which team member is active and until what time.
Does the PagerDuty MCP Server let me see service integrations? +
Yes. Calling get_service retrieves detailed configuration data for a specific service, including its list of integrated tools (Datadog, Sentry, etc.).
How do I programmatically create a brand-new incident using the `create_incident` tool in the PagerDuty MCP Server? +
You pass your email, service ID, and an incident title. The server immediately generates the alert. This lets your agent trigger an incident instantly without needing manual steps.
Can I use `get_user` in the PagerDuty MCP Server to check a team member's specific contact details? +
Yes, you get detailed information on any user profile. This includes their notification rules and various contact methods. It’s useful for coordinating follow-up comms outside of incident channels.
How do I review the entire alert routing logic using `list_escalation_policies` with the PagerDuty MCP Server? +
The tool lists every defined escalation policy. You see exactly how incidents route through teams and what time limits are set for each level of response.
Does the PagerDuty MCP Server allow me to reassign an existing incident using `update_incident`? +
Yes, you can programmatically change which user owns an active incident. This is critical when shifting ownership during a complex resolution or investigation workflow.
Can I acknowledge and resolve incidents directly from my AI agent? +
Yes! Use the update_incident tool with the incident ID and your PagerDuty email. Set status to acknowledged or resolved to change the incident state instantly without opening the PagerDuty dashboard.
How do I find out who is on-call right now? +
Run the list_oncalls tool. It returns every user currently on-call across all schedules and escalation levels, showing their name, escalation policy, and coverage window.
Can I create incidents programmatically for testing or escalation? +
Absolutely. Use create_incident with your PagerDuty email, the target service ID, a descriptive title, and optionally set urgency to high or low. The incident will immediately trigger according to the service's escalation policy.
Multi-server workflows that include PagerDuty MCP
MCP Recipe for Instant Incident War Rooms
PagerDuty wakes you up at 2am with 'high error rate' but the Axiom dashboard shows 47 different error types , your agent already ran the query, found the root cause, and posted the diagnosis before you opened your laptop
Run Incident Response From Discord via MCP
PagerDuty fires, Datadog provides the evidence, Discord becomes the war room , nobody opens three browser tabs at 3am anymore
Use it with your favorite AI tools
Connect this server to Cursor, Claude, VS Code, and more.