MCP-based incident response coordination across six to ten tools

Incident Response Already Crosses Six to Ten Tools

A typical 2026 incident touches more independent tools than the on-call engineer can hold in working memory. The pager fires from the on-call vendor (PagerDuty, Opsgenie, Incident.io). The first signal is usually in metrics (Datadog, Grafana, New Relic). The second signal is in logs (Splunk, Elastic, Loki). The third is in traces (Datadog APM, Honeycomb, Tempo, Jaeger). The deploy that caused it is in CI (GitHub Actions, Buildkite, CircleCI). The fix is in version control (GitHub, GitLab). The blast radius is in the cloud console (AWS, GCP, Azure). The communication is in chat ops (Slack, internal Mattermost, Teams). The postmortem is in a doc (Notion, Confluence, the incident vendor’s own template). The customer-facing status update is somewhere else again.

Engineers consistently spend two to four hours of an incident’s wall-clock time just locating the source — switching between consoles, copying timestamps, pasting trace IDs, manually correlating across UIs that were not designed to talk to each other. The incident itself is often resolvable in fifteen minutes once the cause is found. The work in between is the cost.

The 2024-2025 generation of AI SRE tools (Komodor, Traversal, NeuBird, SRE.ai, Resolve, FireHydrant’s AI features, Datadog Bits) attacked this with vendor-specific copilots — a smart agent inside a single tool’s UI that summarizes what it sees. Useful, but each one is locked to its vendor’s data. The cross-tool correlation problem stayed unsolved.

The Model Context Protocol changed the constraint. MCP gives every tool a standardized way to expose its data and actions to an LLM, and gives an LLM a standardized way to read across all of them in a single conversation. By 2026 every tool that matters in the incident path has either shipped an MCP server or is actively building one. The connective tissue exists for the first time.

What MCP Actually Changes

MCP is not magic. It is a protocol that defines how a host application (Claude, Claude Code, Cursor, an internal agent) calls “tools” exposed by an MCP server, and how that server returns structured results the model can reason over. The contract is small: list available tools, describe their inputs, return typed outputs. The implications are large because every tool now speaks the same dialect.

For incident response, three properties matter:

• One conversation, many tools. A single LLM session can call PagerDuty’s MCP server to read the active incident, Datadog’s MCP server to pull the spike timeline, GitHub’s MCP server to identify the deploy that landed at the inflection point, and the cloud provider’s MCP server to confirm the affected region. The correlation work that used to require a human switching tabs is now a sequence of typed calls that an agent makes in seconds.

• Action, not just retrieval. MCP servers expose mutating operations as well — open an incident, post an update, roll back a deploy, scale a service, restart a pod. The same agent that did the read-only investigation can take the read-write next step, gated by the same approval policy the human follows.

• Composability across vendors. The vendor-locked AI SRE copilots compete with each other; MCP servers compose. An incident that spans Datadog metrics and Splunk logs and a GitHub deploy is one conversation, not three.

The 2026 MCP-For-Incidents Vendor Picture

The MCP-server landscape moved fast in late 2025 and early 2026. The pieces an incident-response stack needs are now mostly addressable:

• PagerDuty shipped a first-party MCP server in 2025 and has been positioning MCP as the connective layer for the AI-assisted incident lifecycle. The server exposes incident lookup, status updates, on-call lookup, and incident creation. PagerDuty has been explicit that MCP is the standardized interface they want third-party agents to use.
• Datadog ships an MCP server that exposes metrics, monitors, logs, and APM traces. The server is the canonical way to give an LLM access to Datadog data without giving it the full API surface.
• Splunk, New Relic, Grafana, and Honeycomb each have either shipped or announced MCP servers. The observability category converged on MCP fast because the alternative — every customer building bespoke connectors — was untenable.
• GitHub ships an MCP server that exposes pull requests, issues, deploys (via Actions), and repository contents. The deploy-correlation problem that historically required custom plumbing is now a standard tool call.
• AWS, GCP, and Azure each have MCP servers (first-party or community) that expose service health, recent changes, and a constrained set of remediation actions. The cloud-blast-radius question that used to take a console deep-dive is now answerable from the same agent conversation.
• Internal MCP servers are the missing piece for most teams. The internal service catalog, the runbook repository, the on-call escalation map, the customer impact data — these are usually the highest-leverage MCP servers a platform team can stand up, because they are the data the off-the-shelf servers cannot supply.

The 2026 MCP roadmap (published by the protocol stewards) lists the four properties enterprises consistently asked for: an immutable audit trail of every tool call, SSO-integrated authentication, a gateway that sits between the LLM and the MCP servers for centralized policy, and configuration portability across MCP host applications. All four are critical for production incident response and all four landed or are landing in 2026.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

Three Coordination Patterns That Work

Wiring MCP servers up is the easy part. Building incident-response patterns on top of them is where teams either succeed or stall. Three patterns have emerged from the early-2026 deployments that survive contact with a real Sev-2.

Pattern 1: The Investigator. A read-mostly agent that gets called as soon as a Sev-2 page fires. It pulls the active incident from the on-call vendor, the metric timeline from the observability vendor, the relevant logs and traces, and the recent deploys. It produces a single summary message in the incident channel: “Here is what changed, here is when, here is the most likely cause, here is the customer impact estimate.” All Observe-tier; no mutations. The on-call human still drives the response, but starts thirty seconds in instead of thirty minutes in.

Pattern 2: The First Responder. A scoped Operate-tier agent that takes the obvious-and-reversible first action. If a deploy landed within the spike window and an automated rollback is in policy, the agent rolls back. If a single pod is throwing while the rest of the deployment is healthy, the agent restarts the pod. If a flag was flipped and the page fired within the rollout window, the agent flips it back. Every action is logged to the immutable audit trail, every action is posted to the incident channel, every action is reversible. The First Responder closes the time-to-mitigate gap on incidents whose remediation is well-known.

