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

# Set up MCP Actions

> Connect external connectors and internal operations servers, discover their tools, and decide — tool by tool — what WHAWIT may call and what needs a human

## Prerequisites

* An MCP server reachable over **HTTPS** (Streamable HTTP or SSE transport). Private and
  internal addresses (localhost, metadata endpoints, RFC-1918 ranges) are rejected by
  design — the server must be reachable from outside your network.
* A **bearer token** (or custom auth header) for the server. OAuth-only servers are not
  supported yet — the catalog marks those **Coming soon**.
* The *manage integrations* capability in WHAWIT (organization admins have it).

## The page: two groups, two flows

Open **MCP Servers** in the app sidebar (`/ops/mcp`) — or find the **MCP Server** card on
the Integrations page, which takes you there. The left rail lists your servers in two
groups, each with its own **+** button:

* **External connectors** — vendor context for the agents: GitHub, Sentry, Grafana… Adding
  one starts from the [curated catalog](/mcp-actions/connectors).
* **Internal operations** — your own levers: runbooks, automation, incident fixes. Adding
  one opens the editor directly.

A server's kind is **fixed at creation** and shown as a badge on its detail view
(**External connector** / **Internal operations**). To reclassify one, delete it and
re-create it under the other group — the allow-list and credential go with the deletion.

## 1a. Connect an external connector

<Steps>
  <Step title="Open the catalog">
    Press **+** on the **External connectors** group. The picker shows the well-known
    vendors — pick one to start from its endpoint and token instructions, or choose
    **Custom connector** for any vendor-hosted server not listed.
  </Step>

  <Step title="Paste the token">
    The editor arrives pre-filled with the vendor's endpoint, transport and auth header —
    every field stays editable. Each template explains where to mint the token and links
    the vendor's own **Server docs**. See [the catalog page](/mcp-actions/connectors) for
    the per-vendor detail.
  </Step>

  <Step title="Connect">
    Flip **Enabled** and press **Connect server**. The token goes to a secret manager and
    is never shown again; WHAWIT's database only records that credentials exist.
  </Step>
</Steps>

## 1b. Add an internal operations server

<Steps>
  <Step title="Open the editor">
    Press **+** on the **Internal operations** group: *"A server you run that exposes your
    own operations — restart a service, flush a queue, run a runbook. Its tools stay
    behind the org's approval gate."*
  </Step>

  <Step title="Register it">
    Name, HTTPS URL, transport, and the token. A custom auth header name is supported
    (default: `Authorization: Bearer <token>`).
  </Step>

  <Step title="Test the connection">
    On the saved server, **Test connection** performs a live handshake and reports latency
    and how many tools the server exposes — nothing is executed and nothing is persisted.
  </Step>
</Steps>

## 2. Discover and curate tools

Hit **Discover tools** to fetch the server's catalog.

<Warning>
  Every discovered tool arrives **denied**. WHAWIT will not call — or even offer to its
  agents — a tool you have not explicitly allowed. This holds for both kinds.
</Warning>

For each tool you flip two switches:

* **Allowed** — WHAWIT may call it (agents, Radar, and the incident's Run action).
* **Requires approval** — every call files an approval request for a human instead of
  executing. The default at first allow depends on the kind: **internal operations tools
  inherit your organization's approval policy; connector tools default to off** so agents
  keep usable read context even in strict organizations. Both are editable per tool
  afterwards — flag any connector tool that mutates (creating issues, merging PRs) if you
  want it gated.

A tool your server stops exposing is marked **stale** but keeps its curation — a flaky
discovery never silently un-allows anything.

## 3. Set the organization policy

On **Policies** (`/policies`), the **MCP actions** card holds the coarse controls:

| Control                           | Effect                                                                                                                                                           | Default |
| --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
| Allow MCP actions                 | Master switch — off means nothing executes, for anyone, on either kind                                                                                           | On      |
| Require approval for every action | Forces human approval for every **internal operations** call regardless of per-tool flags. External connector tools are governed by their own per-tool flag only | On      |
| Daily limit                       | Hard budget of executions per organization per day, reserved atomically and **shared across both kinds**                                                         | 200     |

<Note>
  Because the daily budget is shared, a chatty connector can consume executions that your
  internal operations would otherwise use. Watch the calls counter on the rail if agents
  lean on a connector heavily.
</Note>

## Good practices

**For your internal operations server:**

* Expose **narrow, named actions** (`restart-checkout`, `flush-search-cache`) rather than
  generic escape hatches (`run-shell-command`). The allow-list is only as meaningful as the
  tools behind it.
* Give tools **clear descriptions and typed input schemas** — agents read them to decide
  when a tool applies, and the incident dialog builds its argument form from them.
* Keep destructive tools behind **Requires approval**; let read-only or low-risk tools run
  autonomously so agents can act fast when it is safe.
* **Rotate the token** periodically; updating it in WHAWIT takes effect on the next call.

**For external connectors:**

* Scope the vendor token to what the agents should see — a fine-grained GitHub token over
  the relevant repositories beats an org-wide one.
* Allow read tools broadly; that is what connectors are for. Be deliberate with vendor
  write tools (create issue, merge PR) — they mutate, and the org-wide approval gate does
  not cover them, so flip **Requires approval** on those yourself.

<Note>
  Servers connected before the connector/internal split reads as **Internal operations**
  — the stricter profile they were created under. Nothing was silently relaxed. If you
  connected GitHub or Sentry from the catalog before the split and want the relaxed
  connector governance, delete the server and re-add it through the External connectors
  flow.
</Note>