MCP and agents

Next to every page

https://<page>/mcp (and statoss.com/s/<address>/mcp) is a read-only MCP server with no key: get_status, list_incidents and get_error_budget. On a password-protected or private page it takes the page's key as ?key=.

Over the account

https://statoss.com/api/v1/mcp with an API key as a bearer token. Read keys get list_pages, get_status, list_monitors, list_incidents and get_page_access; write keys add:

• Pages: create_page, update_page (name, address, words, how it looks) and delete_page.
• Own domain: set_custom_domain, check_custom_domain and remove_custom_domain. The answer says which DNS record to add.
• Who can open a page: update_page_access.
• Monitors: create_monitor, update_monitor, delete_monitor and check_monitor.
• Incidents: open_incident, schedule_maintenance, post_update (status completed ends a maintenance window), update_incident and delete_incident.
• Deploys: record_deploy.

The incident tools take what the REST API takes: a state per monitor, a start in the past, an incident that is already over, a window's reminders and repeat, and notify: false to leave subscribers out. Every tool answers with the same resources the REST API sends, and a key that reaches one page only sees that page and has no create_page. delete_page is for keys made by the team's owner or an admin, and deletes only when confirm is the page's address; without it the answer says what would go. A logo or favicon is an image, and MCP carries JSON, so those two are set over REST only. With on-call, read keys also get list_alerts, get_alert and get_on_call, write keys acknowledge_alert, resolve_alert and snooze_alert, and open_incident takes internal.

https://statoss.com/api/v1/mcp/read takes any key and lists only the tools that read. Teams that have errors or logs also get their tools at both addresses, such as list_issues and search_logs. https://statoss.com/api/v1/mcp/apps/<app> lists one app's tools, the app by id or slug.

Each address takes an API key or a person's sign-in, below.

Setting up an account

Write keys also finish an account's setup, with the calls described under Setting up an account. Read keys get the first tool of each pair that only reads.

• Alert destinations: list_alert_destinations, add_alert_destination, update_alert_destination, remove_alert_destination, resend_destination_link and test_alert_destination. An email address is not used until it is confirmed.
• A page's alerts: get_alert_settings, update_alert_settings and test_page_alerts.
• Subscribers: list_subscribers, add_subscriber and remove_subscriber. An email address gets the confirmation mail and is not subscribed until it opens the link.
• The team: get_team, invite_member, cancel_invitation, change_member_role and remove_member. For the owner's and admins' keys; the owner is never changed or removed.
• API keys: list_api_keys, create_api_key and revoke_api_key. A key makes keys no broader than itself, and the new key is in the answer once. A key made through a connected app is deleted when the app is disconnected or its access revoked.

Billing, passwords, two-factor sign-in, single sign-on and deleting the account stay in the dashboard.

Connecting a client

The endpoints speak the Streamable HTTP transport, stateless: JSON-RPC by POST, JSON back, no session and no event stream. Claude Code, Cursor, Claude Desktop and most other clients take a remote server as a URL plus headers.

claude mcp add statoss https://statoss.com/api/v1/mcp \
  --transport http \
  --header "Authorization: Bearer sk_..."

Or, as a JSON entry for a client that reads one:

{
  "mcpServers": {
    "statoss": {
      "url": "https://statoss.com/api/v1/mcp",
      "headers": { "Authorization": "Bearer sk_..." }
    }
  }
}

Signing in

A client added without a key signs its person in with OAuth 2.1. The first call is answered 401 with where to sign in, and the client opens StatOSS in a browser.

claude mcp add statoss https://statoss.com/api/v1/mcp --transport http

In Claude Code, /mcp then starts the sign-in. The Connect page names the client and where it sends the person back, and asks for:

• the team;
• Read, or Read and write when the client asks to write, which is for owners and admins;
• every app, or only one.

After Allow, the client acts as that person with what they chose. A read grant lists only the tools that read, and a grant held to one app sees that app alone. The client renews its access every hour; one unused for 30 days signs in again.

Clients that register themselves and clients with a client ID metadata document both work. The metadata is at /.well-known/oauth-authorization-server, with PKCE (S256) and the scopes read and write.

Connected apps

Settings, Connected apps lists each client the person allowed, with its address, the team, read only or read and write, every app or one, and when it was last used. Revoke stops it at once, with all its tokens.

llms.txt

https://<page>/llms.txt is a short text file that says what the page is, lists its monitors, and points at status.json, the feeds and the MCP endpoint, with a note on how to read status.json. It is what a language model should be handed instead of the HTML. The site's own llms.txt describes StatOSS itself.