Incident tools

The automated incident responder, from the agent’s side: reading incidents, approving a proposed action, and raising one.

Permission is what the tool server requires before it dispatches; who holds it is read from the control plane’s own grant. The two are read from different places on purpose: a tool server that grants more than the control plane does offers an operation and then has it refused halfway through a conversation.

Advertised says whether the tool appears in the default tool list. Most do not: a small window is advertised and the rest are found with search_tools, read with describe_tool and invoked with request_tool. A tool reached that way is checked against the same permission as a direct call.

Generated from Tool. Hand edits to this table are overwritten on the next build — change the Go doc comment, or the generator.

Tool	Permission	Who holds it	Advertised
sre_approve_action	sre:approve	operator	no
sre_config	sre:read	developer, operator, readonly, support	no
sre_health	sre:read	developer, operator, readonly, support	no
sre_incident_detail	sre:read	developer, operator, readonly, support	no
sre_incidents	sre:read	developer, operator, readonly, support	no
sre_trigger_incident	sre:trigger	operator	no

sre_approve_action

Approve a pending SRE remediation action. When the SRE Orchestrator proposes actions that require approval (based on risk level or configuration), use this tool to approve and execute them. The action will be executed with full safety guardrails.

Argument	Type	Required	Meaning
incident_id	string	yes	The incident ID containing the action to approve
action_id	string	no	The specific action ID to approve (if multiple pending)
approved	boolean	yes	Set to true to approve, false to reject
reason	string	no	Reason for approval/rejection (for audit trail)

sre_config

View the current SRE Orchestrator configuration including automation level, guardrails, blacklists, and notification settings.

Takes no arguments.

sre_health

Check the health status of the SRE Orchestrator. Returns status of all components (Consul, Docker, Claude Code, Notifications) and incident statistics.

Takes no arguments.

sre_incident_detail

Get detailed information about a specific SRE incident, including full context, all actions taken or proposed, and Claude’s analysis. Always returns complete data.

Argument	Type	Required	Meaning
incident_id	string	yes	The incident ID to retrieve (can be short 12-char or full ID)

sre_incidents

List SRE incidents with optional filtering. Returns incidents processed by the SRE Orchestrator. Use format=‘summary’ (default) for browsing, ‘standard’ for operations, ‘full’ for debugging. Use sre_incident_detail for complete information about a specific incident.

Argument	Type	Required	Meaning
status	one of all, new, investigating, remediating, pending_approval, resolved, escalated	no	Filter by incident status (default: all)
severity	one of all, critical, warning, info	no	Filter by severity level (default: all)
container	string	no	Filter by container name
limit	integer	no	Maximum number of incidents to return (default: 20)
offset	integer	no	Number of incidents to skip for pagination (default: 0)
format	one of summary, standard, full	no	Response detail level: summary (minimal, default), standard (operational), full (complete)

sre_trigger_incident

Manually trigger an SRE incident for a container. Use this to escalate issues you’ve identified that need automated investigation and remediation. The SRE Orchestrator will gather context, invoke Claude Code for analysis, and propose/execute remediation actions.

Argument	Type	Required	Meaning
container_name	string	yes	Name of the container experiencing the issue
alert_name	string	yes	Name/type of the alert (e.g., ‘HighCPU’, ‘OOMKilled’, ‘Unhealthy’)
severity	one of critical, warning, info	yes	Severity level of the incident
description	string	no	Description of the issue being escalated