How to Connect Your Incident Management Tool to Claude via MCP

How to Connect Your Incident Management Tool to Claude via MCP

MCP (Model Context Protocol) is the open standard that lets Claude read from and act on external systems, like your incident tool, directly inside a chat. This guide covers connecting PagerDuty, Opsgenie, incident.io, and ServiceNow to Claude Desktop and Claude Code, plus the permission model you need before giving an AI agent access to live incidents.

MCP (Model Context Protocol) standardizes how an AI application talks to outside tools. Instead of a one-off integration per vendor, Claude connects to an MCP server that exposes a fixed set of capabilities, mainly tools it can call and data it can read, over a shared protocol. What we haven't seen anyone cover well is a straight, cross-vendor look at what this means for incident tools specifically, which is the rest of this piece.

Incident response is a context-assembly problem before it's anything else. Someone gets paged, and the first few minutes go to reconstructing what's happening: which alerts fired, who's on call, what the last few incidents on this service looked like, whether anyone's already on it. Normally that means several browser tabs and a Slack search. With an incident tool wired into Claude over MCP, that context lives in the same window as the conversation - Claude can pull the on-call schedule, cross-reference open alerts, and draft a timeline without you leaving the chat.

Every MCP server you connect falls into one of two risk classes, and incident tools make the gap unusually wide. A read-only server - list incidents, show the on-call schedule, pull a postmortem - can leak sensitive operational data if it's over-shared, but it can't change your environment. A write-capable server - acknowledge, escalate, resolve, create - can alter what responders see mid-incident, silently resolve something that isn't actually fixed, or page the wrong person if a tool call goes wrong. Those are different categories of mistake, and most setup guides for these tools don't say so.

Our recommendation: connect read-only by default, and add write access as a deliberate second step once you trust the specific tool calls you're relying on. Before you connect a credential to any of these tools, run through this checklist:

