Skip to main content
Glama
whoamiTM

bi-mcp

by whoamiTM
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

bi_list_log

Read-only

Retrieve and filter Blue Iris system log entries by time, camera, level, message, or regex to inspect profile changes, disk operations, logins, errors, and aggregate activity counts.

Instructions

Recent Blue Iris system log entries with optional filters.

Pick the right tool: for reconstructing 'what fired when' on a camera, start with bi_list_alerts — per-alert timestamps with no dedup. This log is best for system events (profile changes, disk ops, logins, errors) and aggregate activity counts.

Filters: since — UTC epoch sec, ISO-8601, or '-15m'/'-2h'/'-1d' (server-side via aftertime) camera — exact match on entry.obj (clone cameras log under their own short names) obj — exact match on entry.obj (escape hatch: 'App', 'MQTT', 'DB', 'AI_Input', drive letters, usernames) levels — list of accepted level ints; empirical: 0=info, 1=warn, 2=error, 3=trigger/alert aggregate (deduped — use bi_list_alerts for per-event), 4=status change, 10=user match — case-insensitive substring on entry.msg regex — Python regex on entry.msg (IGNORECASE); xor with match limit — applied AFTER filtering (default 100)

Returns {entries, scanned, matched, warning?}. raw=true bypasses the envelope and shaper. Admin required.

BI aggregates repeated messages: count is cumulative since BI startup (or last log clear), and date is when BI last summed the entry, not necessarily the most recent occurrence. To tell whether a message is actively firing now, re-query with a tight since=-5m window.

Input Schema

NameRequiredDescriptionDefault
objNoExact match on entry.obj. Use for non-camera subsystems: 'App', 'MQTT', 'DB', 'AI_Input', 'Alerts', 'Log', drive letters ('A:', 'D:'), or usernames.
rawNoIf true, return the raw Blue Iris JSON instead of the shaped view.
limitNoMax entries (default 100). An explicit limit also caps raw=true output.
matchNoCase-insensitive substring match on entry.msg.
regexNoPython regex on entry.msg (IGNORECASE). XOR with match.
sinceNoEarliest entry to return. Int (UTC sec), ISO-8601, or relative shorthand like '-15m', '-2h', '-1d'.
cameraNoExact match on entry.obj. Clone cameras (e.g. SecCam_11AI) have their own short names and log separately.
levelsNoKeep entries whose level is in this list. Empirical: 0=info, 1=warn, 2=error, 3=trigger/alert aggregate (deduped — use bi_list_alerts for per-event), 4=status, 10=user.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.4
    • changedInput schema / properties / limit / description
      Previous value: -"Max entries (default 100)."New value: +"Max entries (default 100). An explicit limit also caps raw=true output."
  2. First observedv0.3.3

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the `readOnlyHint` annotation, the description adds important operational behavior: admin requirement, server-side `since` handling, post-filter `limit`, envelope return shape, `raw=true` bypass, and Blue Iris log aggregation semantics where `count` is cumulative and `date` is when BI last summed the entry.

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?

The description is well structured and front-loads the most important routing guidance, but it repeats several parameter descriptions that are already fully covered by the schema. The aggregation caveat is valuable but makes the definition longer than strictly necessary.

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?

There is no output schema, but the description explains the return envelope, optional warning field, raw-response behavior, and the key aggregation caveat needed to interpret log results correctly. It is complete for an agent to invoke and interpret this tool.

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?

Although schema coverage is already high, the description adds meaningful semantics that are not obvious from the schema alone: empirical level mappings such as 3 being deduped trigger/alert aggregate, the XOR relationship between `match` and `regex`, `limit` applying after filtering, and clone cameras logging under their own short names.

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 states a specific verb and resource ('list' + 'log entries') and clearly differentiates this tool from the sibling `bi_list_alerts`, explaining that this log is for system events and aggregate activity counts while alerts are better for per-event camera activity.

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?

It gives explicit when-to-use guidance against a named alternative: start with `bi_list_alerts` for reconstructing what fired when on a camera. It also explains when this log is preferable, namely for system events and aggregate activity counts, and calls out admin-required access.

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