Gear MCP Server

List alarms

list_alarms

Read-onlyIdempotent

Retrieves alarms for a single client, facility, device, or endpoint, filtered by open, closed, or all states and date range; returns newest first, up to 500 records.

Instructions

Alarms of exactly one client, facility, device or endpoint. state: open (default), closed or all. Newest first, up to 500.

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_alarms"
  }
}

Input Schema

Name	Required	Description
`max`	No	Default 100
`state`	No
`date_to`	No	UTC date, "2026-10-01" or "2026-10-01T08:00:00Z"
`client_id`	No
`date_from`	No	UTC date, "2026-10-01" or "2026-10-01T08:00:00Z"
`device_id`	No
`endpoint_id`	No
`facility_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 30, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavior: newest-first ordering and the 500-record ceiling. It does not say what happens when more than 500 match or what an alarm record contains.

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?

Three short fragments, front-loaded with the scope constraint then state then ordering/limit. Extremely economical, though the telegraphic style (no verb, no full sentence) costs a little readability.

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

Completeness3/5

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

With 8 parameters, no output schema and 38% schema coverage, the description covers ordering, cap and the selector rule but leaves gaps: no description of the returned alarm shape, no explanation of date-range filtering, and no statement of what 'exactly one' means operationally (error vs. intersection).

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 only 38%, and the description compensates with the single most important semantic rule: exactly one of client_id/facility_id/device_id/endpoint_id must be supplied — a constraint the JSON schema does not enforce via oneOf. It also restates the state default and the max cap, though date_from/date_to semantics come only from the schema.

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?

Identifies the resource (alarms) and a strong scoping constraint ('of exactly one client, facility, device or endpoint'), which tells an agent this is a filtered list. It is a fragment without a verb and never names a sibling, but none of the siblings (list_devices, get_endpoint_history, find_devices) list alarms, so confusion risk is low.

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?

'state: open (default), closed or all' gives an implied default and the 'exactly one ... client, facility, device or endpoint' phrasing hints at the required selector. There is no explicit when-to-use/when-not guidance and no mention of what to do if you need alarms across multiple entities.

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

Deploy Server