SolidPing

Official

Overview Schema Source Related Servers Discussions Admin

Manage status page incident

manage_status_page_incident

Destructive

Create, update, publish or remove the customer-facing incidents shown on a status page, separating public notices from internal incident records.

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

TableJSON 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

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

Addedv0.38.5Oct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses the customer-visible blast radius of titles/bodies, that create/add_update/publish notify subscribers under an hourly cap, that every action hits webhook connections, that unpublish preserves rows for audit, and the exact auth requirements (mcp scope, mcp:read refused, user role minimum). This is unusually rich operational context for a destructive tool.

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?

The safety warning about customer-visible content is front-loaded, and every subsequent sentence is an action-to-parameter mapping rather than filler. It is dense and long, but nearly all of it earns its place; only mild compaction is possible.

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?

For a 5-action, 9-parameter mutation tool with an output schema and existing annotations, the description supplies everything else an agent needs: action routing, parameter binding per action, side effects, permissions, and audit behavior. Nothing material is left unspecified.

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 3 is the baseline, but the description adds real value by mapping parameters to actions (pageIdentifier+title for create, publicationUid for update, kind+bodyMarkdown for add_update, incidentUid for publish/unpublish) and by stating PATCH semantics and append-only behavior for add_update. It does not restate enum values, which the schema already documents.

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?

States a specific verb (manage) and a precisely scoped resource: 'the customer-facing incidents a status page shows (publications)'. It explicitly distinguishes that resource from the internal incidents returned by list_incidents, so an agent can route correctly without opening schemas.

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?

Enumerates each action with its required parameters (create, update with PATCH semantics, add_update append-only, publish relays an existing incident, unpublish removes while keeping the row for audit) and names the exact read companion: get_status_page include=incidents. It also names the alternative source for internal incidents (list_incidents), covering when-not-to-use.

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