Documentation Index
Fetch the complete documentation index at: https://docs.scaling.cloud/llms.txt
Use this file to discover all available pages before exploring further.
The Scaling MCP server exposes ten tools today, split into read tools (safe to call freely) and mutation tools (create or change state). Any compliant MCP client will also surface this list at runtime via tools/list with full input schemas — this page is a static overview.
All tools are scoped to the caller’s organization, resolved server-side from the OAuth token. You cannot read or write data in another org through this server.
| Tool | What it does |
|---|
list_incidents | List incidents in the caller’s organization, optionally filtered by status. |
get_incident | Get full incident details by sequential id, scoped to the caller’s organization. |
get_incident_timeline | Get the ordered timeline of events (status changes and paging events) for an incident, looked up by its sequential id. |
list_schedules | List on-call schedules in the caller’s organization. |
who_is_on_call | Return the current on-call user(s) in the caller’s organization. |
| Tool | What it does |
|---|
create_incident | Manually create (page) a new incident in the caller’s organization. |
post_incident_update | Append a timestamped, authored update to an incident’s timeline. |
acknowledge_incident | Acknowledge a paged incident, stopping further escalation. |
resolve_incident | Mark an incident as resolved. |
transition_incident_status | Advance an incident through its fixed lifecycle (investigating → identified → monitoring → resolved). |
post_incident_update — visibility
post_incident_update requires the caller to commit to a visibility on every call. There is no default — the model must pick.
| Parameter | Required | Values | Notes |
|---|
sequentialId | yes | positive integer | The incident’s per-org sequential id. |
body | yes | 1–10,000 characters | The update text. |
visibility | yes | internal | public | public publishes the update on your org’s status page (customer-visible). internal is staff-only and never reaches the public page. |
statusChange | no | investigating | identified | monitoring | resolved | If provided, transitions the incident’s lifecycle in the same write. |
idempotencyKey | no | 1–128 characters | See Idempotency below. |
Errors
| Code | When it fires |
|---|
NO_PUBLIC_SURFACE | visibility=public but the org has no published status page whose components overlap with this incident’s affected components. The update is rejected before any write. |
INCIDENT_RESOLVED_NO_FURTHER_UPDATES | The incident is already resolved. Resolved incidents are terminal — no further updates can be posted at any visibility. |
Idempotency
Every mutation that creates a new record (create_incident, post_incident_update) accepts an optional idempotencyKey. Acknowledge, resolve, and transition_incident_status are idempotent by nature — retrying them on an incident that is already in the requested state returns success without emitting a duplicate audit event.
When you pass an idempotencyKey:
- A second call with the same key returns the existing record. No duplicate incident, no duplicate update, no duplicate
incident.created event.
- First write wins. If the second call carries a different payload (different
title, body, etc.), the original record is returned unchanged and the new arguments are silently ignored. To create a distinct record, supply a different key.
- Keys are scoped per-organization for incidents, and per-incident for updates. Reuse across orgs is safe.
- Concurrent retries hitting the same key from two clients at once both resolve to the same winning record — no error returned.
Generate idempotency keys client-side per logical operation, not per call. A natural pattern is a UUID per “the user asked the agent to do X.”
Permissions
Today every connected client gets the same broad scope across all ten tools. Granular per-tool scopes are tracked separately — until then, revocation (in Settings → Connections) is the only way to limit a client. See the MCP overview for connection management.