Skip to main content
Glama
RhombusSystems

Rhombus MCP Server

Official

policy-alerts-tool

Retrieve Rhombus policy alerts triggered by AI events, device status changes, tampering, or access control events. Filter by time range, device, or location to find specific alerts.

Instructions

Retrieves Rhombus policy alerts. Policy alerts in the Rhombus system are generated based on user-defined alert policies configured in the Rhombus Console. These policies trigger alerts when specific events occur, such as:

  • AI & Computer Vision Events: Based on intelligent video analytics for motion, people, vehicles, facial recognition, license plate recognition, or unusual behavior.

  • Device Status Changes: Like camera disconnections or sensor low battery.

  • Physical or Visual Tamper: Detection of physical movement of a device or obstruction of a camera's field of view.

  • Access Control Events: Such as unauthorized access attempts in restricted areas.

Alerts are generated on triggers, but are NOT the same as notifications. Only certain alerts generate notifications based on user settings.

Can inquire about labels that have been seen.

Please note, this is not an exhaustive list, and there may be other types of triggers or events that generate policy alerts within the Rhombus system.

This tool allows you to filter existing alerts by existing/expiring, a specific time range (before or after a timestamp in ISO 8601 format), by a list of device UUIDs, or by a list of location UUIDs. You can also specify the maximum number of results to return. The output is provided in JSON format.

Pagination: Results are paginated and have a maximum page size. If the response includes a lastEvaluatedKey (for queryType "expiringSoon") or both lastTimestampISO and lastUuid (for queryTypes "existing" and "alert-groups"), more results are available. Pass these values back in the next call using the corresponding input parameters (lastEvaluatedKey, or lastTimestampISO and lastUuid) to retrieve the next page. Repeat until the response no longer includes these fields.

IMPORTANT: The "unhealthy-devices" queryType returns historical alert notifications that were triggered for device health issues. It does NOT return live/real-time device connection status. If no device health alert policies are configured, or alerts were dismissed, this may return empty even when devices are offline.

To check which devices are currently online/offline, use the get-entity-tool instead. The get-entity-tool returns the current state of all devices including their live connection status (the "connected" field). Request all entity types (CAMERA, DOORBELL_CAMERA, BADGE_READER, etc.) and check the "connected" field on each device to determine which are offline.

Output filtering (all tools):

  • includeFields (string[]): Dot-notation paths to keep in the response (e.g. "vehicleEvents.vehicleLicensePlate"). Omit to return all fields.

  • filterBy (array): Predicates to filter array items. Each entry: {field, op, value} where op is one of = != > >= < <= contains. All conditions are ANDed. Example: [{field:"vehicleLicensePlate", op:"=", value:"ABC123"}] WARNING: some tool responses exceed 400k characters — use these params to request only the data you need.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryTypeYesThe type of policy alerts to retrieve. Use "existing" to get current policy alerts, and "expiringSoon" to get policy alerts that are nearing their expiration date.
afterTimestampISOYesThe start of the time range for which to retrieve alerts. Only alerts that occurred AFTER this timestamp will be returned.Time format is in ISO 8601 format. Both UTC ("2025-08-04T20:54:27.123Z") and time zone offsets ("2025-08-04T13:54:27.123-07:00") are accepted to ensure an unambiguous point in time.
beforeTimestampISOYesThe end of the time range for which to retrieve alerts. Only alerts that occurred BEFORE this timestamp will be returned.Time format is in ISO 8601 format. Both UTC ("2025-08-04T20:54:27.123Z") and time zone offsets ("2025-08-04T13:54:27.123-07:00") are accepted to ensure an unambiguous point in time.
deviceFilterYesA list of UUIDs representing the specific devices to filter alerts by. Only alerts emitted by these devices will be returned. Please truncate any facets, such as .v0
locationFilterYesA list of UUIDs representing the specific locations to filter alerts by. Only alerts associated with these locations will be returned. Please truncate any facets, such as .v0
maxResultsYesThe maximum number of policy alerts to return. A good default is 100, but you may increase or decrease this number as needed. A reasonable hard maximum is 1000 alerts.
lastEvaluatedKeyYesOpaque pagination cursor from a previous response. When the response includes lastEvaluatedKey, pass it here on the next call to retrieve the next page. Used by queryType 'expiringSoon'.
lastTimestampISOYesPagination cursor (ISO 8601 timestamp). When the response includes lastTimestampISO, pass it here with lastUuid on the next call for the next page. Used by queryTypes 'existing' and 'alert-groups'.Time format is in ISO 8601 format. Both UTC ("2025-08-04T20:54:27.123Z") and time zone offsets ("2025-08-04T13:54:27.123-07:00") are accepted to ensure an unambiguous point in time.
lastUuidYesPagination cursor (UUID of last item). Pass together with lastTimestampISO from the previous response to fetch the next page. Used by queryTypes 'existing' and 'alert-groups'.
timeZoneYesThe timezone from the location of the camera of the policy alert, for formatting timestamps. This is necessary for the tool to produce accurate formatted timestamps.
alertUuidYesThe UUID of a specific policy alert. Required for 'details' and 'dismiss'.
includeFieldsYesDot-notation field paths to include in the response (e.g. "vehicleEvents.vehicleLicensePlate"). Pass null to return all fields. WARNING: some responses can exceed 400k characters — use includeFields to request only the data you need. For high-volume tools this may be required to get a complete answer.
filterByYesFilter array items in the response by field values. All conditions are ANDed. Example: [{field: "vehicleLicensePlate", op: "=", value: "ABC123"}, {field: "confidence", op: ">", value: 0.8}] Use alongside includeFields to get only the specific records and fields you need.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNo
errorMsgNo
policyAlertsYes
lastEvaluatedKeyNoIf present, more results are available. Pass this value as lastEvaluatedKey on the next call to get the next page (queryType 'expiringSoon').
lastTimestampISONoIf present with lastUuid, more results are available. Pass both as lastTimestampISO and lastUuid on the next call for the next page ('existing' or 'alert-groups'). ISO 8601 format.
lastUuidNoIf present with lastTimestampISO, more results are available. Pass both on the next call for the next page ('existing' or 'alert-groups').
Behavior5/5

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

With no annotations, the description fully discloses behavior: alerts vs notifications, unhealthy-devices returns historical not live data, large response warning, pagination details for different query types. No contradictions.

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 description is very long and dense, covering many aspects but lacking conciseness. It repeats some schema info and could be more streamlined. However, it is well-structured with sections.

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?

Given the complexity (13 params, multiple query types, pagination, output filtering), the description is highly complete. It covers pagination per query type, output filtering warnings, and sibling tool differentiation. It explicitly states it's not exhaustive, setting expectations.

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%, baseline 3. Description adds meaning for queryType enum values, time format details, pagination cursors, and output filtering. It goes beyond schema by explaining when to use each pagination parameter.

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 clearly states 'Retrieves Rhombus policy alerts' and distinguishes them from notifications. It explains what triggers alerts and contrasts with get-entity-tool for live device status, effectively differentiating from siblings.

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?

Explicit guidance on when to use this tool (for policy alerts) and when not to (for live device status, use get-entity-tool). It also explains pagination and output filtering, providing clear context for alternative usage.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/RhombusSystems/rhombus-node-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server