Skip to main content
Glama
fettlesh

fettle-mcp

by fettlesh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

List check regions

list_regions
Read-onlyIdempotent

List all available check regions on the platform to see where monitors can run, including each region's code, display name, city, country, and group.

Instructions

List every check region of the platform, to show the user where checks can run. Returns regions, each with code (what a regions argument takes), display_name, city, country_code, group and group_display_name. The organization may use only some of them: to choose regions for a monitor read limits.allowed_regions and max_regions from get_plan_usage instead. For one monitor's per-region timings use get_response_time_by_region.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.1
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "regions": {
+      "items": {
+        "properties": {
+          "city": {
+            "type": "string"
+          },
+          "code": {
+            "type": "string"
+          },
+          "country_code": {
+            "type": "string"
+          },
+          "display_name": {
+            "type": "string"
+          },
+          "group": {
+            "type": "string"
+          },
+          "group_display_name": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "code",
+          "display_name",
+          "city",
+          "country_code",
+          "group",
+          "group_display_name"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "regions"
+  ],
+  "type": "object"
+}
  2. First observedv0.5.4

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real context by noting the organization may use only some regions, steering the agent to get_plan_usage for the actual allowed set. It does not add further behavioral traits like rate limits.

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 purpose. The enumerated return fields are somewhat redundant against the output schema, though the note on 'code' justifies inclusion.

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 needn't explain returns, yet it covers purpose, alternatives, and the allowed-region caveat. Nothing an agent needs to call this correctly 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 parameters, so the baseline is 4. The description still earns its keep by explaining that the returned 'code' field is what a 'regions' argument elsewhere consumes, linking this tool's output to other tools' inputs.

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 every check region of the platform') plus the intent ('to show the user where checks can run'). It also disambiguates from two siblings, so an agent can identify it without opening the schema.

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?

Explicitly routes the agent away: use limits.allowed_regions/max_regions from get_plan_usage to choose a monitor's regions, and get_response_time_by_region for per-region timings. Both the when-to-use and clear alternatives are named.

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