MCP across a fleet
MCP for agents covers connecting and the tool list. With many monitors and several teams, a few more questions come up, and the answers below keep every agent precise.
One key, one organization
Section titled “One key, one organization”An MCP key belongs to exactly one organization. A person can belong to several organizations, and a key always names one, so the reach of every write is clear.
For the same reason, MCP authenticates with keys and OAuth tokens rather than browser sessions. A session says who you are. A key says who you are, what you may do, and where, and for an agent the last two matter most.
Match the key to the agent’s task
Section titled “Match the key to the agent’s task”| The agent … | Key |
|---|---|
| answers “how are we doing” across everything | organization-wide, read scopes |
| works on one team’s services | narrowed to those projects |
| runs unattended in CI | narrowed, with the smallest scope that works |
| is driven by a person right now | OAuth, so actions carry that person’s name |
A narrowed key sees exactly what it may touch. Restricted to certain projects or monitors,
it finds those in list_monitors and list_incidents, and everything else is invisible to it,
with no way to probe whether it exists. Writes behave the same way: an out-of-scope ID reports
“no such monitor” instead of “forbidden”. The difference matters, because “forbidden” is itself
an answer about what exists.
Organization-wide tools stay with organization-wide keys: get_organization_summary,
list_status_pages, create_project, and create_monitor. The create tools would otherwise
write into projects the key knows nothing about.
One call for the whole picture
Section titled “One call for the whole picture”At fleet size, the useful entry point is get_organization_summary: services per state and open
incidents in a single call. Reach for it before list_monitors, which is the tool for working on
something specific rather than for getting oriented.
Archiving keeps the evidence
Section titled “Archiving keeps the evidence”An agent retires a service with archive_monitor. Deleting a monitor would cascade through
eleven tables and take the incident history, the daily SLA rollups, and the exclusion windows
with it, so for a product built around evidence, MCP offers archiving.
Archiving covers everything a retirement needs: checks stop, the service leaves the active
lists, and its slot in your plan returns, while its history stays under the normal retention
rules. restore_monitor brings it back paused. list_monitors with archived: true shows the
archive, and get_monitor finds archived entries, so the way back never depends on somebody
remembering an ID.
Host agents run through the app and REST
Section titled “Host agents run through the app and REST”Host agents are enrolled in the app, and the REST API lists and removes them with a scoped key. MCP creates and manages the monitors on top of them. Rolling out host agents walks through a roll-out.
Every action carries a name
Section titled “Every action carries a name”Actions taken through MCP are attributed. With an API key, the actor is the person who created it. With OAuth, it is the signed-in person who consented. Acknowledging an incident through an agent puts a name on it exactly as it would in the app, and that is the point, because an acknowledgment is a statement about who is handling it. See From measurement to alarm.
Revoking
Section titled “Revoking”- API key: delete it. Everything it could do stops.
- OAuth: disconnect the application, or remove the person’s membership. Their access goes with it.
At fleet scale, give each automation its own narrowed key. You can then revoke one without touching the others, and the audit trail names exactly which one acted.
- MCP for agents: connecting, authentication, and every tool.
- API: scoped keys for pipelines and scripts.