OpenUptime

update_status_page

Idempotent

Patch an existing status page by UUID to edit its title, theme, header link, or published components. Omitted fields stay unchanged; monitorIds replaces the full component list.

Instructions

Patch an existing status page by its UUID from list_status_pages; returns {ok:true}. Use this to edit presentation or selected components; use get_public_status_page to read the public result. Omitted fields stay unchanged; monitorIds replaces the complete component list and [] clears it. Changes affect the published page; an empty externalUrl removes its header link. Hosted branding restrictions still apply.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "update_status_page"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Resource UUID returned by the matching list tool; not its name, incident number or status-page slug.
`theme`	No	Public page color scheme; auto follows the visitor's system preference.
`title`	No	Heading displayed on the public status page.
`project`	No	Project id (from list_workspaces). Omit to use the default project of the workspace.
`workspace`	No	Workspace id (from list_workspaces). Omit to use the default one.
`monitorIds`	No	Ordered monitor UUIDs from list_monitors to publish as components; replaces the full list, [] clears it.
`externalUrl`	No	http(s) website the page header links to; empty string removes it
`showLatency`	No	Whether visitors can see component response-time charts.
`hideBranding`	No	Hide OpenUptime's name and mark; the page shows the website's logo instead. Some plans do not include this.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.1.1Oct 23, 2026

changedInput schema / properties / id / description

Previous value: -"Resource id (uuid)"New value: +"Resource UUID returned by the matching list tool; not its name, incident number or status-page slug."

addedInput schema / properties / monitorIds / description

Added value: +"Ordered monitor UUIDs from list_monitors to publish as components; replaces the full list, [] clears it."

addedInput schema / properties / showLatency / description

Added value: +"Whether visitors can see component response-time charts."

addedInput schema / properties / theme / description

Added value: +"Public page color scheme; auto follows the visitor's system preference."

addedInput schema / properties / title / description

Added value: +"Heading displayed on the public status page."

First observedv0.1.0Oct 19, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare non-readOnly, idempotent and non-destructive, so the bar is lower; the description still adds real context the annotations cannot convey: PATCH semantics ('omitted fields stay unchanged'), that changes go live on the published page, that an empty externalUrl deletes the header link, and that hosted branding restrictions (plan limits) apply to hideBranding. A gap: the replace/clear behavior of monitorIds is a targeted destructive effect not reconciled with destructiveHint=false.

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 verb, resource and ID provenance, then the routing hint, then per-field edge cases. Semicolon-joined clauses stay dense without padding; every sentence carries information an agent would otherwise have to infer.

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?

Covers identifier provenance, write scope, live-publish consequences, field-omission semantics, the destructive [] case, plan restrictions, and even the return shape ({ok:true}) despite there being no output schema. With all 9 parameters fully documented in the schema, nothing material is missing.

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 100%, so the baseline is 3. The description's monitorIds replace/clear rule and empty-externalUrl rule duplicate what the schema already says verbatim; its only genuine addition is that unspecified fields are left untouched, which frames the whole parameter set as a patch rather than a full replace.

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 (patch), a specific resource (an existing status page), and even the identifier source ('by its UUID from list_status_pages'). It explicitly distinguishes itself from the read-side sibling get_public_status_page, so an agent can select it without consulting the schema.

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

Usage Guidelines4/5

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

Explicitly routes the agent: use this to edit presentation/components, use get_public_status_page to read the result. The write-vs-read split is clear. It does not address the create/delete boundary (create_status_page, delete paths), so it stops short of full alternative coverage.

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