Best AI Agent Skills for Incident Response in 2026

Your pager goes off at 2:14am. Checkout latency just tripled, the error rate graph is climbing, and you have four browser tabs open: one dashboard, one logging tool, one trace viewer, and a Slack channel where three people are typing "is it just me?" at the same time. You're the one awake, so you start the part everyone hates. Copy a timestamp from the alert. Paste it into the log search. Scroll. Copy a request ID. Paste it into traces. Scroll again. Twenty minutes later you have a hunch but no proof, and the SLO clock keeps running.

This is the work that AI agent skills for incident response are starting to take off your plate. Not the decision-making. The grunt correlation in the first fifteen minutes, when a tired human is the slowest part of the loop.

Skill vs MCP, in one paragraph

If you're an SRE who hasn't lived inside Claude Code, two words come up constantly and they mean different things. A skill is a folder with a SKILL.md file that the agent reads on demand. It's instructions and procedure plus optional scripts: "when debugging, do these steps in this order, here's the script that pulls the stack trace." The agent loads it only when the task matches, so a debugging skill sits dormant until something breaks. An MCP server is a connector. It hands the agent a live tool or data source over the Model Context Protocol: a browser it can drive, a repo it can query, a monitoring API it can hit. Skills are the playbook; MCP servers are the hands. A good incident setup uses both, and the table below mixes them on purpose.

The shortlist

Here are six that earn a spot in an on-call workflow. I've kept the ones that solve a real step in a page, not the ones with the nicest README.

A note on that last column: skills install by living in a folder, MCP servers install by being registered as a connector. That difference is the whole mental model, so it's worth seeing it laid out before you touch a config file.

What each one actually does for you

sp-systematic-debugging is the Superpowers debugging skill, and it's the one I'd install first. Incidents make people skip steps. The skill won't let the agent propose a fix until it has reproduced the problem and named a root cause, which is exactly the discipline that evaporates when you're tired and the dashboard is red. It's procedure, not magic, but procedure is what you're missing at 2am.

