> ## 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. # Available tools > The MCP tools exposed by the scaling.cloud MCP server, what they do, and the idempotency contract for mutations. The scaling.cloud MCP server exposes eleven 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. {/* Run `pnpm docs:generate` after changing a tool's name, description, or kind. */} ## Read tools | Tool | What it does | | -------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | `list_incidents` | List incidents in the caller's organization, optionally filtered by status. | | `list_inbox` | List inbox items for the calling user in the caller's organization. | | `list_components` | List components in the caller's organization, including their aliases (external identifiers alert tooling uses). | | `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. | | `list_routing_policies` | List routing policies in the caller's organization. | | `get_routing_policy` | Get a routing policy by id, including its four per-severity rules, scoped to the caller's organization. | | `list_escalation_policies` | List the escalation policies in the caller's organization. | | `get_escalation_policy` | Get an escalation policy by id, scoped to the caller's organization, including its ordered steps. | | `list_working_hours` | List the named working hours sets in the caller's organization. | | `get_working_hours` | Get a working hours set by id, scoped to the caller's organization. | ## Mutation tools | 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). | | `change_incident_severity` | Re-assess an open incident's severity (critical \| high \| medium \| low). | | `create_routing_policy` | Create a named, non-default routing policy in the caller's organization. | | `update_routing_policy` | Re-point a routing policy's four per-severity rules, and optionally rename it or change its description, scoped to the caller's organization. | | `delete_routing_policy` | Delete a non-default routing policy in the caller's organization. | | `create_escalation_policy` | Create an escalation policy in the caller's organization with an ordered list of `steps`. | | `update_escalation_policy` | Replace an escalation policy in the caller's organization, atomically rewriting its name, description, and full ordered `steps` list. | | `delete_escalation_policy` | Delete an escalation policy in the caller's organization. | | `create_working_hours` | Create a named working hours set in the caller's organization. | | `update_working_hours` | Update a working hours set in the caller's organization. | | `delete_working_hours` | Delete a working hours set in the caller's organization. | ## `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](#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 eleven 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](/integrations/mcp) for connection management.