Skip to main content
Glama
whoamiTM

bi-mcp

by whoamiTM
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

bi_list_log

Read-only

Query Blue Iris system logs with filters for time, camera, level, or text to diagnose errors and track system events.

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

TableJSON 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).
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. First observedv0.3.3

TDQS

A5/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description adds substantial behavioral context: admin requirement, return envelope shape ({entries, scanned, matched, warning?}), raw mode behavior, and the critical aggregation caveat that count is cumulative and date reflects last summation rather than most recent occurrence. It also warns that level 3 entries are deduped and points to bi_list_alerts for per-event data.

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

Conciseness5/5

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

The description is long but every section earns its place: routing, filter semantics, return shape, and aggregation caveat. It is front-loaded with the most important sibling distinction and remains scannable with clear labels. No filler or repetition of schema content.

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 8 parameters, no output schema, and only a readOnly annotation, the description nevertheless covers return structure, permission requirements, filter behavior, dedup semantics, and how to detect actively firing messages. There are no critical gaps for an agent to call this safely and correctly.

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?

Even though schema coverage is 100%, the description adds meaning far beyond the schema: 'limit is applied AFTER filtering', 'regex is xor with match', 'since supports relative shorthand server-side via aftertime', clone cameras log under short names, and the empirical level meanings. This materially improves an agent's ability to call the tool correctly.

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: 'Recent Blue Iris system log entries with optional filters.' It clearly distinguishes itself from bi_list_alerts by explicitly positioning this tool for system events and aggregate counts versus per-alert timestamps. An agent can immediately tell this apart from its siblings.

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?

The 'Pick the right tool' section explicitly tells the agent when to use bi_list_alerts instead, and what this log is best for: system events and aggregate activity counts. It gives concrete routing guidance without leaving the decision to inference.

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