PingRelay MCP Server

monitor_list

Read-onlyIdempotent

List non-deleted monitor summaries for the authenticated organization, optionally filtering by name and effective state. State precedence is disabled, paused, maintenance, then up/down/unknown. No pagination or result limit. LastCheckedAt currently reflects the stored scheduled execution time, not proof of a completed check; use MonitorLatestChecks for actual checks.

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

Input Schema

Name	Required	Description
`search`	No	Optional substring match on the monitor name; omitted or empty means no name filter.
`status`	No	Optional effective state: up, down, paused, maintenance, disabled, or unknown. Use lowercase; omitted or empty means all states.
`includePaused`	No	Include paused monitors by default. False excludes monitors with a paused flag or stored paused status, even when another state takes precedence.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 8, 2026

addedInput schema / properties / includePaused / description

Added value: +"Include paused monitors by default. False excludes monitors with a paused flag or stored paused status, even when another state takes precedence."

addedInput schema / properties / search / description

Added value: +"Optional substring match on the monitor name; omitted or empty means no name filter."

addedInput schema / properties / status / description

Added value: +"Optional effective state: up, down, paused, maintenance, disabled, or unknown. Use lowercase; omitted or empty means all states."

First observedNov 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description still adds substantial behavioral context: deleted monitors are excluded, there is no pagination or result limit, and LastCheckedAt is a scheduled time rather than proof of a completed check. The state-precedence ordering is disclosed behavior that no structured field conveys.

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

Conciseness5/5

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

Four sentences, front-loaded with the core purpose, then filtering semantics, then the pagination caveat, then the LastCheckedAt warning. Every sentence adds a distinct operational fact and nothing is repeated from the schema verbatim.

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?

There is no output schema, so the description carries the burden of describing returns, and it does so by characterizing results as monitor summaries and by flagging the misleading LastCheckedAt field. For a read-only three-parameter list tool, nothing an agent needs in order to call it correctly is missing.

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, and the description goes beyond it by defining 'effective state' and spelling out the precedence chain (disabled, paused, maintenance, then up/down/unknown). That precedence is essential to interpreting the status filter and is not derivable from the schema alone.

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?

Opens with a specific verb and resource plus scope: 'List non-deleted monitor summaries for the authenticated organization', then names the two filter axes. An agent can distinguish it from monitor_get (single monitor), monitor_list_recent, and monitor_latest_checks without opening any 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 the agent to MonitorLatestChecks when actual check data is needed, which is a real when-to-use-this-instead signal. It does not address the closer siblings monitor_list_recent or monitor_get, so the sibling differentiation is partial rather than complete.

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?