PingRelay MCP Server

incident_list

Read-onlyIdempotent

Search a page of non-deleted incident summaries in the authenticated organization, ordered by descending incident ID (newest first). Includes active and resolved incidents by default. Only incidents with both description and details populated are listed. Defaults to page 1 with 25 results; use IncidentSummary for aggregate counts or IncidentReport for trends.

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

Input Schema

Name	Required	Description
`search`	No	Optional substring match in description or details; omitted or empty means no text filter.
`pageSize`	No	Maximum results per page, from 1 through 100; default 25.
`pageNumber`	No	One-based page number; must be at least 1. Default 1.
`isActiveOnly`	No	True filters to incidents whose IsActive flag is set. False includes active and resolved incidents; default false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 8, 2026

addedInput schema / properties / isActiveOnly / description

Added value: +"True filters to incidents whose IsActive flag is set. False includes active and resolved incidents; default false."

addedInput schema / properties / pageNumber / description

Added value: +"One-based page number; must be at least 1. Default 1."

addedInput schema / properties / pageSize / description

Added value: +"Maximum results per page, from 1 through 100; default 25."

addedInput schema / properties / search / description

Added value: +"Optional substring match in description or details; omitted or empty means no text filter."

First observedNov 7, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, and the description still adds non-obvious traits: deleted incidents are excluded and only incidents with both description and details populated appear. It does not cover result volume beyond page size or whether a total count is returned, but the extra filtering behavior is genuinely useful.

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 core operation and ordering, then eligibility rules, then defaults, then sibling routing. The page-1/25 default sentence duplicates schema defaults and slightly crowds the paragraph, but nothing is wasted outright.

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 four-parameter, all-optional read tool with full schema coverage and safety annotations, the description covers scope, filtering, ordering, and alternatives adequately. Without an output schema, some indication of whether a total count is returned would be the only meaningful addition.

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 coverage is 100%, so all four parameters are already documented in the schema, including defaults and the active/resolved semantics of isActiveOnly. The description reinforces the default inclusion of active and resolved incidents and the page-1/25 default, but adds no new syntax or edge-case detail beyond the schema.

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 ('Search a page of non-deleted incident summaries in the authenticated organization') plus scope, ordering (descending incident ID, newest first), and default inclusion rules. An agent can distinguish it from incident_get or incident_report without opening the schema.

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?

Explicitly routes aggregate and trend use cases to IncidentSummary and IncidentReport, which is real when-to-use guidance. It stops short of distinguishing the remaining siblings (incident_get for a single incident, incident_alert_history) but no agent would be misled.

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

All PingRelay MCP Server tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?