Skip to main content
Glama
fclairamb

SolidPing

Official
by fclairamb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

update_status_page

Update an existing status page by changing only the fields you provide, such as visibility, language, or custom CSS, while leaving other settings untouched.

Instructions

Update an existing status page (PATCH semantics — only provided fields change).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoNew display name, e.g. "Public status page".
slugNoNew URL-friendly slug, e.g. "public".
enabledNoEnable or disable the public-facing page.
languageNoLanguage code, e.g. "en" or "fr".
customCssNoCustom 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.
isDefaultNoMark as the org's default page (only one allowed).
identifierYesStatus page UID or URL-friendly slug, e.g. "public".
visibilityNoVisibility setting. Allowed: "public", "private".
autoPublishNoAutomatically 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.
autoResolveNoWhat 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".
descriptionNoNew free-text description shown in the UI.
historyDaysNoDays of history to show on the page (default 90).
showAvailabilityNoToggle availability percentage on the public page.
showResponseTimeNoToggle response-time charts on the public page.
autoPublishDelaySecondsNoDebounce in seconds before an incident becomes public (default 60). 0 publishes immediately. An incident that resolves inside the delay is never published at all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.32.1

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses PATCH semantics — that only provided fields change — which is a meaningful behavioral trait. Still, it omits side effects, permissions, validation failures, and return behavior, leaving notable gaps for a mutation tool.

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?

The description is a single front-loaded sentence with no filler. It conveys the action and the most important semantic nuance in a compact, easily parseable form.

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 15-parameter mutation tool with no annotations and no output schema, the input side is thoroughly covered by the schema and PATCH note. However, the description does not explain return values, error/conflict behavior, or side effects, so an agent is left without key post-invocation context.

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%, and each parameter is already well documented. The description adds important cross-parameter meaning by stating that omitted fields remain unchanged, which is essential for correctly performing partial updates.

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?

The description states a specific verb ('Update') and resource ('existing status page'), and adds PATCH semantics. This clearly distinguishes it from create_status_page and delete_status_page as well as from section/resource update siblings.

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?

The description implies the correct context: use it when an existing status page must be modified, and only provided fields should change. However, it does not explicitly mention when to prefer this over create/delete or other update siblings, nor does it give any exclusion criteria.

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