InfraNest

Monthly uptime report

uptime_report

Read-onlyIdempotent

Uptime per monitor for one calendar month, with downtime, incidents, longest outage and the basis of each figure. Planned maintenance and time a monitor was paused are left out of the uptime and downtime; planned maintenance is reported beside them: planned_minutes_excluded per monitor and planned_minutes in the summary. A monitor with an uptime target carries uptime_target and an allowance: the month’s allowed_minutes, used_minutes, remaining_minutes, the projected_uptime_pct and projected_miss_on at the pace so far, and a status (met or missed for a closed month; on_track, at_risk or missed for the current one). The summary counts targets_set and targets_missed. Pass month as YYYY-MM (default: the last full month; the current month gives the allowance left so far) and tag to limit it to monitors with that tag. A monitor with an uptime target carries uptime_target and allowance (allowed, used and remaining minutes, projected_uptime_pct, projected_miss_on, status). The figures are calendar-month and unweighted, which is not the status page's impact-weighted figure.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

Name	Required	Description
`tag`	No	Only things with this tag id.
`month`	No	The month as YYYY-MM (default: last full month). The current month gives each uptime target's allowance used and left so far, and the day it runs out at that pace.
`organization_id`	No	The organization to read. Leave it out when the token reaches only one.

Output Schema

Name	Required	Description	Default
`month`	No
`checks`	No
`closed`	No
`summary`	No
`findings`	No
`generated_at`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description adds real value beyond them: planned maintenance and paused time are excluded from uptime/downtime, planned minutes are surfaced separately, and the current-month call behaves differently (partial allowance, projection basis). That is genuine behavioral context rather than restated hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The scope is front-loaded well, but the description is bloated: the allowance paragraph ('A monitor with an uptime target carries `uptime_target` and an `allowance`... allowed, used, remaining minutes, projected_uptime_pct, projected_miss_on, status') is stated twice in near-identical form. That redundancy costs space without adding information.

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?

For a report tool with an output schema and full annotation coverage, the definition supplies what an agent actually needs: month default behavior, exclusion rules for maintenance/paused time, target-status values per closed vs current month, and the meaningful distinction from the impact-weighted status-page figure. Only the explicit sibling trade-off is missing.

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%, so baseline is 3. The description adds modest meaning — that `tag` limits the report to monitors carrying it and that `month` defaults to the last full month and yields partial allowance for the current month — but this largely restates the schema verbatim rather than explaining new semantics such as tag-id sourcing or timezone basis.

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?

The opening sentence states a specific verb+resource+scope ('uptime per monitor for one calendar month') and enumerates what is included (downtime, incidents, longest outage). It distinguishes itself from the status page's impact-weighted figure but never names or contrasts with the closest siblings (monitor_stats, monitor_results), so an agent must infer which uptime tool to pick.

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?

Useful operational guidance exists — 'Pass `month` as YYYY-MM (default: the last full month...)' and 'tag to limit it to monitors with that tag' — so the how is clear. But there is no explicit statement of when to choose this over monitor_stats or monitor_results, which are the obvious alternatives for uptime metrics; the choice is left implied.

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

All InfraNest 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.