bi-mcp 0.2.0__tar.gz

bi_mcp-0.2.0/.claude/hooks/run_tests_advisory.sh

@@ -0,0 +1,56 @@
+#!/usr/bin/env bash
+# Advisory test runner — fires on PostToolUse for Edit/Write under bi-mcp.
+#
+# Behavior:
+#   • Silent on pass (no output → no extra tokens, no noise).
+#   • Loud on fail (clear header + pytest short summary).
+#   • Exit 0 always — this is advisory, not blocking. Claude sees the
+#     output and decides whether to fix immediately or defer.
+#
+# Hook payload (PostToolUse) arrives on stdin as JSON. We only care about
+# the edited file path; if it isn't under src/ or tests/, we skip silently.
+
+set -u
+
+REPO_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/../.." && pwd)"
+PYTEST="$REPO_ROOT/.venv/bin/pytest"
+
+# Read hook payload from stdin (best-effort — tolerate missing/odd shape).
+payload="$(cat || true)"
+
+# Extract tool_input.file_path with a tiny inline python (jq isn't a hard
+# dep on every host). Falls through to empty string on any parse failure.
+file_path="$(printf '%s' "$payload" | python3 -c '
+import json, sys
+try:
+    d = json.loads(sys.stdin.read() or "{}")
+    print((d.get("tool_input") or {}).get("file_path", ""))
+except Exception:
+    print("")
+' 2>/dev/null)"
+
+# Only run when an edit landed under src/ or tests/. Anything else
+# (README tweaks, AGENTS.md, settings) doesn't affect test behaviour.
+case "$file_path" in
+  "$REPO_ROOT"/src/bi_mcp/*|"$REPO_ROOT"/tests/*) ;;
+  *) exit 0 ;;
+esac
+
+# Pytest must exist — if the venv is gone, surface that once and bail.
+if [[ ! -x "$PYTEST" ]]; then
+  echo "⚠️  bi-mcp tests skipped: $PYTEST not found. Run: .venv/bin/pip install 'pytest>=8'" >&2
+  exit 0
+fi
+
+# Run quietly; capture output so we can decide whether to emit anything.
+output="$("$PYTEST" "$REPO_ROOT/tests/unit/" -q --no-header --tb=line 2>&1)"
+rc=$?
+
+if [[ $rc -ne 0 ]]; then
+  # Loud header so the failure stands out in the conversation transcript.
+  echo "❌ bi-mcp tests FAILED after edit to ${file_path#$REPO_ROOT/}" >&2
+  echo "$output" >&2
+fi
+
+# Always exit 0 — advisory, never blocks the edit.
+exit 0

bi_mcp-0.2.0/.claude/settings.json

@@ -0,0 +1,16 @@
+{
+  "$schema": "https://json.schemastore.org/claude-code-settings.json",
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "Edit|Write",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/run_tests_advisory.sh"
+          }
+        ]
+      }
+    ]
+  }
+}

bi_mcp-0.2.0/.claude/skills/bi-troubleshoot/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: bi-troubleshoot
+description: Structured walk for "camera X is missing alerts" or "alerts are firing wrong on camera X" — read alert pattern, drill into config (BI then .reg), form one hypothesis, test it (optional bi_trigger_camera), verify.
+disable-model-invocation: true
+---
+
+# bi-troubleshoot — alert pipeline diagnosis
+
+Use this when the user reports an alert problem on a specific camera —
+missing alerts, spurious alerts, wrong classification, alerts at the wrong
+times of day. Do NOT use for connectivity / PTZ / recording issues; those
+need different surfaces.
+
+## Step 1 — Confirm the symptom in data
+
+```
+bi_list_alerts(camera="<short>", limit=50)
+```
+
+Look at the time distribution, AI memo, and zone hits. Don't trust the
+user's framing alone — they may have miscounted, or the issue may be
+different from how they described it.
+
+If they gave you a time range:
+
+```
+bi_list_alerts(camera="<short>", startdate=<unix>, enddate=<unix>, limit=200)
+```
+
+If you need clip context (was it recording? what resolution?):
+
+```
+bi_list_clips(camera="<short>", view="alerts", limit=20)
+```
+
+## Step 2 — Read top-level config
+
+```
+bi_get_camera_config(short="<short>")
+```
+
+Note `sense`, `contrast`, `recmode`, `aizones`, profile/schedule flags.
+The `_note` field tells you whether you got the admin (deep) or fallback
+(shallow) view.
+
+## Step 3 — Drill into what camconfig doesn't expose
+
+Pick the area that matches the symptom:
+
+| Symptom                                | `bi_get_reg` key_path                                |
+| -------------------------------------- | ---------------------------------------------------- |
+| Wrong AI classification / thresholds   | `AI\\<profile>` (smartconf, smartlabels, smartzones) |
+| Trigger zones look wrong               | `Motion\\<profile>` (maskbits_*, objmaxpercent10)    |
+| Alerts not firing during PTZ preset    | `PTZ\\Presets` (noalerts flag per preset)            |
+| Dahua IVS not reaching BI              | `camevents` (ONVIF event handlers)                   |
+| Wrong action (no email/webhook)        | `Alerts\\OnTrigger`                                  |
+
+If `bi_get_reg` returns `meta.stale: true`, stop and ask the user to
+re-export the camera before continuing — stale data will lead you astray.
+
+## Step 4 — Form ONE hypothesis
+
+Write it down in user-visible text. Examples:
+
+- "AI confidence is 70 in profile 3; person events at night are scoring
+  60-65 because of low contrast — they're below threshold."
+- "Preset 5 has noalerts=1 set, so alerts during that preset are
+  deliberately suppressed. Either the preset is wrong or the noalerts
+  flag is."
+
+Only one hypothesis. If you have multiple, pick the one you can falsify
+fastest.
+
+## Step 5 — Test the hypothesis (mutations path)
+
+If `BI_MCP_ALLOW_MUTATIONS` is enabled, you can close the loop:
+
+```
+bi_trigger_camera(camera="<short>", memo="diagnose-<symptom>")
+bi_list_alerts(camera="<short>", limit=1)
+```
+
+The memo should appear on the new alert. If the alert didn't fire, or
+fired with a different classification than you expected, your hypothesis
+is wrong — go back to step 2.
+
+If mutations are disabled, ask the user to wave at the camera (or
+otherwise generate motion) and re-run step 1.
+
+## Step 6 — Report
+
+User-visible answer should include:
+
+- One-line root cause
+- The specific setting (registry key, BI menu path) that's responsible
+- A concrete change to make (don't apply it yourself — the user owns
+  the BI UI)
+- Citation: which AGENTS.md / BlueIris_Manual.md section confirms the
+  diagnosis
+
+## Anti-patterns
+
+- ❌ Walking all the .reg subkeys "in case something looks wrong" —
+  pick the one matching the symptom
+- ❌ Forming multiple hypotheses and asking the user which to pursue —
+  pick one, test it, iterate
+- ❌ Looping `bi_trigger_camera` — one call, observe, move on
+- ❌ Re-fetching `bi_list_cameras` for identity facts already in
+  `project_camera_roster.md`

bi_mcp-0.2.0/.env.example

@@ -0,0 +1,38 @@
+# Blue Iris web server endpoint
+BI_HOST=192.168.1.10
+BI_PORT=81
+
+# Dedicated low-privilege Blue Iris user (Settings > Users in BI).
+# Do NOT use your admin account. Give this user LAN access only.
+BI_USER=
+BI_PASS=
+
+# Optional admin user — for tools that hit BI cmds gated behind admin rights:
+#   bi_get_camera_config (deep camconfig path), bi_list_log, bi_get_sysconfig.
+# Recommended setup: create a SECOND user in Blue Iris with admin enabled.
+# If you leave these blank and your BI_USER above already has admin rights,
+# that user will automatically be used for admin-gated cmds. If neither path
+# yields an admin user, those tools degrade or raise admin_required.
+BI_ADMIN_USER=
+BI_ADMIN_PASS=
+
+# Set to 1 to register the mutating tools: bi_trigger_camera, bi_set_ptz_preset,
+# bi_set_profile. With the flag off (default), they're not registered at all.
+# READ AGENTS.md § "Mutation patterns" before enabling.
+BI_MCP_ALLOW_MUTATIONS=0
+
+# Optional overrides for bi_get_reg (the .reg parser tool).
+# Defaults are resolved relative to the *current working directory* at the
+# time the tool is called — Claude Code launches the server from the
+# project directory, so by default that's <project>/.reg-venv/ and
+# <project>/cam settings/.
+#
+# Set these to absolute paths if your layout differs:
+# BI_MCP_REG_VENV_PYTHON: absolute path to a Python with python-registry
+# BI_MCP_REG_DIR: absolute path to the directory holding <camera>.reg exports
+#BI_MCP_REG_VENV_PYTHON=
+#BI_MCP_REG_DIR=
+
+# Optional: enable verbose logging to stderr + a rotating file.
+# Default is silent. Set to 1 when debugging.
+BI_MCP_DEBUG=0

bi_mcp-0.2.0/.gitignore

@@ -0,0 +1,12 @@
+.env
+.venv/
+__pycache__/
+*.pyc
+*.pyo
+dist/
+build/
+*.egg-info/
+.pytest_cache/
+.ruff_cache/
+.mypy_cache/
+.audit/