Skip to main content

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 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

https://mcp.scaling.cloud
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 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

The MVP MCP server only supports users that belong to a single Scaling organization. If you’re a member of more than one org, the OAuth handshake will succeed at Clerk but the MCP server will reject your token until org-selection is implemented (tracked separately).

​
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.