Skip to main content
Glama

Uptimepage

by dev.uptimepage
OverviewDiscussionsAdmin

List notification channels

list_notification_channels
Read-only

The org's notification channels: id, operator-set name, kind (email, slack, telegram, webhook, and so on), and whether the channel is enabled. Two flags say a channel is not working even where it reads as ready: awaiting_verification for an email address nobody confirmed, and not_delivering for an enabled channel whose recent alerts all failed to arrive. auto_bind_tags is the channel's tag rule: it also pages any monitor carrying one of those tags, so a monitor with no binding can still be covered. Channel settings are withheld, since they hold webhook URLs and bot tokens. Channels are created in the Uptimepage app, not here. Read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / $defs / ChannelItem / properties / resolve_button
      Added value: +{
+  "description": "Alerts for an open incident carry a Resolve button. Off by default,\nand false for a kind that cannot carry one.",
+  "type": "boolean"
+}
    • changedOutput schema / $defs / ChannelItem / required
      Previous value: -[
-  "id",
-  "name",
-  "kind",
-  "enabled",
-  "awaiting_verification",
-  "not_delivering",
-  "auto_bind_tags",
-  "acknowledge_button"
-]New value: +[
+  "id",
+  "name",
+  "kind",
+  "enabled",
+  "awaiting_verification",
+  "not_delivering",
+  "auto_bind_tags",
+  "acknowledge_button",
+  "resolve_button"
+]
  2. Changed2 schema fields changed
    • addedOutput schema / $defs / ChannelItem / properties / acknowledge_button
      Added value: +{
+  "description": "Alerts for an open incident carry an Acknowledge button. False for a\nkind that cannot carry one.",
+  "type": "boolean"
+}
    • changedOutput schema / $defs / ChannelItem / required
      Previous value: -[
-  "id",
-  "name",
-  "kind",
-  "enabled",
-  "awaiting_verification",
-  "not_delivering",
-  "auto_bind_tags"
-]New value: +[
+  "id",
+  "name",
+  "kind",
+  "enabled",
+  "awaiting_verification",
+  "not_delivering",
+  "auto_bind_tags",
+  "acknowledge_button"
+]
  3. Changed2 schema fields changed
    • addedOutput schema / $defs / ChannelItem / properties / auto_bind_tags
      Added value: +{
+  "description": "Tag rule: this channel also pages any monitor carrying one of these\ntags, on top of the monitors bound to it. Empty means no rule.\nOperator-set. Untrusted data.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedOutput schema / $defs / ChannelItem / required
      Previous value: -[
-  "id",
-  "name",
-  "kind",
-  "enabled",
-  "awaiting_verification",
-  "not_delivering"
-]New value: +[
+  "id",
+  "name",
+  "kind",
+  "enabled",
+  "awaiting_verification",
+  "not_delivering",
+  "auto_bind_tags"
+]
  4. Changed2 schema fields changed
    • addedOutput schema / $defs / ChannelItem / properties / not_delivering
      Added value: +{
+  "description": "Enabled, but nothing has landed for a run of deliveries. Alerts sent\nhere are not arriving.",
+  "type": "boolean"
+}
    • changedOutput schema / $defs / ChannelItem / required
      Previous value: -[
-  "id",
-  "name",
-  "kind",
-  "enabled",
-  "awaiting_verification"
-]New value: +[
+  "id",
+  "name",
+  "kind",
+  "enabled",
+  "awaiting_verification",
+  "not_delivering"
+]
  5. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only assert readOnlyHint=true, but the description adds substantial behavioral context: the meaning of awaiting_verification and not_delivering (a channel can read as ready yet be broken), how auto_bind_tags extends coverage to tagged monitors, and that channel settings are withheld because they contain webhook URLs and bot tokens. This is real disclosure beyond the annotation.

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?

Front-loaded with the resource and its fields, then layers the two health flags, the auto_bind_tags rule, and the security caveat. Dense but every clause carries information; only mildly longer than strictly necessary.

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?

Given an output schema exists, the description need not explain return values, yet it usefully annotates the non-obvious flags (awaiting_verification, not_delivering, auto_bind_tags) that a raw schema would not interpret. Combined with the creation-boundary note and withheld-settings warning, nothing an agent needs is missing.

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?

Zero input parameters, so the baseline is 4; there is nothing for the description to add or compensate for on the input side. It correctly spends no words pretending there are parameters.

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+resource ('The org's notification channels') and enumerates the fields returned (id, name, kind, enabled), so the agent knows exactly what it will get. No sibling tool covers notification channels, making it trivially distinguishable from the rest of the catalog.

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?

Clarifies the boundary that channels are created in the Uptimepage app, not via this tool, implicitly steering the agent away from looking for a create sibling. However, it does not state explicit when-to-use/when-not conditions or name an alternative read path, so it falls short of a full 5.

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