Skip to main content
Glama

list_recognition_detections

Get all individual sightings for a recognition group on a Protect console. Specify group_id and type to retrieve detections with timestamps, cameras, and confidence scores.

Instructions

List a recognition group's detections (individual sightings) on a Protect console.

REQUIRED: both type and group_id. group_id identifies which enrolled subject to list sightings for — obtain a valid one from list_recognition_groups (its id field, e.g. face_90); there is no "all groups" mode. Calling without group_id fails schema validation, and passing an id that does not exist on the console returns HTTP 404.

Each detection carries id, eventId (joinable against list_protect_events), thumbnailId (fetch the crop with get_thumbnail), detectedAt (epoch ms), cameraId, and matchedGroupConfidence (0-100).

Response shape: {"detections": [...], "count": N} (plus "nextPage" / "incomplete" when paging manually). The array key is "detections", NOT "data" — unlike the offset-proxy tools that return {"data": [...], "totalCount": N}; read the list from result["detections"].

host: console name, ID, or composite ID (MAC:numericId format). type: recognition type. Use 'face' or 'vehicle' (singular -- plural forms return HTTP 400 from upstream). Forwarded to the API as-is. group_id: REQUIRED. The group's stable id, e.g. face_90 — take it from a list_recognition_groups result (the id field). Not optional; not guessable. page_size: API page size; also the drain page size. Defaults to 200. start/end: optional time window in epoch SECONDS (UTC), converted to milliseconds internally. Verified live: the endpoint filters detections server-side by detectedAt against this window, so an arbitrary range (e.g. the last hour, 30 days, or 90 days) can be requested directly. Omit both for all detections. page: fetch a single page (1-based) instead of draining. The response pages via a links.next envelope; by default every page is drained so the complete detection set for the group (and window, if given) is returned. Pass page to fetch one page manually — nextPage is then surfaced.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNo
hostYes
pageNo
typeYes
startNo
group_idYes
page_sizeNo

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 provided, the description carries the full behavioral burden and does so thoroughly. It discloses HTTP 404 for nonexistent IDs, HTTP 400 for plural types, server-side time-window filtering, epoch-millisecond conversion, response key naming ('detections' not 'data'), default page size, and default full draining behavior.

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 adds operational value, and it is logically organized: overview, response shape, paging expectations, then parameter-by-parameter details. The structure makes the length justified rather than bloated.

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?

The description fully compensates for the lack of annotations and 0% schema coverage. It covers response format, parameter semantics, failure modes, pagination behavior, and relationships to sibling tools (list_recognition_groups, list_protect_events, get_thumbnail), leaving no critical gap for an agent to call this tool correctly.

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 parameter gets concrete semantics: host formats, type value constraints, group_id provenance, page_size default, start/end units and conversion, and page behavior.

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 uses a specific verb ('List'), names the exact resource ('a recognition group's detections'), and clarifies it is about 'individual sightings' on a Protect console. It differentiates this from sibling tools like list_recognition_groups by focusing on detections rather than groups.

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 explicitly states required parameters, the prerequisite of obtaining group_id from list_recognition_groups, and the absence of an 'all groups' mode. It also warns against plural type values, explains the paging/draining behavior, and notes the distinction from offset-proxy tools, giving clear selection and invocation guidance.

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