• Does the connector or API key offer a read-only scope, and did you pick it? (PagerDuty's local server, for example, ships read-only until you add a flag.)
• If it's write-capable, can your plan restrict individual tools to 'ask before running' rather than auto-approve? Team and Enterprise plans can.
• Is the credential a personal token tied to one person, or a shared/service credential the whole team can trigger actions with?
• Would you be comfortable with this tool call running unattended, overnight, with nobody watching? If not, don't set it to auto-approve.

If you can't check the first two boxes, treat the connector as write-capable by accident, and lock it down before it ever touches a live incident.

MCP support for incident tools moves fast and unevenly. Here's where the four tools in this guide stand, plus Splunk On-Call for comparison, as of this writing:

• Step 1: Open Claude Settings: Open Claude Desktop and go to Settings from the Claude menu.

Step 1: Open Claude Desktop Settings from the menu.

• Step 2: Go to Developer -> Edit Config: In Settings, select Developer and choose Edit Config under Local MCP servers.

Step 2: Navigate to Developer settings and edit config.

• Step 3: Add the MCP server configuration: For a local PagerDuty MCP server, add the server entry to claude_desktop_config.json. Keep the credential read-only unless you deliberately need write access.

Step 3: Add the server entry to claude_desktop_config.json.

• Step 4: Choose write access deliberately: The local PagerDuty server is read-only by default. Only add the write-tool flag after you have decided Claude should be allowed to modify incidents.

"args": ["pagerduty-mcp", "--enable-write-tools"]

Treat write access as a separate decision from connecting the server.

• Step 5: Save and fully restart Claude Desktop: Save the configuration and use Quit to fully restart Claude Desktop. Closing the window alone may not reload the MCP server.

Step 5: Restart Claude Desktop to load the new MCP server configuration.

• Step 6: Verify the server is running: Return to Settings -> Developer and confirm the incident server appears under Local MCP servers. If no tools appear, check the server logs before assuming the token is wrong.

Step 6: Verify the MCP server is active under Local MCP Servers.

• Step 1: Add a remote MCP server: For a hosted incident.io MCP server, add the remote endpoint from Claude Code:

claude mcp add incident-io --transport http https://mcp.incident.io/mcp

• Step 2: Authenticate with /mcp: Start Claude Code and use /mcp to complete the browser authorization for an OAuth-based server. For token-based servers, provide the token as a header:

claude mcp add pagerduty --transport http https://mcp.pagerduty.com/mcp \
  --header "Authorization: Bearer YOUR_PAGERDUTY_API_KEY"

• Step 3: Add a local stdio server: For a locally running PagerDuty server, use the stdio form instead of an HTTP endpoint:

claude mcp add pagerduty --env PAGERDUTY_USER_API_KEY=your-token -- uvx pagerdutymcp

• Step 4: Choose the right scope for on-call credentials: Claude Code supports local, project, and user scopes. Keep personal on-call credentials out of project scope because .mcp.json is designed to be shared with the project.

• Local: private to you and this project.
• User: private to you across projects on the machine.
• Project: shared through .mcp.json; use only for shared, org-managed authentication.

• Step 5: Test the connection: Once the server is configured, use /mcp in Claude Code to confirm the connection and available MCP tools before using it during an active incident.

• Step 1: Choose between direct connections and a managed gateway: Use a direct/official server when you want fewer moving parts and no third party between Claude and the incident vendor. A managed gateway is useful when you need one MCP endpoint, centralized credentials, and a shared audit trail across several services.

Direct connections vs. Managed gateway architecture.

Once a connector is live, here's the kind of thing worth trying beyond the obvious 'create a new incident':

• “Summarize all active P1 incidents from this week, grouped by service.”
• “Who's on call right now, and have they acknowledged the latest alert?”
• “Draft a postmortem outline for incident #482, pulling in the timeline and any linked follow-ups.”
• “Compare this week's paging volume to last week's - is overnight noise getting worse for any one team?”
• “Which alerts from the last 24 hours never turned into a real incident, and what do they have in common?”

Notice the shift: these all read data and synthesize it. That's deliberate - it's also the safest category of prompt to hand to a write-capable connector while you're still building trust in how it behaves.

MCP support for incident tools is moving fast - Opsgenie's migration timeline, PagerDuty's write-tool flag, and ServiceNow's Action Fabric rollout have all shifted in just the last few months. Treat the table above as a snapshot, and check each vendor's own docs before you lock in a production setup.

Connecting your incident management platform to Claude through MCP is a strong first step toward AI-assisted incident response. But the real value comes from what happens after the connection: giving AI the right context, integrating your observability stack, codifying runbooks, and defining what actions it can safely take.

DataTroops helps engineering teams turn these individual integrations into production-ready AI SRE workflows. With our AI SRE Solutions, we can help you:

• Connect your existing stack: Integrate Claude with incident management, observability, ticketing, logs, metrics, traces, deployment systems, and internal knowledge using MCP and APIs.
• Build incident-aware AI agents: Create AI agents that can investigate alerts, gather relevant telemetry, correlate recent deployments, review historical incidents, and identify likely root causes.
• Automate incident investigation: Our AI-powered incident management solutions can help automate repetitive investigation workflows, reducing the time engineers spend manually jumping between monitoring, logs, tickets, and runbooks.
• Turn runbooks into executable workflows: Convert existing troubleshooting procedures and engineering knowledge into structured AI workflows that can execute consistently across recurring incident patterns.
• Add human-in-the-loop controls: Keep investigation and analysis automated while requiring engineer approval for sensitive remediation actions such as restarting services, changing traffic, or modifying production resources.
• Build a production-aware AI layer: Through a Production Health Assessment, DataTroops can identify recurring incidents, alert fatigue, operational bottlenecks, and opportunities for AI-driven automation before implementing the right workflows.
• Measure the impact: Track improvements across metrics such as MTTR, time to diagnosis, alert-noise reduction, automation rate, and recurring incident volume.

The result is more than Claude connected to your incident management tool. It becomes an AI-powered incident investigation workflow.

MCP provides the connection layer. DataTroops AI helps build the production intelligence, automation, guardrails and engineering workflows that make that connection useful at scale.

Connecting your incident management tool to Claude through MCP is more than an integration. It creates a foundation for faster, context-aware incident response. With the right telemetry, workflows, and guardrails, teams can move from simply detecting incidents to understanding and resolving them faster.

With DataTroops AI SRE solutions, organizations can build production-ready AI workflows that bring together incident data, observability, engineering knowledge, and automation while keeping humans in control.