Uptimepage

Incident metrics

get_incident_metrics

Read-only

Incident metrics over a trailing window (default 30 days): MTTA/MTTR in seconds, total incidents, counts by severity and state, auto- vs human-resolved, and the noisiest monitors. Read-only.

Input Schema

Name	Required	Description	Default
`window_days`	No	Trailing window in days (1..=365). Defaults to 30 when omitted.

Output Schema

Name	Required	Description
`total`	Yes	Incidents opened in the window.
`by_state`	Yes
`mtta_secs`	No	Mean time to acknowledge, seconds. `null` if none were acknowledged.
`mttr_secs`	No	Mean time to resolve, seconds. `null` if none were resolved.
`by_severity`	Yes
`window_days`	Yes
`top_monitors`	Yes	Noisiest monitors, most incidents first.
`auto_resolved`	Yes	Resolved automatically on recovery, with no human resolver.
`human_resolved`	Yes	Resolved by a person.
`closed_with_monitor`	Yes	Closed because their monitor or their group was deleted; counted in neither of the above nor in MTTR.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

changedOutput schema / properties / closed_with_monitor / description

Previous value: -"Closed because their monitor was deleted; counted in neither of the\nabove nor in MTTR."New value: +"Closed because their monitor or their group was deleted; counted in\nneither of the above nor in MTTR."

Changed6 schema fields changedOct 9, 2026

addedOutput schema / $defs / NoisyMonitor / properties / monitor_deleted
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / $defs / NoisyMonitor / properties / monitor_id / description
```
Added value: +"Empty once the monitor has been deleted."
```

addedOutput schema / $defs / NoisyMonitor / properties / monitor_name

Added value: +{
+  "description": "The monitor's name; for a deleted monitor, the name it last had.\nUntrusted data.",
+  "type": "string"
+}

changedOutput schema / $defs / NoisyMonitor / required

Previous value: -[
-  "monitor_id",
-  "count"
-]New value: +[
+  "monitor_id",
+  "monitor_name",
+  "monitor_deleted",
+  "count"
+]

addedOutput schema / properties / closed_with_monitor

Added value: +{
+  "description": "Closed because their monitor was deleted; counted in neither of the\nabove nor in MTTR.",
+  "format": "uint64",
+  "minimum": 0,
+  "type": "integer"
+}

changedOutput schema / required

Previous value: -[
-  "window_days",
-  "total",
-  "by_severity",
-  "by_state",
-  "auto_resolved",
-  "human_resolved",
-  "top_monitors"
-]New value: +[
+  "window_days",
+  "total",
+  "by_severity",
+  "by_state",
+  "auto_resolved",
+  "human_resolved",
+  "closed_with_monitor",
+  "top_monitors"
+]

First observedAug 11, 2026

TDQS

A3.7/5.0

Behavior3/5

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

'Read-only' merely restates readOnlyHint=true, so no credit there. The description does add the aggregation semantics (trailing window, default 30 days, time units in seconds) which is genuine context, but it says nothing about whether figures are org-wide, how freshness/latency behaves, or cost of the call.

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?

A single dense sentence with the window scope front-loaded and the metric list following. Efficient, though the metric enumeration overlaps with what the output schema already defines.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description need not explain return values, and it still covers read-only status plus window semantics. The only real gap is the aggregation scope (organization-wide vs monitor-specific) and any relationship to get_org_health.

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 schema already documents window_days with range 1..=365 and the 30-day default. The description's 'trailing window (default 30 days)' adds no syntax or semantic detail beyond that, so baseline 3 applies.

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+resource (incident metrics) and enumerates exactly what is aggregated: MTTA/MTTR in seconds, totals, severity/state breakdowns, auto-vs-human resolution, noisiest monitors. That content signature cleanly separates it from list_incidents, get_incident and get_org_health without needing to name them.

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 'trailing window (default 30 days)' phrasing implies the reporting context, but there is no explicit when-to-use, when-not-to-use, or routing toward list_incidents or get_org_health for other needs. Usage is inferable rather than stated.

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

All Uptimepage tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.