fettle-mcp

Overview Schema Source Related Servers Discussions Admin

Get plan usage

get_plan_usage

Read-onlyIdempotent

Check an organization's plan limits and current usage before creating monitors, heartbeats, or regions, or to explain a 403 citing a limit.

Instructions

Show the organization's plan, its limits and current usage, to check that new monitors, heartbeats or regions fit before creating them or to explain a 403 naming a limit. Region codes and their cities come from list_regions; billing changes happen only in the dashboard. Values are current as of the call. Returns plan (one of FREE, PLUS, PRO, MAX, ENTERPRISE), limits and usage. limits: max_monitors, min_interval_seconds, max_fast_monitors (monitors below fast_interval_threshold_seconds, 60), max_regions per monitor, allowed_regions, max_heartbeats, max_maintenance_windows, history_retention_days, api_rate_limit_per_minute (shared by the whole organization), renotify_interval_seconds and renotify_max_count (how often and how many times an open, unacknowledged incident is alerted again; 0 means no reminders); null means no limit. usage: monitors (paused included), fast_monitors and heartbeats.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`plan`	Yes	Known values: FREE, PLUS, PRO, MAX, ENTERPRISE.
`usage`	Yes
`limits`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.6.1Oct 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "limits": {
+      "properties": {
+        "allowed_channel_types": {
+          "items": {
+            "description": "Known values: EMAIL, TELEGRAM, WEBHOOK, SLACK, DISCORD.",
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "allowed_regions": {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "api_rate_limit_per_minute": {
+          "type": "integer"
+        },
+        "fast_interval_threshold_seconds": {
+          "type": "integer"
+        },
+        "history_retention_days": {
+          "type": "integer"
+        },
+        "max_api_keys": {
+          "type": "integer"
+        },
+        "max_channels": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "max_fast_monitors": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "max_heartbeats": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "max_maintenance_windows": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "max_monitors": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "max_regions": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "max_status_page_subscribers": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "max_status_pages": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "min_interval_seconds": {
+          "type": "integer"
+        },
+        "renotify_interval_seconds": {
+          "type": "integer"
+        },
+        "renotify_max_count": {
+          "type": "integer"
+        },
+        "tier": {
+          "description": "Known values: FREE, PLUS, PRO, MAX, ENTERPRISE.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "tier",
+        "max_monitors",
+        "min_interval_seconds",
+        "max_fast_monitors",
+        "fast_interval_threshold_seconds",
+        "max_regions",
+        "history_retention_days",
+        "allowed_channel_types",
+        "max_channels",
+        "max_heartbeats",
+        "max_maintenance_windows",
+        "max_status_pages",
+        "max_status_page_subscribers",
+        "renotify_interval_seconds",
+        "renotify_max_count",
+        "max_api_keys",
+        "api_rate_limit_per_minute",
+        "allowed_regions"
+      ],
+      "type": "object"
+    },
+    "plan": {
+      "description": "Known values: FREE, PLUS, PRO, MAX, ENTERPRISE.",
+      "type": "string"
+    },
+    "usage": {
+      "properties": {
+        "fast_monitors": {
+          "description": "Monitors with an interval below the fast threshold.",
+          "type": "integer"
+        },
+        "heartbeats": {
+          "type": "integer"
+        },
+        "monitors": {
+          "description": "Monitors, paused ones included.",
+          "type": "integer"
+        }
+      },
+      "required": [
+        "monitors",
+        "fast_monitors",
+        "heartbeats"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "plan",
+    "limits",
+    "usage"
+  ],
+  "type": "object"
+}

First observedv0.5.4Oct 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description adds substantial context beyond the annotations: values are current as of the call, null means no limit, API rate limits are shared by the whole organization, and renotify fields describe incident alerting behavior. It also clarifies the output categories plan, limits, and usage in enough detail to support interpretation.

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?

The description is front-loaded with purpose and usage before moving into field-level detail. It is somewhat long and repeats some return-value information that may already be captured by the output schema, but the detail largely earns its place for a tool whose limits and usage values need interpretation.

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 the tool's breadth and the presence of an output schema, the description provides all the context an agent needs: when to call it, what the values mean, how limits should be interpreted, and where related actions belong. No material behavioral or usage gap remains.

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?

There are zero parameters, so the baseline is 4. The description does not need to explain parameter meaning, and it does not introduce any parameter-related ambiguity.

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 states a specific verb and resource: showing the organization's plan, limits, and current usage. It also distinguishes its scope from related operations by naming list_regions for region codes and the dashboard for billing changes, 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?

It gives explicit when-to-use guidance: before creating monitors, heartbeats, or regions, and when explaining a 403 that names a limit. It also names alternatives for region data and billing changes, making the selection criteria clear.

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

Deploy Server