Uptimepage

List probe regions

list_regions

Read-only

The fleet's probe regions: id, display name, city, country, continent, and whether each is on by default for a new monitor. Reports max_regions only when the plan reaches fewer regions than the catalog lists, so a set too large to be accepted is visible before it is sent. Use it to pass a valid region to get_monitor_history, and to read where a check would run from. This is a catalog, not a menu to fill: leave create_monitor.regions unset unless the user named the places they want covered. Read-only.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`items`	Yes
`max_regions`	No	How many of these regions one monitor may probe from, when the plan allows fewer than the catalog holds. A `create_monitor` naming more is refused outright, not trimmed to fit. Null when the plan reaches every region listed, which is not licence to name them all: what a monitor takes by default is `default_selected`, not this ceiling.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 4, 2026

addedOutput schema / $defs / RegionItem / properties / default_selected

Added value: +{
+  "description": "Whether a new monitor probes from here unless told otherwise. Omitting\n`create_monitor.regions` takes exactly the regions flagged here.",
+  "type": "boolean"
+}

changedOutput schema / $defs / RegionItem / required

Previous value: -[
-  "id",
-  "name",
-  "city"
-]New value: +[
+  "id",
+  "name",
+  "city",
+  "default_selected"
+]

addedOutput schema / properties / max_regions

Added value: +{
+  "description": "How many of these regions one monitor may probe from, when the plan\nallows fewer than the catalog holds. A `create_monitor` naming more is\nrefused outright, not trimmed to fit. Null when the plan reaches every\nregion listed, which is not licence to name them all: what a monitor\ntakes by default is `default_selected`, not this ceiling.",
+  "format": "uint32",
+  "minimum": 0,
+  "type": [
+    "integer",
+    "null"
+  ]
+}

First observedAug 11, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, and the description reinforces it with 'Read-only.' It adds valuable behavioral detail about `max_regions` appearing only when the plan limit is lower than catalog count, which is beyond annotation coverage.

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 sentences, each earning its place: the catalog contents, the max_regions behavior, and usage guidance. The most critical usage warning is placed last but clearly marked, and the text is front-loaded with the resource description.

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?

With an output schema present, the description doesn't need to detail return values. It covers the fields, the edge case of max_regions, and proper usage, making it fully complete for an agent to call correctly without ambiguity.

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?

The tool has zero parameters, so the description carries no parameter burden. The description focuses on output and usage, which is appropriate for a parameterless tool; a 4 reflects the baseline for 0-param tools.

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 clearly states the tool lists probe regions and specifies the exact fields returned: id, display name, city, country, continent, and default status. It also explains its role in supplying valid `region` values for other tools, distinguishing it from sibling list tools.

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?

The description explicitly directs when to use it: to pass a valid `region` to get_monitor_history and to read where a check runs. It also gives a clear exclusion: not to use it as a menu to fill create_monitor.regions unless the user named specific places.

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.