InfraNest

List incidents

list_incidents

Read-onlyIdempotent

A paginated list of your monitors’ incidents with their monitor, status, impact, latest update and who acknowledged each one, and affected: how many monitors, servers and status pages it took down, counted across the incidents grouped with it. Counts are in meta. period is 24h, 7d (default), 30d or all; filter with status (open, acked or resolved) and search, or pass incident to fetch a single incident whatever its age. Defaults to the last 7 days; widen period to look further back, or pass incident_id for one incident whatever its age. For what happened during one incident use incident_timeline; to act on it, acknowledge_incident or add_incident_note.

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": "list_incidents"
  }
}

Input Schema

Name	Required	Description
`dir`	No	desc for newest or longest first.
`page`	No	Page number, from 1.
`sort`	No	started (default, oldest first) or duration.
`period`	No	How far back (default 7d).
`search`	No	Matches incident title or monitor name.
`status`	No	open: still down; acked: someone is on it.
`per_page`	No	Rows per page, up to 200 (default 25).
`incident_id`	No	Only this incident, whatever its age (period and status are ignored).
`organization_id`	No	The organization to read. Leave it out when the token reaches only one.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive behavior. The description adds useful context beyond that: counts are in `meta`, `affected` is counted across grouped incidents, and `incident_id` causes period/status to be ignored. It does not discuss rate limits or pagination mechanics beyond saying results are paginated.

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 dense but front-loaded with the return shape and key usage rules. There is slight repetition of the 7-day default and 'whatever its age' phrasing, but every sentence contributes to selecting and invoking the tool correctly.

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 nine-parameter list tool with no output schema, the description covers the returned fields, grouped count behavior, defaults, filtering, single-incident retrieval, and relevant sibling tools. An agent has enough information to choose and call this tool without missing critical context.

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 description coverage is 100%, so the baseline is 3. The description still adds meaning beyond the schema: it clarifies period defaults, status semantics, search matching, and that incident_id overrides period and status. Minor gaps remain around `organization_id` and sort/dir combinations, but the core parameters are well explained.

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 opens with a specific verb and resource (paginated list of incidents) and enumerates the per-incident fields returned (monitor, status, impact, latest update, acknowledger) plus grouped `affected` counts. It also names the sibling tools for related actions, so an agent can distinguish it from incident_timeline and acknowledge_incident without opening schemas.

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 explicitly states the default window (last 7 days), the valid `period` values, how to filter by `status` or `search`, and the special case of passing `incident` to fetch one record regardless of age. It also routes to incident_timeline for per-incident detail and to acknowledge_incident or add_incident_note for actions.

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.