rhombus-node-mcp 0.1.33 → 0.1.34

package/dist/tools/camera-tool.js

@@ -29,6 +29,29 @@ What follows is a description of the behavior of this tool given the requestType
 This tool retrieves the current configuration for a specified camera or associated device (e.g., sensor, access controller). The returned JSON object can include detailed camera settings (e.g., resolution, bitrate) and various device-specific configurations (e.g. storage settings).
 
 NOTE: To update camera settings, use the update-tool instead.
+
+---
+
+**AUTOMATIC SNAPSHOT FOR IMAGE QUALITY ISSUES** — When a user mentions camera image quality (darkness, brightness, blur, washed out, "doesn't look great", "fix the image", etc.), you MUST IMMEDIATELY:
+1. Call camera-tool with requestType "image" to capture a snapshot WITHOUT asking first.
+2. Analyze the image to identify quality issues.
+3. Call camera-tool with requestType "get-settings" to check current camera settings.
+4. Propose specific setting changes based on your analysis (store the exact values you plan to change, e.g. img_brightness, wdr_strength).
+5. When the user confirms ("yes", "confirm", "fix it", "apply", "go ahead", "ok", etc.), call update-tool with those stored settings — see update-tool's description for the confirmation flow. NEVER skip the update-tool call.
+
+Examples that REQUIRE the automatic snapshot flow:
+- "This camera's image doesn't look great"
+- "The image quality is poor"
+- "Can you fix the image"
+- "Adjust settings to be optimal"
+- "The camera looks blurry/dark/washed out"
+- Any mention of image appearance problems.
+
+**VISUAL-FEATURE CAMERA FILTERING** — When the user asks for cameras filtered by what they can see (indoors/outdoors, "facing the street", "with a view of X", parking lot, entrance), you MUST:
+1. First get the camera list via get-entity-tool or location-tool.
+2. Then call camera-tool with requestType "image" for EACH candidate camera (in PARALLEL).
+3. Analyze each image to determine if it meets the user's criteria.
+4. Return only the cameras that match.
 `;
 const logger = getLogger("camera-tool");
 const TOOL_ARGS = BASE_TOOL_ARGS;

package/dist/tools/door-schedule-exception-tool.js

@@ -23,6 +23,20 @@ It has the following modes of operation, determined by the "requestType" paramet
 - ${DoorScheduleExceptionRequestType.UPDATE_EXCEPTION}: Update a door schedule exception. Requires exception (DoorScheduleExceptionType object). If intervals are omitted but defaultState and date range are provided, the tool will generate a full-day interval.
 
 Use get-entity-tool to look up location and door UUIDs when needed.
+
+---
+
+**Mutating doorUuids on an existing exception (add/remove/replace doors):**
+\`update-exception\` REPLACES \`doorUuids\` with whatever you pass — it is not a delta operation. To safely remove or add doors while preserving the others:
+
+1. Call \`find-exceptions\` (or \`get-exception\`) to fetch the exception. The response includes the **full \`doorUuids\` array** for that exception — that IS the current door list.
+2. Compute the new array yourself:
+   - **Remove doors:** filter the existing \`doorUuids\` array, dropping the ones to remove.
+   - **Add doors:** append the new UUIDs to the existing array (deduped).
+   - **Replace wholesale:** just use the new set.
+3. Call \`update-exception\` with \`exception.uuid\` and \`exception.doorUuids\` set to your computed array. Other fields (name, dates, intervals, defaultState) are optional — omit them to leave them unchanged.
+
+**You already have the current door list in the find-exceptions response.** Do not ask the user for it, do not claim you need additional lookups, and do not refuse the mutation citing missing context. The doorUuids array you got back IS the context.
 `;
 function buildDateRangeFilter(args) {
     return {

package/dist/tools/get-entity-tool.js

@@ -4,15 +4,14 @@ import { TOOL_ARGS } from "../types/get-entity-tool-types.js";
 import { createToolTextContent, extractFromToolExtra } from "../util.js";
 const TOOL_NAME = "get-entity-tool";
 const TOOL_DESCRIPTION = `
-Retrieves entities (or devices) of certain types.
-Can request multiple entity types at once.
-The return structure is a JSON string that contains the states of the requested entities.
-This data is exact. Whatever entities exist will be returned here.
+Retrieves entities (or devices) of certain types — cameras, doorbell cameras, badge readers, access-controlled doors, audio gateways, door sensors, environmental sensors, motion sensors, buttons, keypads, environmental gateways. Can request multiple entity types at once. The return structure is a JSON string that contains the states (including names, UUIDs, location, model, firmware, connection status) of the requested entities. This data is exact.
 
-This is the primary tool for checking device health and connectivity status. Each device in the response
-includes a "connected" boolean field indicating whether it is currently online (true) or offline (false).
-When asked about device health, offline devices, or connectivity issues, use this tool to fetch all device
-types and check the "connected" field to identify which devices are offline or unreachable.`;
+**Primary use cases:**
+1. **Looking up a device by name.** When the user mentions a specific camera, door, sensor, etc. by name (e.g. "describe camera 1919 Front Door Entrance", "what's the status of HW Lab door"), call this tool with the matching entityType, scan the returned list, and **fuzzy/case-insensitive substring match** the user's reference against the \`name\` field. Don't ask the user to clarify — try this lookup first, and only ask if there are genuinely multiple plausible matches in the results.
+2. **Listing all devices of a type** (cameras, doors, sensors, etc.) for a location or org-wide.
+3. **Checking device health and connectivity.** Each device includes a \`connected\` boolean (true = online, false = offline). For "which devices are offline?" / "is X online?" / health questions, fetch the relevant entityTypes and inspect \`connected\`.
+
+When the user asks to "describe", "look up", "find", "show me", or "tell me about" a named device, this is almost always the right starting tool — call it before asking the user for more specifics.`;
 const TOOL_HANDLER = async (args, extra) => {
     const { entityTypes, timeZone, tempUnit } = args;
     const filterBy = args.filterBy ?? { locationUuids: null };

package/dist/tools/report-tool.js

@@ -6,6 +6,8 @@ const TOOL_NAME = "report-tool";
 const TOOL_DESCRIPTION = `
 **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.
 
+**Interval guidance:** A shorter interval (HOURLY instead of DAILY) gives a better representation of data over time. Balance interval and range so you don't request too much data. For ranges spanning a week or so, HOURLY is appropriate.
+
 ---
 
 **People / occupancy counting strategy**

package/dist/tools/time-tool.js

@@ -1,7 +1,11 @@
 import { parseTimeDescription } from "../api/time-tool-api.js";
 import { TOOL_ARGS } from "../types/time-tool-types.js";
 const TOOL_NAME = "time-tool";
-const TOOL_DESCRIPTION = "This tool is capable of returning the time from a natural language query.  If the user asks about the 'current time' use this tool.  Try to kee time_description as close to the users initial query as possible.  For example if someone says 'was X person seen today?' then time_description should be 'today'.";
+const TOOL_DESCRIPTION = `This tool returns timestamps from natural-language descriptions of time. If the user asks about the "current time", use this tool. Keep time_description as close to the user's original phrasing as possible — e.g. for "was X person seen today?" use time_description "today".
+
+**When to call:** Whenever the user provides a natural-language time description ("today", "5 days ago", "last week", "this morning"), call time-tool to get accurate timestamps. Do not invent timestamps yourself. If you will need a timestamp as input to another tool, call time-tool first; multiple parallel calls are fine.
+
+**Default timezone:** Assume "America/Los_Angeles" unless the user specifies otherwise or device/location context indicates a different one.`;
 const TOOL_HANDLER = async (args, extra) => {
     const { time_description, timezone } = args;
     const result = parseTimeDescription(time_description ?? undefined, timezone ?? undefined, extra);

package/dist/tools/update-tool.js

@@ -27,6 +27,21 @@ Future support planned for:
 - Badge readers
 
 The tool uses elicitation forms for rich user interaction and shows current settings before updates.
+
+---
+
+**CAMERA SETTINGS UPDATE FLOW** — Use this tool for ALL camera settings updates (brightness, contrast, WDR, resolution, audio, LED, etc.).
+- For camera image-quality fixes: provide entityType="camera", entityUuid, and the specific settings to change in cameraVideoSettings.
+- Example for dark image: update-tool(entityType="camera", entityUuid="<uuid>", cameraVideoSettings='{"img_brightness": 0, "wdr_strength": 64}').
+- Example for washed out: update-tool(entityType="camera", entityUuid="<uuid>", cameraVideoSettings='{"img_brightness": -50, "img_contrast": 80}').
+- Saturation matters — saturation 0 yields a grayscale image. Most cameras look best with mid-range values; tune from there.
+
+**CONFIRMATION FLOW (MANDATORY)** — When the conversation history shows you analyzed a camera and proposed fixes, and the user replies with any affirmative ("yes", "confirm", "fix it", "apply", "do it", "go ahead", "proceed", "sure", "ok"):
+1. DO NOT generate any text response first.
+2. IMMEDIATELY call update-tool with the camera settings you previously identified.
+3. Only after update-tool returns successfully, say "Done! Check your camera now…".
+
+NEVER respond saying settings were updated without first calling update-tool — without the call, no changes take effect. Avoid multiple rounds of confirmation; get one confirmation for all proposed changes.
 `;
 const TOOL_HANDLER = async (args, extra) => {
     const { entityType, entityUuid, cameraVideoSettings, cameraAudioSettings, cameraDeviceSettings, step, } = args;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "rhombus-node-mcp",
-  "version": "0.1.33",
+  "version": "0.1.34",
   "description": "MCP server for Rhombus API",
   "keywords": [
     "ai",