Skip to main content
Glama

Get check history

get_check_history
Read-onlyIdempotent

Read one check's history as one row per calendar day, oldest day first: the date, how many runs were recorded (run_count), the mean response time in milliseconds (average_duration_ms, null for heartbeat, domain and SSL checks and for days with no measurement) and how many incidents started that day (incident_count). It's the summary to use for trends over weeks or months; it has no individual runs or percentiles. 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 where each day starts and ends; the default is UTC, and the response names its zone along with the window's start_at and end_at.

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_history"
  }
}

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
daysYes
end_atYes
start_atYes
time_zoneYes
retention_daysYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes further by disclosing error outcomes (quota_exceeded when days exceeds plan limits.history_days, not_found for an unknown id) and null semantics for heartbeat, domain and SSL checks and unmeasured days. It stops short of describing ordering of edge cases or rate-limit behavior, but covers the mutation-safe read profile well.

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?

Front-loaded with the return shape, then parameters, then error and time-zone behavior – a logical order. Dense but nearly every clause carries information; a slight trim of the parenthetical null explanation would tighten it further.

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?

Even though an output schema exists, the description still conveys row semantics, null conditions, default handling, error codes and time-zone effects. Together with full schema coverage and annotations, an agent has everything needed to call it correctly.

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?

Schema coverage is 100% so the baseline is 3, but the description adds real meaning: it explains how time_zone shifts day boundaries and that the response echoes the zone plus start_at/end_at, and it clarifies that days defaults to 30 and exceeding the plan limit yields an error rather than clamping.

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 ('Read one check's history') and pins down the shape precisely: one row per calendar day, oldest first, with the exact fields returned. It also explicitly excludes what it is not ('no individual runs or percentiles'), which separates it from list_check_runs and get_check_metrics.

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?

Gives clear usage context ('the summary to use for trends over weeks or months') and rules out the run-level/percentile alternatives. It does not name the sibling tools that would serve those needs, leaving the agent to infer which one to switch to.

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