OpenUptime

create_status_page

Publish a public status page at /status/ and assign monitored components so visitors can check service health without authentication.

Instructions

Publish a status page at /status/ and return its record and UUID. Use list_monitors to select components and an unused slug (a conflict returns an error); omitted monitorIds creates an empty page. The page and selected monitors' public status become readable without authentication. Use update_status_page to edit an existing page; branding options remain subject to the hosted plan.

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": {
      "slug": "<slug>",
      "title": "<title>"
    },
    "name": "create_status_page"
  }
}

Input Schema

Name	Required	Description
`slug`	Yes	Unique public address segment in /status/<slug>, for example api-status; choose an unused slug.
`theme`	No	Public page color scheme; auto follows the visitor's system preference.
`title`	Yes	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	Optional http(s) website the page header links to
`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

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 / slug / description

Added value: +"Unique public address segment in /status/<slug>, for example api-status; choose an unused slug."

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.4/5.0

Behavior4/5

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

Beyond the annotations, the description discloses that a slug conflict returns an error, that omitted monitorIds creates an empty page, that the page becomes publicly readable without authentication, and that branding options depend on the hosted plan. It does not discuss deletion or reversibility, which is notable given there is no delete_status_page sibling.

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 compact and front-loaded, moving from the primary action to constraints, then alternatives. Each sentence carries useful information without redundancy.

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

Completeness4/5

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

For a 9-parameter creation tool with no output schema, the description covers public visibility, error behavior, monitor omission, and the update alternative. Minor gaps remain around lifecycle/reversibility, but the essential invocation context is present.

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 coverage is 100%, so parameter meanings are already documented. The description adds only marginal detail, such as omitted monitorIds creating an empty page, while repeating the slug uniqueness already stated in the schema.

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 opens with a specific verb and resource: 'Publish a status page at /status/<slug> and return its record and UUID.' It clearly distinguishes creation from sibling operations like update_status_page and list_status_pages.

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?

It explicitly names list_monitors for component selection and update_status_page for editing existing pages. It also states the slug-uniqueness requirement and error behavior, plus what happens when monitorIds is omitted.

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