Skip to main content
Glama
fclairamb

SolidPing

Official
by fclairamb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

List regions

list_regions
Read-onlyIdempotent

Retrieve available monitoring regions and default placement set for your organization. Use returned region slugs in create_check or update_check.

Instructions

List monitoring regions available to the organization (e.g. eu-west-1, us-east-1). Returns {data: [...]} — each region's slug, label and per-region metadata — plus defaultRegions, the org's default placement set. Use these slugs in the regions array of create_check or update_check. Read-only: works with mcp:read tokens.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNoRegions available to this organization.
defaultRegionsNoThe org's default region slugs, used when a check has no explicit regions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.38.5
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "data": {
+      "description": "Regions available to this organization.",
+      "items": {
+        "properties": {
+          "capabilities": {
+            "description": "Live worker capabilities, e.g. {\"ipv6\": \"yes\"} (\"yes\", \"no\" or \"unknown\").",
+            "type": "object"
+          },
+          "emoji": {
+            "description": "Region emoji shown in the UI.",
+            "type": "string"
+          },
+          "name": {
+            "description": "Human-readable region label.",
+            "type": "string"
+          },
+          "offlineSince": {
+            "description": "RFC3339 timestamp of when the region went dark — the last time its workers were seen.",
+            "type": "string"
+          },
+          "private": {
+            "description": "Whether the region is an org-private location served by deported agents.",
+            "type": "boolean"
+          },
+          "slug": {
+            "description": "Region slug to pass in create_check/update_check; private regions are \"@\"-prefixed.",
+            "type": "string"
+          },
+          "status": {
+            "description": "\"online\" or \"offline\" for cloud regions; omitted for private ones.",
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "defaultRegions": {
+      "description": "The org's default region slugs, used when a check has no explicit regions.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}
  2. First observedv0.32.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered structurally. The description adds auth-specific detail the annotations do not carry ('works with mcp:read tokens') plus the defaultRegions payload, which is genuinely new behavioral context. Minor overlap with readOnlyHint keeps it from a 5.

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?

Three tight sentences, front-loaded with what is listed, then the return shape, then the downstream consumer. Every sentence earns its place; the 'Read-only' clause is mildly redundant given readOnlyHint but is justified by the token-scope information it adds.

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?

For a zero-parameter, read-only listing tool with annotations and an output schema, the agent has everything needed: what comes back, the meaning of the slugs, and where those slugs are consumed. Nothing required for correct invocation 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?

The tool takes zero parameters, so the baseline is 4 and there is no syntax the description could add. It correctly spends its words on output semantics (slug/label/metadata, defaultRegions) instead of inventing parameter detail.

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 and resource ('List monitoring regions available to the organization') and grounds it with concrete slug examples (eu-west-1, us-east-1), so it is immediately distinguishable from sibling lists like list_checks or list_check_types. The return shape (slug, label, metadata, defaultRegions) further pins down exactly what is being listed.

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?

Explicitly routes the agent: 'Use these slugs in the regions array of create_check or update_check' names the consuming sibling calls and the exact argument they feed. There is no explicit when-not or exclusion, but the usage context is unambiguous.

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

Deploy Server

Other Tools