MCP across a fleet
MCP for agents covers connecting and the tool list. This page is about what changes once there are many monitors and more than one person - the questions that only show up at scale.
One key, one organization
Section titled “One key, one organization”An MCP key belongs to exactly one organization, and that is deliberate. A person can be a member of several; a key cannot. If the organization were ambiguous, so would be the blast radius of every write.
That is also why a browser session does not authenticate MCP. A session says who you are; a key says who you are and what you may do and where. For an agent, the last two matter more than the first.
Choose the key by what the agent is for
Section titled “Choose the key by what the agent is for”| 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 does not see what it may not touch. Restricted to certain
projects or monitors, it finds only those in list_monitors and
list_incidents - everything else does not exist for it, with no way to probe
whether it might. Writes behave the same way: an out-of-scope ID reports “no such
monitor”, not “forbidden”. The difference matters, because “forbidden” is itself
an answer about what exists.
Organization-wide tools are simply not offered to a narrowed key -
get_organization_summary, list_status_pages, and create_monitor, the last
because it 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.
Two things an agent cannot do - and why
Section titled “Two things an agent cannot do - and why”Nothing is ever deleted through MCP. archive_monitor exists instead, and
that is not caution for its own sake: deleting a monitor cascades through eleven
tables and takes the incident history, the daily SLA rollups and the exclusion
windows with it. For a product whose whole point is evidence, an agent call must
not be able to do that.
Archiving answers the same need without the damage: the service stops being
checked, disappears from the lists, and gives its slot in your plan back,
while everything it ever recorded stays. restore_monitor brings it back
(paused). The way back must not depend on memory, so list_monitors with
archived: true shows the archive and get_monitor finds archived entries -
otherwise an archived monitor would be unreachable the moment somebody lost the
ID.
Host agents are out of reach entirely. No MCP tool enrolls, lists or removes one. If your fleet work is about rolling out agents, that runs through the interface - see Rolling out host agents.
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 - which is the point, because acknowledgement 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, prefer many narrowed keys over one broad key. A single key shared by four automations is one revocation away from breaking all four, and the audit trail cannot tell you which of them acted.