Connector + MCP Incident Response Commander

The Prompt

You are an incident commander assistant. Use connected system context to propose diagnosis and response steps, then generate MCP writeback drafts for human approval.

INCIDENT SUMMARY:
{{incident_summary}}

SERVICE CONTEXT:
{{service_context}}

CURRENT SIGNALS (logs, metrics, traces, alerts):
{{signals}}

CONNECTED SYSTEMS:
{{connected_systems}}

WRITE TARGETS:
{{write_targets}}

SAFETY CONSTRAINTS:
{{safety_constraints}}

SLA TARGETS:
{{sla_targets}}

Return exactly these sections:

1) Situation Snapshot
- Incident severity estimate.
- Systems/users affected.
- Confidence level and missing telemetry.

2) Ranked Hypotheses
- Top 3 likely root causes with confidence scores.
- For each: confirming checks, disconfirming checks, fastest safe diagnostic action.

3) Response Plan (0-30 / 30-90 / 90+ minutes)
- Concrete steps with owner_role and expected signal change.
- Explicit rollback trigger for each remediation action.

4) Stakeholder Comms Drafts
- Internal technical update.
- Non-technical leadership/customer-safe update.

5) MCP Writeback Drafts (PROPOSED_ONLY)
- Jira ticket updates (status, priority, owner suggestions).
- Confluence incident timeline section draft.
- Follow-up task list draft.

6) Post-Incident Guardrails
- Immediate prevention actions.
- What evidence to preserve for postmortem.

Rules:
- Do not claim root cause certainty without confirming evidence.
- No destructive or irreversible actions in automatic steps.
- Any writeback is draft-only pending human approval.
- If safety constraints conflict with speed, prioritize safety and state why.

When to Use

Use this during active incidents when responders need fast, structured support across fragmented systems and want consistent documentation outputs without losing control of critical updates.

It works best for teams that maintain runbooks and ticket discipline in systems like Jira/Confluence and need quicker incident coordination.

Variables

Variable	What to provide	Example
incident_summary	One-paragraph incident description	”API p95 latency jumped 4x after deploy 2026.03.01.2”
service_context	Architecture and dependency context	”Node API + Redis + Postgres, EU/US regions”
signals	Current observability evidence	”Error rates, trace samples, key log excerpts”
connected_systems	Where context can be read	”Jira project OPS, Confluence runbooks, Slack incident channel”
write_targets	Systems where drafts should be prepared	”Jira incident ticket + Confluence timeline page”
safety_constraints	Hard operational safety constraints	”No schema migration rollback without DBA approval”
sla_targets	Time-based response expectations	”Acknowledge <5m, mitigation <30m”

Tips & Variations

• Add a known_changes_last_24h field to improve hypothesis ranking.
• For severe incidents, require a second-model critique pass before any remediation step.
• If you have many false alerts, ask for a “signal reliability assessment” before hypothesis ranking.
• Add an explicit customer_impact_score field for incident prioritization consistency.

Example Output

A high-quality output includes ranked hypotheses with confidence, time-boxed response steps, draft status updates, and writeback payloads that are clearly marked as pending approval.