Pattern 3: The Postmortem Synthesizer. After the incident is closed, an agent walks the timeline across all the MCP servers, pulls the deploy diff, the metric spikes, the customer-impact data, the chat ops messages, and the runbook steps the human took. It produces a draft postmortem in the team’s standard format. The human edits and ships. The pattern saves the four-to-eight hours that postmortems used to consume in expert engineer time, and the consistency of format makes downstream learning (“what categories of incident keep happening?”) a tractable query instead of a literature review.

The teams that get the most out of MCP in 2026 run all three patterns; the teams that stall typically deployed one in isolation and never built the connective tissue between them.

What MCP Doesn’t Solve

MCP is the wire protocol. It does not, by itself, solve four real problems that determine whether an MCP-based incident-response stack reaches production.

• Audit trail completeness. Every tool call from every agent has to land in an immutable, searchable audit log. The MCP roadmap covers this at the protocol level; the production reality is that most teams need a centralized audit sink (a gateway, a side-by-side observability pipeline, or a custom proxy) to make audit queries cheap.
• Permission scoping. An MCP server typically exposes a wide surface; production safety requires per-call scoping. The gateway pattern from the 2026 roadmap is how this gets enforced — the gateway sees every call, applies policy, and logs the decision.
• Approval gates for irreversible actions. Rolling back a deploy is reversible. Truncating a database is not. The capability-tier model — Observe / Operate / Administer — applies as cleanly to incident actions as to any other agent action, and the agent layer needs an approval-gate primitive to use it.
• Cross-tenant blast-radius reasoning. A multi-tenant SaaS incident often touches multiple customers, each with different SLAs and notification policies. MCP gives the agent the data; the customer-impact reasoning still has to be built on top of the agent’s own logic and the team’s customer model.

The four properties the MCP roadmap targeted in 2026 (audit trail, SSO auth, gateway, config portability) map directly onto these gaps. They are the difference between an MCP demo and an MCP production deployment.

Capability Tiers Mapped to Incident Actions

The capability-tier governance model — Observe / Operate / Administer — fits incident response cleanly:

• Observe. Reading the incident, pulling metrics, logs, traces, deploys, recent changes; summarizing the timeline; correlating signals. Auto-execute, fully audited. The Investigator pattern lives here.
• Operate. Reversible mutations within scope: rolling back a deploy, restarting a pod, scaling a service, flipping a feature flag, posting status updates, opening tickets. Auto-execute when in policy and reversible; gated when out-of-policy or hard to reverse. The First Responder pattern lives here.
• Administer. Cross-tenant changes, customer-facing communications, IAM modifications, billing impact, data-mutating operations. Always requires explicit approval; separation-of-duties enforced. The agent prepares the action and the human signs off.

This mapping is what makes MCP-based incident response deployable inside an organization with real compliance constraints. The MCP servers expose the surface, the gateway enforces the tier, the audit trail records the evidence.

How IAN Helps: The Incident-Agent on the Active Operational Layer

IAN is the AI DevOps team for cloud infrastructure, delivered as a coordinated team of specialized agents on the active operational layer. The incident agent is one of those agents, and it is built natively on MCP rather than around it.

The incident agent runs the Investigator pattern continuously: every page that crosses a tier-2 threshold is correlated across the connected MCP servers (PagerDuty, Datadog, Splunk, GitHub, AWS, internal services) and a summary lands in the incident channel within seconds. The First Responder pattern runs scoped to the customer’s policy: reversible actions auto-execute, irreversible actions escalate to an approver. The Postmortem Synthesizer runs after every closed incident and produces a draft for the human owner.

Because IAN is MCP-first, every action the agent takes is a typed MCP call, every call lands in the immutable audit trail, every approval gate references the capability tier of the action being requested. The same audit trail that gives compliance teams the evidence they need also gives the platform team the data to answer “which incidents would have benefited from a different agent action” and tune policy over time.

Pricing is BYOK and usage-based with a monthly minimum. Customers bring their own model keys (Claude, OpenAI, or another provider) and pay inference cost directly to their model vendor. IAN charges for the orchestration layer, per agent action, per cloud account, per operation class. Usage scales with incident volume, which is itself a strong signal of where the team should invest in reliability work.

The Three-Phase Rollout

Phase 1 — Stand up the MCP servers. Connect PagerDuty, the observability vendor, GitHub, and the cloud provider via their first-party MCP servers. Stand up an MCP gateway (commercial or open-source) for centralized policy and audit. Two-to-four weeks for a team with reasonable platform capacity.

Phase 2 — Run the Investigator pattern in production. Wire the agent into the on-call workflow as a read-only assistant. Ship the cross-tool incident summaries in the incident channel for every Sev-2 page. Measure time-to-context (page-to-summary latency) and let the on-call team rate the summary quality. Two-to-three months of pattern tuning.

Phase 3 — Add the First Responder, gated to reversible actions. Codify the reversible incident actions the team already approves implicitly (deploy rollback in the rollout window, pod restart on isolated failure, feature flag rollback). Set the capability-tier policy. Let the agent execute these with the human in the loop, and tune the auto-vs-gated boundary over the first two months. Add the Postmortem Synthesizer as a parallel workstream.

The pattern compounds. By the time Phase 3 lands, the on-call team is running a different shape of work — fewer minutes locating signals, more minutes deciding what to do about them — and the incident-agent has accumulated enough audit data to make the next round of policy tuning a data exercise rather than a debate.

Get a free infrastructure audit → | See pricing →