Plug an AI agent into your monitoring

Pointing an AI agent at production is a trust decision, so it is worth being precise about where the ceiling comes from. It is not a setting you have to get right, and it is not a promise about how the model behaves. It holds at three independent layers:

• On a read connection there is no write tool. A read-scoped connection is served the 47 read tools and nothing else - the write tools are not hidden behind a refusal, they are not registered at all, so there is no destructive action available to call. Every served tool declares itself read-only in its protocol annotations, which careful clients verify for themselves.
• OAuth connections are read-scoped, full stop. Connecting through OAuth issues a read scope, and a write scope is not something these connections can request. Write access exists only through an API token you explicitly minted with write scope in Settings - a deliberate human act, never a consent-screen checkbox.
• Permission is re-checked per request. The connecting account has to still hold the matching permission in your organization - read access for reads, the resource's own create/update permission for each write. Remove someone from the team and their agent stops working on its next call, without anyone remembering to go and revoke a token.

What an agent can see is exactly what that account can see in the web app, in one organization, and never more. What a write-scoped agent can do is bounded the same way - and every write tool takes a dry-run flag, so an agent can validate a change without making it.

With a write-scoped API token, an agent can also set monitoring up rather than only read it: create_uptime_monitor and update_uptime_monitor (say "monitor this endpoint from every region" and it is checking within the minute), create_task and update_task (the response hands back the ping URL to paste into the crontab), and create_maintenance_window and cancel_maintenance_window (announce tonight's deploy on your status page so it reads as maintenance, not an outage).

The next part is the on-call loop. An agent could already pull an incident apart with incident_context; now it can act on what it found. acknowledge_incident puts a name against it, mute_incident and unmute_incident silence a flapping alert overnight without pretending it is fixed, and resolve_incident closes it. comment_incident posts the update your status-page visitors and email subscribers actually receive, and set_incident_visibility decides whether an incident is on that page at all.

And it can operate the alerting itself: create_workflow_from_template turns a template from the gallery into a working alert wired to your verified email channel (or emailing all members until one is verified) - a draft that pages nobody until activate_workflow starts it - and pause_workflow silences one while you work on what it watches, reversibly, keeping the graph and every run. Authoring a workflow's node graph over MCP is deliberately not offered, and neither is touching an archived workflow: templates are the safe path in, and restoring from the archive stays a dashboard decision.

The rest are the remediation verbs - the things an on-call runbook actually does. set_host_maintenance and set_hosts_maintenance_bulk silence a host - or "the db group", by the same filters the instance API takes, in one call - for a planned deploy while its agent keeps reporting; set_device_maintenance does the same for a switch. pause_monitor/resume_monitor and pause_task/resume_task stand checks down and rearm them. check_monitor_now is the "is it fixed yet?" call - it spends the same manual-check budget as the dashboard button, so an agent cannot hammer it. enable_host/disable_host switch monitoring off entirely, and recheck_host_permissions asks the agent to re-detect what it can collect after you fix permissions on the box.

The shape is deliberate. Every one validates first and takes dry_run, so a cautious agent - or a cautious operator's policy - can check "would this be accepted?" (or preview a bulk filter's blast radius) without changing anything. Plan limits come back as "limit reached (N of M)" so an agent proposes an upgrade instead of retrying. Windows are canceled, never deleted, so history survives. The bulk call reports per-instance outcomes, so a partial application reads as partial. And nothing in the set deletes anything at all: deletes stay a human decision in the dashboard.

The ones that reach past your account are treated as such. Posting an update and publishing an incident are the only actions here that put words in front of your customers, so they are named separately on the consent screen rather than folded into "work through incidents", they declare themselves in their protocol annotations, and each says in its own description who ends up reading the result. An agent that resolves an incident to quiet an alert is told, in the tool description, that mute is the tool it wanted. And check_monitor_now, which fires real probes at the endpoint you configured from our infrastructure, declares itself open-world in its annotations for the same reason - a careful client can see which calls leave the account without trusting prose.

Most of the tools are the obvious ones: list this, fetch that. Two are shaped differently, because an agent assembling a picture out of six round trips is slow and tends to stop early.

investigate_host takes one server and returns its details, its recent CPU and memory, and its most recent incidents together. That is the first question anyone asks about a box, answered in a single call.

incident_context takes one incident and returns it with its timeline, the affected instance, that instance's recent CPU and memory, and the log digests captured when it opened, including the error patterns that appeared for the first time around that moment. On a Linux host with log monitoring enabled, that means an agent starts an investigation with the lines from when things actually broke rather than a blank page.