Skip to main content
Glama
statuser-cloud

Statuser MCP Server

Official
by statuser-cloud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Update status page

status_page_update
Destructive

Update selected status-page settings without replacing the whole configuration. Send only the fields to change; slug/domain conflicts return 409 and plan-feature limits return 403.

Instructions

Partial update of status-page settings. Pass only the fields you want to change. Slug/domain conflicts → 409; plan-feature constraints → 403.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
nameNo
slugNoURL-safe slug (3–50 chars, lowercase Latin letters, digits, hyphens, underscores). If omitted on create, a random one is generated.
domainNoCustom domain (must be a subdomain pointing to Statuser via CNAME). Requires `custom_domain_enabled`.
confirmNoSet to true to authorize this write/destructive call even if STATUSER_ALLOW_WRITE is not enabled in the server config. Required for one-off overrides.
languageNoLanguage of the public page, subscriber emails and RSS/Atom feeds: `ru`, `en`, `kk` (Kazakh, Cyrillic), `uz` (Uzbek, Latin), `tr`, `zh` (Simplified Chinese), `es`, `de`, `fr`. Visitors cannot switch it. Server names, incident reports and announcements are not translated — write them in the page language. Omitted on create, the page is in Russian.
logo_urlNo
passwordNoPassword to gate the page. Requires `password_protected_status_page`.
timezoneNo
is_indexedNoAllow search engines to index the page. Requires `indexing_control_enabled` if you want to disable it.
project_idNoProject the status page belongs to. Omitted on create, it goes to the oldest project of the account; passed on update, the page moves there together with the monitors it shows. See `project_list`.
theme_modeNo`user` — follow viewer preference; `light` / `dark` — force theme.
company_urlNo
descriptionNo
favicon_urlNo
support_urlNo
is_publishedNo
timeline_daysNoHow many days the timeline on the page covers. Must be one of: 7, 14, 30, 60, 90, 180.
is_white_labeledNoHide Statuser branding. Requires `white_label_enabled`.
subscribers_enabledNoShow the subscribe button on the public page so visitors can get emails about incident reports and planned maintenances (plus RSS/Atom feeds). Requires a plan with `status_page_subscribers_limit > 0`.
subscribers_reply_toNoReply-To address for subscriber emails — where subscriber replies will arrive. Pass `null` to clear.
subscribers_from_nameNoDisplay name of the sender in subscriber emails (the From address itself stays on the shared sending domain). Defaults to the status page name. Pass `null` to reset.
uptime_decimal_placesNo
minimum_incident_durationNoMinimum incident duration (in seconds, 0–86400) before it appears on the page. Requires `status_page_minimum_incident_duration_enabled` to set above 0.
is_not_monitored_operationalNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.8
    • addedInput schema / properties / language
      Added value: +{
+  "description": "Language of the public page, subscriber emails and RSS/Atom feeds: `ru`, `en`, `kk` (Kazakh, Cyrillic), `uz` (Uzbek, Latin), `tr`, `zh` (Simplified Chinese), `es`, `de`, `fr`. Visitors cannot switch it. Server names, incident reports and announcements are not translated — write them in the page language. Omitted on create, the page is in Russian.",
+  "enum": [
+    "ru",
+    "en",
+    "kk",
+    "uz",
+    "tr",
+    "zh",
+    "es",
+    "de",
+    "fr"
+  ],
+  "type": "string"
+}
  2. First observedv0.4.5

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is partly covered. The description adds genuine context the annotations cannot: the operation is partial (unspecified fields are untouched) and the failure semantics (409 for slug/domain conflicts, 403 for plan-feature constraints). It does not explain what is destroyed or the write-authorization requirement, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three terse sentences with zero filler, front-loading the operation and its partial nature before the error-code shorthand. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 25-parameter mutation with no output schema, the description covers the update semantics and key error codes but says nothing about the returned object or about the many parameters the schema leaves undocumented. Adequate but with visible gaps given the tool's surface area.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 56% across 25 parameters, so the schema carries much of the burden and the description must compensate for the rest. The only parameter-level guidance is the partial-update rule, which is useful but does not explain undocumented fields such as id, name, timezone, logo_url, or is_published. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Partial update of status-page settings') and makes the partial/PATCH semantics explicit. It does not name sibling boundaries (e.g., status_page_publish for publishing, status_page_set_groups for group assignment), but the 'settings' scope is clear enough to distinguish it from those.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Pass only the fields you want to change' gives real guidance on how to invoke it, which is valuable for a 25-param tool. However, there is no when-to-use/when-not guidance versus siblings like status_page_publish or status_page_set_groups, and no mention of prerequisites such as the `confirm` flag for write authorization.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools