Skip to main content
Glama

Uptimepage

by dev.uptimepage
OverviewDiscussionsAdmin

Add status page components

add_status_page_components
Idempotent

Add monitors to a status page as public components, in one confirmation where the client can show a prompt. Give each a public_name the page's readers will understand, since the monitor's own name is operator-facing, and a public_group to file related components together. Monitors already on the page are reported as such rather than duplicated. detail_link_enabled publishes a per-monitor detail view that shows the monitor's real name and address, not public_name. groups adds monitor groups as live sections: a heading with the members' combined state, every member as its own row, and members that join or leave the group joining or leaving the page; members past the plan's public component limit stay off. Not read-only.

Input Schema

NameRequiredDescriptionDefault
slugYesThe page slug (from `list_status_pages`).
groupsNoMonitor groups to show as live sections, by id from `list_monitor_groups`. Every member gets a row, and members that join or leave the group later join or leave the page.
componentsNoThe monitors to add, in the order they should appear.

Output Schema

NameRequiredDescriptionDefault
slugYes
addedYes
resultsYes
sectionsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / $defs / NewSectionArg
      Added value: +{
+  "description": "One monitor group to show on a page.",
+  "properties": {
+    "group_id": {
+      "type": "string"
+    },
+    "heading": {
+      "description": "Public heading, at most 50 characters. Defaults to the group's name.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "group_id"
+  ],
+  "type": "object"
+}
    • addedInput schema / properties / groups
      Added value: +{
+  "description": "Monitor groups to show as live sections, by id from\n`list_monitor_groups`. Every member gets a row, and members that join\nor leave the group later join or leave the page.",
+  "items": {
+    "$ref": "#/$defs/NewSectionArg"
+  },
+  "type": "array"
+}
    • changedInput schema / required
      Previous value: -[
-  "slug",
-  "components"
-]New value: +[
+  "slug"
+]
    • addedOutput schema / $defs / SectionOutcome
      Added value: +{
+  "description": "What became of one requested section.",
+  "properties": {
+    "error": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "group_id": {
+      "type": "string"
+    },
+    "left_off": {
+      "description": "Members the plan's public component limit kept off the page.",
+      "format": "uint32",
+      "minimum": 0,
+      "type": "integer"
+    },
+    "outcome": {
+      "description": "`added`, `already_on_page`, or `failed`.",
+      "type": "string"
+    },
+    "section_id": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "group_id",
+    "outcome",
+    "left_off"
+  ],
+  "type": "object"
+}
    • addedOutput schema / properties / sections
      Added value: +{
+  "items": {
+    "$ref": "#/$defs/SectionOutcome"
+  },
+  "type": "array"
+}
    • changedOutput schema / required
      Previous value: -[
-  "slug",
-  "added",
-  "results"
-]New value: +[
+  "slug",
+  "added",
+  "results",
+  "sections"
+]
  2. Added

TDQS

A4.1/5.0
Behavior4/5

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

Goes meaningfully beyond the annotations: discloses that already-present monitors are reported rather than duplicated, that group membership is live-synced (join/leave propagates to the page), that members beyond the plan's public component limit silently stay off, and that detail_link_enabled publishes the operator-facing name and address. That last point is a genuine privacy/leak warning an agent would not get from the schema. The trailing 'Not read-only' merely restates readOnlyHint=false, but it is a minor redundancy rather than a contradiction.

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?

Purpose is front-loaded in the first clause and every subsequent sentence carries operational content; no filler. Some sentences are long and run-on ('groups adds monitor groups as live sections: a heading with...'), which slightly hurts scanability, and 'Not read-only' is dead weight given the annotations.

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?

Output schema exists, so return values need not be explained, and the description covers the input semantics plus the non-obvious effects (dedup, live group sync, plan-limit truncation, detail-link exposure). What is missing is any mention of ordering interactions between components and groups in the final page layout, and explicit guidance on partial failure when only some monitors are beyond the limit.

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 baseline is 3; the description earns extra credit by supplying intent the schema lacks — why public_name matters (monitor name is operator-facing), what public_group does operationally, and the non-obvious consequence of detail_link_enabled (real name/address exposed, not public_name). It does not cover slug, sort_order, or the 50/80/200-char limits, which the schema already handles.

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?

Opens with a specific verb+resource+scope: 'Add monitors to a status page as public components,' and immediately distinguishes the two payload shapes (components vs. groups as live sections). An agent can tell this is a create/attach operation on a status page rather than a page create (create_status_page) or a component edit (update_status_page_component).

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?

Usage is implied by the semantics (use when attaching monitors or groups to an existing page, with slug coming from list_status_pages), and the duplicate-handling sentence hints at safe re-invocation. However, it never explicitly contrasts with update_status_page_component or says when to prefer adding a group over individual components beyond a one-line behavioral note. Guidance exists but must be inferred.

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

All Uptimepage toolsInspect
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.

Resources