playwright-mcp (you'll also see it as mcp-server-playwright) gives the agent a headless browser. During an incident that matters twice. First, to reproduce: "load the checkout page as a logged-in user and tell me where it stalls." Second, to verify the fix from the customer's side, not just from a green deploy badge. Confirming the symptom is gone is the step people forget in the rush to close the ticket.

claude-debugs-for-you plugs the agent into your editor's debugger. Instead of reasoning about logs after the fact, it can set a breakpoint, run to it, and read the actual variable values. For a class of bugs the logs would never have shown you, this is the difference between a guess and a look.

cc-devops-skills is the catch-all. Think of it as the procedures your senior on-call engineer carries in their head: how to read a deploy diff, where the runbooks live, what to check when a service won't come up. It won't dazzle you, and that's the point. It covers the boring 70% so your attention goes to the weird 30%.

performancemonitor answers the "what changed?" question for metrics. It correlates the incident start time against latency, CPU, and memory curves and tells you which one moved first. That ordering, which metric broke before the others, is often the entire diagnosis.

azure-devops-mcp is Microsoft's connector for Azure DevOps, and it covers the question that solves more incidents than any clever trace: what shipped right before this started? It pulls recent pipeline runs, merged PRs, and work items so the agent can line up the deploy timeline against the alert timeline. If you're on GitHub instead, a git MCP server does the same job: git log and PR history are the cheapest correlation you'll ever run.

Install commands

Nothing here needs a build step. Skills are files; MCP servers are one registration command.

# Skill: clone it straight into your skills directory
git clone https://github.com/obra/superpowers ~/.claude/skills/superpowers
# (sp-systematic-debugging ships inside the Superpowers skill set)

# Another skill, same pattern
git clone https://github.com/<org>/cc-devops-skills ~/.claude/skills/cc-devops-skills

# MCP server: register it as a connector
claude mcp add playwright npx '@playwright/mcp@latest'

# Azure DevOps MCP
claude mcp add azure-devops npx '@azure-devops/mcp@latest'

You can also wire MCP servers up in an .mcp.json file at your project root if you'd rather check the config into the repo:

{
  "mcpServers": {
    "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] }
  }
}

For the exact, current repos, search GitHub rather than trusting a link that might have moved: Superpowers skills, claude-debugs-for-you, cc-devops-skills, performancemonitor skill. The Playwright and Azure DevOps MCPs are published by Microsoft and the Playwright team, so prefer the @playwright/mcp and @azure-devops/mcp packages over forks.

A security note worth reading before you install anything

Skills and MCP servers run with your permissions. The agent loading them is sitting in your terminal, with your cloud creds in the environment and your repo on disk. That's the whole value, and it's the whole risk.

Read the SKILL.md before you drop a skill in your folder. Read the server source, or at least the package, before you register an MCP. The thing you're scanning for: anything that reads your logs, env vars, or credentials and sends them somewhere. An incident-response skill has a legitimate reason to touch logs, which makes a malicious one easy to hide. Prefer official packages and widely-used community skills with real commit history over a repo that appeared last week with one star. When you grant an MCP access to a monitoring API, scope the token to read-only if the provider lets you. None of this is paranoia. It's the same hygiene you'd apply to any tool you give production access.

How to assemble an incident-response skill stack

Don't install all six and call it done. A pile of overlapping tools makes the agent slower and your config harder to trust. Pick by the steps you actually repeat at 2am.

Start with one debugging skill that enforces method, sp-systematic-debugging, because the failure mode under pressure is skipping straight to a fix. That's your spine. Add one correlation source next: either performancemonitor for the metrics side or azure-devops-mcp (or a git MCP) for the "what shipped" side. Most incidents are one or the other, and you'll learn fast which your team hits more often.

Then add a reproduction tool. playwright-mcp earns its place here because confirming the symptom from outside is the step that keeps you from closing an incident that isn't actually fixed. claude-debugs-for-you is the deeper option when the bug lives in code paths the logs won't show. cc-devops-skills rounds it out as the generalist that handles the routine checks so you're not writing the same three commands every page.

The trap is breadth. Three tools you trust and have read beat eight you installed off a trending list. If you're building out a wider toolkit beyond on-call, the same logic applies to skills for DevOps engineers: fewer, audited, mapped to real steps.

One more thing about the human in the loop: keep the agent advisory during a live incident. Let it correlate, reproduce, and propose. You decide what gets rolled back and what gets restarted. An agent that's great at finding the cause is still a poor choice for pulling the trigger on production at 2am, and you'll sleep better knowing the destructive actions stayed under your own hand.

FAQ

Can an AI agent resolve an incident on its own? Not safely, and you shouldn't want it to yet. The strong use is the diagnosis half: correlating logs, reproducing the symptom, naming the likely cause. Remediation that touches production stays a human call. Treat the agent as the fastest junior on-call you've ever had, not as the incident commander.

Skill or MCP server: which should I reach for? If you need a procedure the agent should follow, that's a skill. If you need it to touch a live system or data source, that's an MCP server. Debugging method is a skill; driving a browser or querying your deploy history is an MCP. Most real setups run a couple of each.

Do these work outside Claude Code? MCP servers do, since the protocol is open, and the Playwright and Azure DevOps servers run with any MCP-capable client. Skills in the SKILL.md format are tied to agents that read that format, Claude Code being the main one today. Check your client's docs before assuming a skill ports over.

Is it safe to give an agent access to production logs? With care. Logs hold tokens, PII, and internal hostnames. Scope read-only tokens, audit which MCP servers can see what, and read the source of anything that handles log data. The convenience is real and so is the blast radius if you skip the review.

What's the smallest useful setup? One debugging skill and one correlation MCP. sp-systematic-debugging plus either a git MCP or azure-devops-mcp covers most of what slows you down in the first fifteen minutes. Add reproduction tooling once that pair is earning its keep, and grow from there only when a real recurring step demands it.