Skip to main content

​
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. WHAWIT distinguishes two kinds of MCP server, managed side by side on the MCP Servers page:

External connectors

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 that prefills the endpoint and token instructions.

Internal operations

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

Agents act when it helps

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.

Incidents resolve operationally

Every incident gets a Run action button. Execute an allowed tool with arguments, and the outcome lands on the incident timeline.

You curate every tool

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.

Everything is audited

Executions, failures, approvals and rejections are recorded on the incident — and feed Operational Memory, so WHAWIT learns which actions resolve which problems.

​
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

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 under Developer Tools. Neither of these is the same as Integrations, the providers WHAWIT ingests telemetry from.

​
Next steps

1

Connect a vendor from the catalog

Browse the connector catalog — GitHub, Sentry, Grafana, PagerDuty, Honeycomb and Linear are a token paste away.
2

Connect and curate your servers

Set up MCP Actions — both flows, discovery, the allow-list, and the organization policy.
3

Resolve incidents with it

Run actions from incidents and agents — the Run action button, agent usage, and the approvals queue.