report-tool

**Scope:** This tool returns **aggregated counts and time-series summaries** over specified intervals and scopes. Use **events-tool** when you need raw, event-level data (individual events with timestamps). Use this tool for high-level reports, analytics, and trends—especially over periods of a day or more. --- **People / occupancy counting strategy** When asked to count people on a camera or at a location, follow this strategy: 1. **Always call GET_OCCUPANCY_ENABLED_CAMERAS first** to discover which cameras have occupancy counting enabled. 2. If the target camera IS in the list, call **GET_OCCUPANCY_COUNT_REPORT** for that device. The response will automatically include a `faceCountEnrichment` field with the number of unique individuals identified by face recognition in the same time range. Present both data sources: occupancy estimate and unique face count. 3. If the target camera is NOT in the list, **tell the user** that camera does not have occupancy counting enabled, and list the cameras that do. You can still call GET_SUMMARY_COUNT_REPORT with PEOPLE type — its response will also include `faceCountEnrichment` with unique face data as a fallback. If the PEOPLE count returns zero, the response will also include the list of occupancy-enabled cameras and a hint. 4. When both occupancy data and face recognition data are available, **synthesize both** in your answer (e.g., "Occupancy estimates ~15 people. Face recognition identified 9 unique individuals during this period."). **PEOPLE type (in GET_SUMMARY_COUNT_REPORT):** Not a unique person count; it counts people-detection events. Requires people detection to be enabled on the camera. Use for high-level activity trends, not for deduplicated head counts. --- **Summary and occupancy** - **GET_SUMMARY_COUNT_REPORT:** Aggregated counts (people, faces, motion, vehicles, etc.) over time at device, location, or org scope. Interval: minutely, hourly, daily, weekly, monthly, yearly. When called with PEOPLE type at DEVICE scope, the response is automatically enriched with face recognition data. - **GET_OCCUPANCY_ENABLED_CAMERAS:** List of cameras with occupancy reporting enabled. **Always call this first** before any people/occupancy counting request to verify camera support. - **GET_OCCUPANCY_COUNT_REPORT:** Occupancy count time series for a specific device over a time range. Response is automatically enriched with face recognition data. If the device does not support occupancy, the response will include a hint and the list of cameras that do. --- **Line crossing** - **GET_LINE_CROSSING_ENABLED_CAMERAS:** Cameras at a location with line crossing enabled, plus their configs. Call first to see which cameras support threshold crossing reports. - **GET_THRESHOLD_CROSSING_COUNT_REPORT:** Ingress/egress counts for line crossings over time. Supports human and vehicle detection; bucket size: quarter hour, hour, day, week. Response includes computed metrics: average entries/exits per hour, hour with most entries/exits, busiest hour (with breakdown). --- **Custom LLM events** - **FIND_PROMPT_CONFIGURATIONS:** All custom event prompt configurations (e.g. "black dog sightings", "delivery truck arrivals", "parking availability %"). Each has prompt text, UUID, and promptType (COUNT, PERCENT, BOOLEAN). Call first to discover available custom events. - **GET_CUSTOM_LLM_REPORT:** **This is the PRIMARY way to get custom event reports.** Aggregated time-series for one custom event by prompt UUID. Automatically selects the correct API based on promptType: COUNT (numeric counts), PERCENT (percentages), BOOLEAN (true/false). Intervals: minutely, quarter-hourly, hourly, daily, weekly, monthly. **Always use this for custom event reports, trends, and analytics.** Use FIND_PROMPT_CONFIGURATIONS first to get the promptUuid and promptType. - **GET_CUSTOM_EVENTS_REPORT:** Raw individual event values only (not aggregated). Use only when you need per-event granularity, not for reports or trends. --- **Audit and diagnostics** - **GET_AUDIT_FEED:** Audit log of all user/admin actions in the org over a time range. Returns who did what and when (principalName, targetName, action, displayText). - **GET_DIAGNOSTIC_FEED:** Device diagnostic events over a time range. - **GET_THRESHOLD_CROSSING_EVENTS:** Individual line-crossing events (not aggregated counts). - **GET_PEOPLE_COUNT_EVENTS:** Most recent people count readings for specified devices. **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.. It is categorised as a Read tool in the Rhombus Node MCP Server, which means it retrieves data without modifying state.

Add a rule in your Intercept YAML policy under the tools section for report-tool. You can allow, deny, rate-limit, or validate arguments. Then run Intercept as a proxy in front of the Rhombus Node MCP server.

report-tool is a Read tool with low risk. Read-only tools are generally safe to allow by default.

Yes. Add a rate_limit block to the report-tool rule in your Intercept policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

Set action: deny in the Intercept policy for report-tool. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

report-tool is provided by the Rhombus Node MCP server (rhombus-node-mcp). Intercept sits as a proxy in front of this server to enforce policies before tool calls reach the server.