Skip to main content

​
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.
  • 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

1

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

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 for the per-vendor detail.
3

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.

​
1b. Add an internal operations server

1

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.”
2

Register it

Name, HTTPS URL, transport, and the token. A custom auth header name is supported (default: Authorization: Bearer <token>).
3

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.

​
2. Discover and curate tools

Hit Discover tools to fetch the server’s catalog.
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.
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:
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.

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