Skip to main content
Glama
whoamiTM

bi-mcp

by whoamiTM
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

bi_audit_actions

Read-only

Compares action rows across cameras to surface field values that deviate from the group norm or lack a majority, so you can confirm whether per-camera differences are intentional or accidental.

Instructions

Informational tool — surfaces cross-camera action-row outliers for user review. Walks every camera's .reg export, buckets action rows into cohorts by (type, description, type-specific key), and reports fields where one camera's value deviates from the cohort's modal value under 'outliers'; fields with no strict majority appear there as entries with no_majority=true listing each value and its members. Per-camera path tokens (e.g. 'ai/SecCam_3/motion') are templated to '' before comparison so legitimate per-camera substitution doesn't false-positive. The 'enabled' field is reported separately under 'disabled_outliers' so a row left disabled by accident is easy to spot. Outliers are NOT necessarily bugs — they may be intentional per-camera customizations (e.g. one camera filtering different trigger sources, or running a narrower profile set). Present findings to the user as 'values worth confirming' and ask whether each is intentional. Pure read; no live BI connection.

Input Schema

NameRequiredDescriptionDefault
rawNoIf true, return the raw Blue Iris JSON instead of the shaped view.
hookNoWhich hook(s) to audit: 'on_trigger', 'on_reset', or 'both' (default).
camerasNoOptional list of camera short names to audit. Defaults to every camera with a .reg export.
min_cohortNoMinimum cohort size before outliers are computed. Cohorts smaller than this are listed under 'unbucketed' for visibility but not analyzed. Default 3.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.3

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond readOnlyHint=true: it explains cohort bucketing by (type, description, key), how path tokens are templated to '<CAM>' to avoid false positives, that no-majority fields are surfaced with no_majority=true, and that 'enabled' is split into disabled_outliers. It also warns that outliers may be intentional customizations, which prevents the agent from misreporting results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but well front-loaded: the one-line bold summary precedes the mechanics, then the caveat. Some redundancy in the 'Outliers are NOT necessarily bugs' emphasis and the repeated presentation guidance, but every section carries information.

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?

With no output schema, the description carries the full burden and does so by naming the return surfaces ('outliers', 'disabled_outliers', 'unbucketed', no_majority entries, templated '<CAM>' tokens). An agent knows what it will get back and how to interpret it before calling.

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

Parameters3/5

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

Schema description coverage is 100%, so all four parameters (raw, hook, cameras, min_cohort) are already documented in structured form. The prose mentions cohorts and modal values but adds no parameter-level detail such as hook semantics or min_cohort behavior beyond what the schema states.

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?

States a specific verb and resource: it walks every camera's .reg export and reports action-row cohort outliers. This is clearly distinct from sibling readers like bi_get_reg or bi_get_actionset, which just fetch raw/persisted values rather than comparing across cameras.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear operational context ('for user review', 'Pure read') and explicit instructions on how to present findings to the user ('values worth confirming', ask whether intentional). It does not name a sibling alternative or state exclusion conditions, which keeps it below a 5.

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

Deploy Server

Other Tools