Uptimepage

Update status page component

update_status_page_component

Idempotent

Change how one monitor is presented on a status page: its public name, description, group or position; or, with section_id, a group section's heading. An omitted field is left alone. A section member's heading is its section's, so its public_group does nothing. Not read-only; idempotent.

Input Schema

Name	Required	Description
`slug`	Yes	The page slug (from `list_status_pages`).
`heading`	No	The section's public heading, at most 50 characters; blank shows the group's name.
`monitor_id`	No	The monitor id whose curation is being changed. Send this or `section_id`.
`section_id`	No	A section (from `get_status_page`) whose `heading` is being changed.
`sort_order`	No
`public_name`	No
`public_group`	No	Ignored on a section member, whose heading is the section's.
`public_description`	No

Output Schema

Name	Required	Description	Default
`slug`	Yes
`monitor_id`	No
`section_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedOct 29, 2026

addedInput schema / properties / heading

Added value: +{
+  "description": "The section's public heading, at most 50 characters; blank shows the\ngroup's name.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedInput schema / properties / monitor_id / description

Previous value: -"The monitor id whose curation is being changed."New value: +"The monitor id whose curation is being changed. Send this or\n`section_id`."

changedInput schema / properties / monitor_id / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

addedInput schema / properties / public_group / description

Added value: +"Ignored on a section member, whose heading is the section's."

addedInput schema / properties / section_id

Added value: +{
+  "description": "A section (from `get_status_page`) whose `heading` is being changed.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedInput schema / required

Previous value: -[
-  "slug",
-  "monitor_id"
-]New value: +[
+  "slug"
+]

changedOutput schema / properties / monitor_id / type

Previous value: -"string"New value: +[
+  "string",
+  "null"
+]

addedOutput schema / properties / section_id

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "slug",
-  "monitor_id"
-]New value: +[
+  "slug"
+]

AddedSep 19, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds useful behavior beyond those annotations: omitted fields are left alone, section member headings come from the section, and public_group is ignored in that case. It does not add auth or rate-limit context.

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?

Three tightly written sentences front-load the main action and then add the critical exception and field-preservation rule. There is no filler.

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?

The tool is a mutation with annotations and an output schema, so the description need not explain return values. It covers the key mutation semantics and section/member exception. It could say more about monitor_id vs section_id exclusivity and error behavior, but is sufficient for correct invocation.

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 63%, with key parameters like slug, heading, monitor_id, section_id, and public_group documented in the schema. The description adds meaningful semantics: omitted fields are preserved, section_id targets a section heading, and public_group has no effect on section members. This compensates well for the remaining gaps such as sort_order and public_name details.

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 and resource: changing how one monitor is presented on a status page, or with section_id, a section heading. It clearly scopes the tool to component-level curation, distinguishing it from the page-level sibling update_status_page.

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?

It explains the two usage paths: monitor curation by default, or section heading via section_id. It also warns that public_group does nothing for a section member. It does not name alternative tools such as update_status_page or add_status_page_components, but the context is otherwise clear.

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

All Uptimepage tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.