Incident response action layer for MCP
mttrly gives AI coding assistants a controlled way to move from alert context to diagnosis, approval, remediation, and audit history.
Direct answer
An incident response action layer is the MCP layer that sits after monitoring alerts. Monitoring and observability tools help an AI assistant read signals: metrics, errors, telemetry, and alert context. mttrly gives Claude Code, Cursor, and Codex scoped tools to diagnose a live server, propose bounded remediation, create approval-gated actions, execute approved playbooks or command actions, and record the audit trail. It complements Grafana, Datadog, Sentry, and PagerDuty; it does not replace them.
For setup details, see the main mttrly MCP page and the MCP docs.
Monitoring MCP reads signals
Monitoring and observability MCP servers are strongest when the assistant needs to read context. They help answer what changed, what is failing, who is affected, and who needs to be paged.
Grafana / Prometheus
Metrics, dashboards, and alert signals that help teams see resource pressure, service health, and changing system behavior.
Sentry
Application errors and exception context that help teams understand failing code paths and user-impacting app failures.
Datadog
Telemetry, APM context, and alerts that help teams correlate infrastructure, application, and service-level signals.
PagerDuty
Alert routing and escalation workflows that get the right human into the incident response loop.
Which MCP or incident layer should you choose?
These tools solve different parts of the response loop. Pick the layer that matches the job instead of treating every MCP server as interchangeable.
| Option | Choose it when | Boundary |
|---|---|---|
| Datadog / Grafana MCP | The assistant mainly needs telemetry, dashboards, traces, and alert context. | Keep a separate execution layer for server remediation. |
| PagerDuty | Routing, escalation, incident ownership, and established runbook operations are the primary workflow. | It is broader incident process infrastructure, not a lightweight VPS agent. |
| Octopus Deploy + Polling Tentacle | Deployment automation and an outbound worker model are already part of the delivery platform. | Optimized around deployment automation rather than conversational VPS diagnosis. |
| Local MCP over SSH | You need maximum terminal flexibility and can design, secure, and audit the shell policy yourself. | A terminal-shaped interface has a wider blast radius than scoped incident tools. |
| mttrly | An ordinary Linux VPS needs scoped diagnostics, prepared actions, human approval, and an audit trail from an AI IDE or phone. | Requires the outbound agent and does not replace SSH or provider rescue access. |
Action MCP changes the incident
mttrly starts where alert context leaves off. It gives an AI assistant a bounded path to inspect the server, choose a safer remediation path, ask for approval, and preserve an audit trail. It pairs well with Telegram approval flows and with operating models that avoid raw shell access for routine response, such as managing a VPS without raw SSH as the normal control path.
Server-side outbound agent
The mttrly agent runs on the server and connects outbound, so the MCP client can work through mttrly without exposing a broad inbound control surface.
Scoped MCP tools
AI assistants discover available tools, limits, servers, diagnostics, playbooks, pending actions, and audit history through bounded MCP calls.
Diagnostics before action
mttrly supports targeted diagnostics so Claude Code, Cursor, or Codex can investigate server health before proposing a change.
Remediation playbooks
Prepared playbooks give the assistant a safer first path for known operational fixes, instead of defaulting to free-form command execution.
Approval gates
Approval-required actions normally create pending approvals for human review. A user-authorized, bounded mttrly_execute_command Investigation or narrowly configured preauthorization are explicit exceptions; both remain audited.
Audit log
Approvals, command actions, playbook runs, and results are recorded so the incident has a reviewable trail.
Telegram and mobile approval
The same action layer can route review and approval through Telegram, dashboard, or IDE confirmation flows when configured.
Action MCP vs monitoring MCP
| Row | Monitoring / observability MCP | mttrly action MCP |
|---|---|---|
| Primary job | Detect, visualize, correlate, and route incident signals. | Diagnose and remediate after a signal becomes an incident. |
| Typical question answered | "What is wrong, where is it happening, and who should know?" | "What can we safely check or fix next on this server?" |
| Data read | Metrics, dashboards, telemetry, application errors, events, and alert context. | Connected servers, health state, alerts, logs, diagnostics, playbook catalog, pending actions, and audit history. |
| Actions taken | Usually read, alert, route, or annotate incident context. | Runs diagnostics, creates approval-gated remediation, executes approved playbooks or scoped command actions when enabled. |
| Approval model | Typically outside the MCP read path, or handled by the incident process. | Approval-required changes normally create pending actions. A bounded mttrly_execute_command Investigation or narrowly configured preauthorization must be authorized separately and remains audited. |
| Audit trail | Alert history, event history, dashboard annotations, or incident timelines. | Approval decisions, requested actions, execution results, and diagnostic context in the mttrly audit log. |
| Best used with | Grafana, Prometheus, Datadog, Sentry, PagerDuty, and existing observability workflows. | Those same detection tools, plus Claude Code, Cursor, Codex, Telegram, and prepared remediation playbooks. |
For the broader positioning against traditional alerting and server monitoring, see mttrly vs monitoring tools.
Grafana alert -> Claude Code investigates -> mttrly remediates
A concrete response flow keeps the assistant inside clear boundaries: read context, run diagnostics, prefer prepared playbooks, ask for human approval, then verify and log the result.
Alert fires in Grafana, Datadog, or PagerDuty.
The AI assistant reviews the alert and the surrounding context available from the monitoring tool or incident thread.
The AI calls mttrly_get_capabilities to learn what tools, limits, and restrictions apply.
The AI calls mttrly_list_servers to select the affected server.
The AI calls mttrly_run_diagnostic with a focused incident description.
The AI lists remediation options with mttrly_list_playbooks.
The AI creates a pending remediation with mttrly_run_playbook when a suitable playbook exists.
A human approves or rejects the pending action from Telegram, the dashboard, or an IDE confirmation flow. The AI does not approve this for itself.
The result is verified and logged with mttrly_get_audit_log.
When to use both
The combined stack is simple: keep your detection and context tools, then put mttrly behind the assistant when the response needs a scoped server action.
- +Use Grafana, Datadog, Sentry, and PagerDuty for detection, context, routing, and escalation.
- +Use mttrly for scoped server diagnosis, approval-gated remediation, and mobile action after an alert fires.
- +Keep observability as the source of signals, then let the action layer help the assistant move through the response checklist.
- +Document what happened with audit history so the response can be reviewed after the incident.
This is especially useful for on-call response workflows where the first alert arrives while the responder is away from a laptop.
See the action layer in concrete incidents: start with the website-down playbook or browse all Linux incident playbooks.
When mttrly is not the right layer
mttrly is an incident action layer, not a replacement for every operations tool. Choose another primary layer when your main need is:
- -Pure metrics visualization or dashboarding.
- -Long-term observability storage as the primary requirement.
- -Distributed tracing as the main product need.
- -Incident communications or major incident command as the primary workflow.
- -Servers where the agent is offline or outbound connectivity is blocked.
FAQ
What is an incident response action layer?
An incident response action layer is the controlled execution layer that comes after monitoring detects a problem. It lets an AI assistant run scoped diagnostics, propose bounded fixes, request human approval for risky changes, execute approved remediation, and record what happened.
Is mttrly a monitoring MCP server?
No. mttrly is not primarily a monitoring MCP server. It can read server status, alerts, diagnostics, and audit history, but its role is the action layer after monitoring has detected or routed an incident.
Does mttrly replace Grafana or Datadog?
No. mttrly complements Grafana and Datadog. Use observability tools for metrics, dashboards, telemetry, APM context, and alerting. Use mttrly when an AI assistant needs scoped tools to investigate and remediate after an alert fires.
How does mttrly work with Sentry or PagerDuty?
Sentry can provide application error context, and PagerDuty can route or escalate the alert. mttrly then gives Claude Code, Cursor, or Codex a controlled path to inspect the affected server, request remediation, and review the audit trail.
Can Claude Code use mttrly to fix production incidents?
Claude Code can use mttrly MCP tools to investigate incidents and request remediation. Approval-required production changes normally create pending actions for human review. A bounded mttrly_execute_command Investigation or narrowly configured preauthorization must be authorized separately; the assistant must not self-authorize either path.
What requires human approval?
Approval-required remediation playbooks, scripts, file writes, repair, and update actions normally wait for human review. A user-authorized Investigation can skip per-command confirmation only for mttrly_execute_command within its server, inactivity, hard-cap, and action limits. Narrowly configured preauthorization applies only to the automation the user enabled. Both exception paths remain audited.
Can mttrly run only playbooks without command execution?
Yes. Teams can operate mttrly through read-only tools and prepared remediation playbooks, and keep command execution disabled or restricted where their plan, MCP client, or workspace policy supports that setup.
Add an action layer after your alerts
Start with read-only MCP tools, then add approval-gated playbooks when your team is ready to let the assistant help remediate production incidents.