Skip to main content
Glama

list_protect_events

Query historical UniFi Protect events (motion, smart-detect, sensor open/close) from an NVR for a given time range, filtering by type, smart-detect subtype, camera, or category.

Instructions

Query historical Protect events (motion, smart-detect, sensor open/close, etc.).

This uses the private /proxy/protect/api/events REST path — the ONLY source of historical events. The official Protect Integration API exposes events solely over WebSocket (/v1/subscribe/events) with no REST query endpoint, so do not expect the integration path to answer this.

REQUIRED: host, start, and end. start/end are epoch SECONDS as INTEGERS (e.g. 1690000000 for 2023-07-22T06:13:20Z), NOT milliseconds and NOT an ISO 8601 string: a millisecond-magnitude value is rejected up front, and a string fails schema validation. This differs on purpose from query_isp_metrics, whose start_time/end_time are ISO 8601 STRINGS — do not carry a format across the two tools.

host: console name, ID, or composite ID (MAC:numericId format). start/end: REQUIRED. Epoch SECONDS (UTC) as integers, converted to milliseconds internally. Ranges are inclusive on both ends. History depth is bounded by the NVR's retention. (Contrast query_isp_metrics, which wants ISO 8601 strings.) types: filter by event TYPE; single value or a list. Verified-present values: motion, smartDetectZone, smartAudioDetect, sensorOpened, sensorClosed, access. NOTE: person/face/animal/alrmSpeak are NOT event types — they are smart-detect subtypes and belong in smart_detect_types, not here. An unrecognised value returns zero events. smart_detect_types: filter by the smart-detect SUBTYPE — person, vehicle, animal, package, face, licensePlate (on smartDetectZone events) and the audio alarms alrmSpeak, alrmSiren, alrmBark, alrmCarHorn (on smartAudioDetect events). This is a distinct upstream parameter from types. The API only honours it when types is also set to the relevant event type(s); passing smart_detect_types alone is a silent no-op upstream, so this tool rejects that with a clear error. Example: types="smartDetectZone", smart_detect_types="person" for just person detections; types="smartAudioDetect", smart_detect_types="alrmSpeak" to isolate the dominant audio-alarm noise. cameras: filter by camera NAME or ID; single value or list. Names resolve to IDs (case-insensitive) — an unknown name errors rather than silently matching nothing. categories: filter by event category; single value or list. Verified values: motion, smart, iot, admin. Unknown values are silently ignored by the upstream API. without_descriptions: when true, ask the API to omit each event's description block (~16% smaller payload). Opt-in only — full-fidelity records are the default and descriptions are never dropped automatically. limit/offset: offset-based pagination (not cursor-based). By default (neither given) every page is drained and the complete event set for the window is returned — a wide window can hold tens of thousands of events, so expect all of them, not just the first page. Pass offset or limit to fetch a single manual page instead; a capped drain is flagged incomplete rather than truncating. order_direction: "ASC" (default, oldest-first) or "DESC" (newest-first).

Sensor events set the top-level sensor field to null; the sensor reference at metadata.sensorId.text is promoted to that field so you can filter/join on it. Events are passed through verbatim, including identifiers (MAC/IP/hostname/name) and the metadata.name object carrying camera / recognised-person / license-plate text; the recognised-person name on face events is at metadata.detectedThumbnails[].matchedName.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endYes
hostYes
limitNo
startYes
typesNo
offsetNo
camerasNo
categoriesNo
order_directionNoASC
smart_detect_typesNo
without_descriptionsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Install Server

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries full burden and does so thoroughly. It discloses internal behaviors: epoch seconds converted to milliseconds internally, inclusive ranges, retention-bounded history, pagination behavior (default drains all pages, capped drain flagged incomplete), sensor field promotion, and verbatim passthrough of identifiers. It also reveals silent no-op upstream behavior for smart_detect_types alone and unknown-type handling. These are critical behavioral traits not visible in the schema, and they are described clearly.

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?

The description is long but every sentence earns its place. It is organized logically: summary first, then the rare API-path constraint, then required parameters with format warnings, then optional filters, then pagination, then ordering, then return-value caveats. The prose is dense yet readable, and no redundant or filler sentences exist. The length is justified by the tool's complexity and the zero-coverage schema.

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 an 11-parameter tool with no annotations and 0% schema coverage, the description is remarkably complete. It covers all parameters, edge cases, error conditions, upstream quirks, pagination behavior, and return-field semantics. With an output schema present, the description did not need to list return fields, but it still adds meaningful detail about passthrough and field promotion. Nothing an agent needs to correctly invoke the tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain every parameter, and it does. Each of the 11 parameters gets a dedicated explanation: host formats, start/end unit constraints, types enumerated with verified values and note about subtypes, smart_detect_types with dependency on types, cameras with case-insensitive resolution, categories with verified values and unknown-value behavior, without_descriptions purpose, limit/offset pagination semantics, and order_direction allowed values. This far exceeds what the bare schema provides.

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 clear verb-resource combination ('Query historical Protect events') and enumerates event types. It explicitly distinguishes itself from sibling tools by naming the private REST path and contrasting with the official WebSocket-only integration API, and later contrasts parameter formats with query_isp_metrics. This leaves no ambiguity about what the tool does or how it differs from related tools.

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?

The description provides explicit when-to-use guidance: it states the private path is the ONLY source of historical events, warns that the integration API cannot answer this, and tells agents to not expect the integration path. It also gives clear conditional rules (e.g., smart_detect_types is honored only when types is set, otherwise the tool rejects it with a clear error), and contrasts with query_isp_metrics for parameter formats. Examples are provided for common use cases, making usage boundaries explicit.

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

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/swkstudios/unifi-fabric-mcp-server'

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