SolidPing

Official

Overview Schema Source Related Servers Discussions Admin

Manage status page incident

manage_status_page_incident

Destructive

Create, update, publish, or unpublish customer-facing status page incidents and post narrative updates so subscribers stay informed without exposing internal probe details.

Instructions

Manage the customer-facing incidents a status page shows (publications), distinct from the internal incidents list_incidents returns. Titles and bodies are shown to CUSTOMERS: never paste probe output, error strings, internal hostnames or IPs. action=create publishes a hand-written incident (pageIdentifier, title). action=update edits a publication's title, severity or state (pageIdentifier, publicationUid; PATCH semantics). action=add_update appends a narrative entry (pageIdentifier, publicationUid, kind, bodyMarkdown); entries are append-only. action=publish relays an EXISTING internal incident (incidentUid, pageIdentifier) with a title templated from the page. action=unpublish removes a relayed incident from the page (incidentUid, publicationUid), keeping the row for audit. create, add_update and publish notify status-page subscribers (hourly cap) and every action reaches webhook connections. Read publications with get_status_page include=incidents. Annotated destructive and non-idempotent because delete is one of its actions. Every action requires the mcp scope (mcp:read tokens are refused) and at least the user role in the organization.

Input Schema

Name	Required	Description
`kind`	No	Update kind (required). Allowed: "investigating", "identified", "monitoring", "resolved", "maintenance", "info". The first four also advance the publication's state.
`state`	No	Initial public state (default "investigating"). Allowed: "investigating", "identified", "monitoring", "resolved".
`title`	No	Customer-facing title (required), e.g. "Payments API is degraded".
`action`	Yes	What to do with the customer-facing incident.
`severity`	No	Public badge severity. Allowed: "minor", "major", "critical".
`incidentUid`	No	Optional UID of the internal incident this publication tracks.
`bodyMarkdown`	No	Optional first narrative entry, in Markdown.
`pageIdentifier`	No	Status page UID or URL-friendly slug, e.g. "public".
`publicationUid`	No	UID of the incident publication to act on.

Output Schema

Name	Required	Description
`uid`	No	Publication UID.
`kind`	No	Update kind, e.g. "investigating" or "resolved".
`stale`	No	True when the linked incident has resolved while the entry is still open.
`state`	No	Public state: investigating, identified, monitoring or resolved.
`title`	No	Customer-facing title.
`severity`	No	Public severity: minor, major or critical; absent when unset.
`createdAt`	No	RFC3339 creation timestamp.
`updatedAt`	No	RFC3339 last-update timestamp.
`resolvedAt`	No	RFC3339 timestamp when it was resolved; absent while open.
`autoCreated`	No	True when the publication was created by the auto-publish pipeline.
`incidentUid`	No	Linked internal incident UID, when the publication tracks one.
`publishedAt`	No	RFC3339 timestamp when the entry appeared on the page.
`unpublished`	No	Always true on success.
`bodyMarkdown`	No	Update body in Markdown.
`humanTouched`	No	True once an operator edited it, which stops auto-resolve.
`statusPageUid`	No	UID of the status page the publication lives on.
`publicationUid`	No	UID of the publication removed from the page.

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv0.42.0Oct 27, 2026
- addedInput schema / properties / action / maxLength
```
Added value: +2048
```
- addedInput schema / properties / action / minLength
```
Added value: +1
```
- addedInput schema / properties / bodyMarkdown / maxLength
```
Added value: +2048
```
- addedInput schema / properties / incidentUid / maxLength
```
Added value: +2048
```
- addedInput schema / properties / kind / maxLength
```
Added value: +2048
```
- addedInput schema / properties / pageIdentifier / maxLength
```
Added value: +2048
```
- addedInput schema / properties / publicationUid / maxLength
```
Added value: +2048
```
- addedInput schema / properties / severity / maxLength
```
Added value: +2048
```
- addedInput schema / properties / state / maxLength
```
Added value: +2048
```
- addedInput schema / properties / title / maxLength
```
Added value: +2048
```
Changed2 schema fields changedv0.41.0Oct 23, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- addedOutput schema / additionalProperties
```
Added value: +false
```
Addedv0.38.5Oct 15, 2026

TDQS

A5/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses subscriber notifications with an hourly cap and webhook fanout for create/add_update/publish, append-only narrative entries, audit retention after unpublish, PATCH semantics on update, and the required mcp scope plus org role. The only imprecision is the claim that 'delete is one of its actions' when the enum exposes unpublish rather than delete, but the destructive/non-idempotent annotations themselves are not contradicted.

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?

Front-loads the resource identity and the safety warning before enumerating actions, then closes with side effects and auth. Dense but every sentence carries operational information an agent would otherwise have to guess.

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?

Return values are covered by the output schema, so the description correctly spends its budget on side effects, permission requirements, append-only semantics and per-action argument requirements. Nothing needed to invoke a destructive multi-action tool correctly is missing.

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

Parameters5/5

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

Schema coverage is 100% so the baseline would be 3, but the description adds a per-action parameter map (pageIdentifier+title for create, publicationUid for update, kind+bodyMarkdown for add_update, incidentUid+publicationUid for unpublish) that the schema—whose only required field is action—does not encode. It also clarifies that publish templates the title from the page.

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?

Names the specific resource (customer-facing status page incidents/publications) and the exact verb per action (create, update, add_update, publish, unpublish), including the parameters each requires. It explicitly distinguishes itself from list_incidents, which returns internal incidents, so the agent can tell the two apart without opening either 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?

Every action carries its use case and required arguments, and the description names the alternative path for reading publications (get_status_page with include=incidents). It also states when-not conditions via the warning that titles/bodies are customer-visible and must never contain probe output, error strings, hostnames or IPs.

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