> ## Documentation Index
> Fetch the complete documentation index at: https://docs.whawit.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Resolving incidents with MCP

> Run an action from the incident, let the agents act during investigation, and decide the calls that need a human — with the exact payload in front of you

## From the incident: Run action

Open an incident → **Run action**. Pick a tool — the select groups them by server and
kind, `Internal ops · <server>` first, then `Connector · <server>`, because this dialog
exists to act on the incident and connectors are the supporting cast. Fill the arguments —
the form is generated from the tool's input schema, with a raw-JSON fallback for complex
schemas — and execute.

The outcome lands on the incident timeline as an **MCP action** event: who ran what, on
which server, with which arguments and result. Four outcomes are possible:

| Outcome              | What happened                                                                             |
| -------------------- | ----------------------------------------------------------------------------------------- |
| **Executed**         | The tool ran; the result summary is on the timeline                                       |
| **Pending approval** | The tool requires a human — the request was filed in the approvals queue                  |
| **Denied**           | Governance refused (tool not allowed, policy off, daily budget exhausted) with the reason |
| **Failed**           | The server errored or timed out; WHAWIT never retries a side effect on its own            |

## By the agents

The on-call agent teams and Radar see your allowed tools alongside their built-in ones,
tagged by kind — `[MCP connector · <name>]` for vendor context, `[MCP action · <name>]`
for internal operations — with a warning attached to any tool whose call would file an
approval request instead of executing. They decide *when* a tool is worth calling;
governance decides *whether* it runs — the same single execution path a human uses, with
the agent as the recorded actor.

When a tool needs approval, the agent does not block or retry: it files the request,
reports that it is waiting on a human, and continues the investigation.

## The approvals queue

Pending requests live at **MCP Servers → Approvals** (`/ops/mcp/approvals`). Each card
shows:

* **The exact payload** — server, tool and arguments, verbatim. What you approve is
  byte-for-byte what is sent.
* Who requested it (an operator, or an agent) and why.
* The linked incident, when there is one.
* An expiry countdown — requests expire after 60 minutes undecided.

**Approve** re-checks the daily budget and executes the stored payload unchanged, recording
the result on the approval and the incident. **Reject** records your note for the
requester.

<Note>
  Approving is a decision, not a rubber stamp: the payload in front of you is exactly what
  reaches your infrastructure.
</Note>

## Audit and learning

Every MCP outcome — executed, failed, pending, rejected — is a timeline event on the
incident, distinguishable between human- and agent-initiated. Those events feed
**Operational Memory**, so resolutions through your MCP server teach WHAWIT which actions
actually fix which problems — and future investigations arrive with that knowledge
attached.