SolidPing

Official

Overview Schema Source Related Servers Discussions Admin

Update status page

update_status_page

Idempotent

Change an existing status page by UID or slug with partial updates: edit its name, visibility, CSS, and incident settings while omitted fields stay unchanged.

Instructions

Update an existing status page by UID or slug and return the updated page. PATCH semantics — only fields you pass change, omitted fields keep their current values; the page must already exist and a slug that collides with another page is rejected. Use create_status_page to make a new page and delete_status_page to remove one instead. Modifies the page in place, so it is reversible by updating again with the previous values. Requires the mcp scope (mcp:read tokens are refused) and at least the user role in the organization.

Input Schema

Name	Required	Description
`name`	No	New display name, e.g. "Public status page".
`slug`	No	New URL-friendly slug, e.g. "public".
`enabled`	No	Enable or disable the public-facing page.
`language`	No	Language code, e.g. "en" or "fr".
`customCss`	No	Custom CSS injected into the public page as a <style> element (see create_status_page). Max 64 KB; @import is rejected. Pass an empty string to clear it.
`isDefault`	No	Mark as the org's default page (only one allowed).
`identifier`	Yes	Status page UID or URL-friendly slug, e.g. "public".
`visibility`	No	Visibility setting. Allowed: "public", "private".
`autoPublish`	No	Automatically publish incidents affecting this page's resources as public incidents. New pages default to true; pages that existed before this feature shipped default to false.
`autoResolve`	No	What an auto-created publication does when its incident resolves. Allowed: "always", "if_untouched" (default — a publication a human has edited is left for them to close), "never".
`description`	No	New free-text description shown in the UI.
`historyDays`	No	Days of history to show on the page (default 90).
`showAvailability`	No	Toggle availability percentage on the public page.
`showResponseTime`	No	Toggle response-time charts on the public page.
`autoPublishDelaySeconds`	No	Debounce in seconds before an incident becomes public (default 60). 0 publishes immediately. An incident that resolves inside the delay is never published at all.

Output Schema

Name	Required	Description
`uid`	Yes	Status page UID.
`name`	No	Display name.
`slug`	No	URL-friendly slug.
`enabled`	No	Whether the public page is served.
`createdAt`	No	RFC3339 creation timestamp.
`isDefault`	No	Whether this is the organization's default page.
`visibility`	No	"public", "private" or "password".
`historyPeriod`	No	History window: "24h", "7d", "30d" or "90d".

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv0.42.0Oct 27, 2026
- addedInput schema / properties / autoResolve / maxLength
```
Added value: +2048
```
- addedInput schema / properties / customCss / maxLength
```
Added value: +65536
```
- addedInput schema / properties / description / maxLength
```
Added value: +2048
```
- addedInput schema / properties / identifier / maxLength
```
Added value: +2048
```
- addedInput schema / properties / identifier / minLength
```
Added value: +1
```
- addedInput schema / properties / language / maxLength
```
Added value: +2048
```
- addedInput schema / properties / name / maxLength
```
Added value: +2048
```
- addedInput schema / properties / slug / maxLength
```
Added value: +2048
```
- addedInput schema / properties / visibility / maxLength
```
Added value: +2048
```
Changed2 schema fields changedv0.41.0Oct 23, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- addedOutput schema / additionalProperties
```
Added value: +false
```

Changed1 schema field changedv0.38.5Oct 15, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "createdAt": {
+      "description": "RFC3339 creation timestamp.",
+      "type": "string"
+    },
+    "enabled": {
+      "description": "Whether the public page is served.",
+      "type": "boolean"
+    },
+    "historyPeriod": {
+      "description": "History window: \"24h\", \"7d\", \"30d\" or \"90d\".",
+      "type": "string"
+    },
+    "isDefault": {
+      "description": "Whether this is the organization's default page.",
+      "type": "boolean"
+    },
+    "name": {
+      "description": "Display name.",
+      "type": "string"
+    },
+    "slug": {
+      "description": "URL-friendly slug.",
+      "type": "string"
+    },
+    "uid": {
+      "description": "Status page UID.",
+      "type": "string"
+    },
+    "visibility": {
+      "description": "\"public\", \"private\" or \"password\".",
+      "type": "string"
+    }
+  },
+  "required": [
+    "uid"
+  ],
+  "type": "object"
+}

First observedv0.32.1Sep 26, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so safety is partly pre-covered; the description still adds substantial context: PATCH semantics for omitted fields, reversibility by re-updating with previous values, the required mcp scope (mcp:read refused) and minimum user role. The only gap is that it doesn't note side effects of toggling isDefault/visibility on other pages.

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

Conciseness4/5

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

Front-loaded with the mutation and its identifier, then partial-update semantics, error cases, alternatives and auth in a tight progression with no filler. It is dense with clauses, but each sentence carries distinct operational information.

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

Completeness5/5

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

With 15 parameters, an existing output schema, and rich annotations, the description covers everything an agent needs before calling: identity resolution, partial-update contract, failure modes, sibling routing, reversibility and authorization. Return-value details are correctly left to the output schema.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3; the description earns an extra point by explaining that only supplied fields change and omitted ones retain current values — a semantic not derivable from the schema of 15 optional properties plus one required identifier. It doesn't add per-field details beyond the schema, which already documents enums, defaults and limits.

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

Purpose5/5

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

Specific verb+resource ("Update an existing status page by UID or slug and return the updated page") with the identifier form stated up front. It explicitly names the sibling tools it is not (create_status_page, delete_status_page), so an agent can route without opening another schema.

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

Usage Guidelines5/5

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

States both when to use (page must already exist, PATCH-style partial update) and when not to (use create_status_page for new pages, delete_status_page to remove). It also names a concrete failure condition — a colliding slug is rejected — which an agent needs to avoid a wasted call.

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