Skip to main content
Glama

Get check uptime

get_check_uptime
Read-onlyIdempotent

Read one check's uptime over a rolling window: the window's length in seconds (window_seconds), the time spent in incidents (downtime_seconds) and uptime_percentage, which is the incident-free share of the window. The window starts at the check's creation when the check is newer than the period asked for, and uptime_percentage is null until the check has a run or an incident. Time spent paused or pending isn't known and counts as up, so this is incident-free time, not verified availability. days is 7, 14, 30, 90 or 365 and defaults to 30; asking for more than the plan's limits.history_days returns quota_exceeded. An unknown check id returns not_found. time_zone (an IANA name) sets the zone for timestamps; the default is UTC, and the response names its zone.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "get_check_uptime"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesCheck id (check_…).
daysNoDays of history, up to the plan's limit. Defaults to 30, or the plan's limit when shorter.
time_zoneNoIANA time zone for days and timestamps, such as America/Chicago. Defaults to UTC.

Output Schema

NameRequiredDescriptionDefault
idYes
basisYes
end_atYes
start_atYes
time_zoneYes
window_secondsYes
downtime_secondsYes
uptime_percentageYes
paused_and_pending_history_availableYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: the window starts at check creation for young checks, uptime_percentage is null until a run or incident exists, paused/pending time counts as up so the figure is incident-free time rather than verified availability, plus named error outcomes (quota_exceeded, not_found) and the timestamp-zone default.

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 core purpose and window definition are front-loaded, and every sentence carries content relevant to interpretation. It is a dense, somewhat run-on single paragraph, and a few clauses (output field naming, time zone default) duplicate structured fields.

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 read-only single-resource metric tool with an output schema, the description covers the remaining gaps an agent needs: nullability, window-start edge case, pause/pending caveat, plan quota failure, unknown-id failure, and time zone handling. Little is left for the agent to guess.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the description mostly restates what the schema already says about days (enum and default) and time_zone (IANA name, UTC default). The extra meaning it adds is interpretive rather than parameter-level (quota limits, window start), so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read one check's uptime over a rolling window') and enumerates the returned figures, which separates it in substance from get_check_metrics and get_check_history. It does not explicitly name a sibling alternative, so the differentiation is implicit rather than spelled out.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains window semantics, the days default, and the quota_exceeded/not_found failure modes, which implies when the tool is appropriate. It never states when to prefer get_check_history or get_check_metrics instead, nor any exclusion conditions, so the when-to-use guidance remains implied.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources