Skip to main content
The scaling.cloud MCP server lets your AI client read and act on your scaling.cloud data — incidents, on-call schedules, components, and more — over the Model Context Protocol. Authentication uses standard OAuth 2.1 with dynamic client registration, so a compliant client can connect without you copying API keys around.

​
Server URL

Use this URL in Claude.ai’s Connectors UI, in Claude Desktop’s MCP config, or in ChatGPT’s Connector / Custom GPT setup. The client will discover the OAuth metadata at /.well-known/oauth-authorization-server and walk you through sign-in automatically.

​
Setup guides

Claude.ai (web)

Claude Desktop

ChatGPT

​
What the server can do

See Available tools for the ten tools the server exposes — list and get incidents, walk on-call schedules, create or acknowledge incidents, advance incident status, post incident updates (with explicit visibility — internal vs public) — plus the idempotency contract for mutations.

​
Managing your connections

Every client you connect appears under Settings → Connections in the scaling.cloud dashboard, with the client name, organization scope, when it was first connected, and when it was last used. Click Revoke to immediately invalidate a client’s access. Subsequent tool calls from that client return 401 Unauthorized until the client re-authorizes through the OAuth flow.

​
Multi-organization users

Connections are scoped to a single organization. If you belong to more than one scaling.cloud organization, the consent screen shows an organization selector during the OAuth handshake — every tool call from that client then operates on the organization you picked. To work with a different organization, connect the client again and select it on the consent screen. Connections authorized before organization selection existed are not org-scoped; if you have since joined a second organization, revoke the old connection and re-authorize.

​
Security: untrusted content in incident data

Incident titles, descriptions, and the bodies of internal incident updates are returned verbatim to the AI client by get_incident, get_incident_timeline, and list_incidents. Any text written into an incident — including by webhooks, integrations, or other users in your organization — flows straight into the model’s context window. This is normal for read tools, but means a teammate (or an automated integration) can plant instructions that your AI agent later reads as if they were yours. Do not paste output from untrusted systems into an incident update unless you’re comfortable with your AI client acting on it. The same caution applies to post_incident_update from the model’s side: the tool requires the model to commit to visibility: 'internal' | 'public' on every call (no default). A public update reaches customers on your status page — make sure your client surfaces the visibility choice in its UI so a human can spot a mis-commit before submission. If you operate the AI client, treat tool output as data, not instructions — the same way you would treat any other tool-returned string.

​
Limitations

  • Granular per-tool scopes are not yet exposed. Each grant gets the same broad scope set; revocation is the only way to limit a client today.
  • Tokens are issued by Clerk and are short-lived (default 1 hour). Clients refresh transparently.
  • Audit log of MCP activity lives in CloudWatch (server-side) but is not yet surfaced in the dashboard.