> ## 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.

# MCP Actions

> Connect MCP servers so WHAWIT's agents can see more and do more — vendor connectors for context, your own internal operations for fixes — curated tool by tool, governed by policy, audited on the incident

## Not every incident is fixed with a pull request

WHAWIT observes your systems through its integrations, and it can fix code through the
Coder. But most incidents are resolved by *doing something operational*: restarting a
service, flushing a queue, rolling a feature flag back, running an internal runbook. And
most investigations go faster when the agents can look at the systems around the failure —
the GitHub repository, the Sentry issues, the Grafana dashboards.

**MCP Actions** closes both gaps with the [Model Context Protocol](https://modelcontextprotocol.io).
WHAWIT distinguishes two kinds of MCP server, managed side by side on the **MCP Servers**
page:

<CardGroup cols={2}>
  <Card title="External connectors" icon="plug">
    A vendor's context surface — GitHub, Sentry, Grafana, PagerDuty, Honeycomb, Linear —
    that gives the agents **read context** while they investigate. Connected from a
    [curated catalog](/mcp-actions/connectors) that prefills the endpoint and token
    instructions.
  </Card>

  <Card title="Internal operations" icon="terminal">
    **Your own operational levers** — a server you run that exposes runbooks, restarts,
    automation and incident fixes. This is where WHAWIT acts on your infrastructure, and
    where governance is strictest.
  </Card>
</CardGroup>

The two kinds share one machinery — discovery, deny-by-default curation, the daily budget,
the audit trail — but they are governed differently, because reading a dashboard and
restarting a service are not the same risk.

## What you get

<CardGroup cols={2}>
  <Card title="Agents act when it helps" icon="robot">
    The on-call agent teams and Radar can call your allowed tools at their discretion while
    investigating — connectors for evidence, internal operations for fixes — under the same
    governance as everyone else.
  </Card>

  <Card title="Incidents resolve operationally" icon="bolt">
    Every incident gets a **Run action** button. Execute an allowed tool with arguments,
    and the outcome lands on the incident timeline.
  </Card>

  <Card title="You curate every tool" icon="list-check">
    Discovery is deny-by-default: WHAWIT can only call the tools an admin explicitly
    allowed. Internal operations inherit your approval policy; connector tools run
    unattended unless you flag them.
  </Card>

  <Card title="Everything is audited" icon="clipboard-check">
    Executions, failures, approvals and rejections are recorded on the incident — and feed
    Operational Memory, so WHAWIT learns which actions resolve which problems.
  </Card>
</CardGroup>

## Why your internal server stays the control point

Your internal actions — the script that restarts `checkout`, the job that reindexes
search — are yours, and they change at your pace. Exposing them through **your** internal
operations server means:

* **You curate the surface.** WHAWIT sees only what your server exposes, and calls only
  what you allow.
* **You keep the keys.** The server runs in your infrastructure; WHAWIT authenticates with
  a bearer token you can rotate or revoke at any time. The token is stored in a secret
  manager, never in WHAWIT's database.
* **One protocol, any tool.** Anything you can wrap in an MCP tool — shell scripts,
  Kubernetes operations, database maintenance, feature flags — becomes available without a
  new integration.

External connectors are the mirror image: the vendor hosts the server, you supply a token
scoped to what the agents should see, and WHAWIT treats the tools as read context rather
than as levers.

## Governance guarantees

| Guarantee               | What it means                                                                                                                                     |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| Deny-by-default         | Discovery never enables anything; only an admin's explicit **Allow** does — for both kinds                                                        |
| One execution path      | Agents, Radar and humans pass the same policy checks — no caller bypasses governance                                                              |
| Kind-aware approvals    | The org-wide **Require approval for every action** gate covers **internal operations only**; connector tools are gated by their own per-tool flag |
| Exact-payload approvals | What an approver sees is byte-for-byte what will be sent                                                                                          |
| Bounded blast radius    | Per-organization daily budget — shared across both kinds — per-call timeout, no automatic retries                                                 |
| Full audit              | Every outcome on the incident timeline, feeding Operational Memory                                                                                |

<Note>
  Three directions, three different features. **External connectors** are MCP servers
  WHAWIT reads for context. **Internal operations** are MCP servers WHAWIT calls to act on
  your systems. And using **WHAWIT itself as an MCP server** from Cursor, VS Code or Claude
  Code is [WHAWIT MCP Server](/ai-tools/mcp-server) under Developer Tools. Neither of these
  is the same as [Integrations](/concepts/integrations), the providers WHAWIT ingests
  telemetry from.
</Note>

## Next steps

<Steps>
  <Step title="Connect a vendor from the catalog">
    [Browse the connector catalog](/mcp-actions/connectors) — GitHub, Sentry, Grafana,
    PagerDuty, Honeycomb and Linear are a token paste away.
  </Step>

  <Step title="Connect and curate your servers">
    [Set up MCP Actions](/mcp-actions/setup) — both flows, discovery, the allow-list, and
    the organization policy.
  </Step>

  <Step title="Resolve incidents with it">
    [Run actions from incidents and agents](/mcp-actions/resolving-incidents) — the Run
    action button, agent usage, and the approvals queue.
  </Step>
</Steps>