Skip to main content
Glama
whoamiTM

bi-mcp

by whoamiTM
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

bi_list_clips

Read-only

Lists recorded camera clips with paths, durations, resolution, flags, and memos; filter by camera, date range, view, memo search, or daily tiles.

Instructions

Recent recorded clips for a camera: path, duration, resolution, flags, memo. Complementary to bi_list_alerts (clips include continuous recordings; alerts are AI/motion events). Requires 'camera' short name (or 'Index' for all). Optional 'view' (filter; see schema for full enum), 'startdate'/'enddate' accept unix epoch int, ISO-8601, or relative shorthand ('-2h', '-1d'). 'search' (memo substring, server-side), 'tiles' (true=one entry per day, useful for calendar views). 'limit' default 50. Crossover note: alert-side view values (e.g. 'alerts', 'people', 'zonea') will return alert items in this response — they have an 'msec' field meaning alert length (not clip length) and lack the 'zones' field. UI3 v91 fixed a bug where this was mishandled.

Input Schema

NameRequiredDescriptionDefault
rawNoIf true, return the raw Blue Iris JSON instead of the shaped view.
viewNoDatabase view filter. Per BI manual § *cliplist*: 'all', 'new', 'stored', 'alerts', 'aux1'..'aux5', 'flagged', 'export', 'archive', 'confirmed', 'canceled'. Per UI3 source (extra alert-side values that work here, returning alert items): 'people', 'vehicles', 'zonea'..'zoneh', 'dio', 'onvif', 'audio', 'external', 'cancelled' (British).
limitNoMax clips returned (default 50). An explicit limit also caps raw=true output.
tilesNoIf true, return one entry per day instead of one per clip.
cameraYesCamera short name (required). Use 'Index' for all cameras.
searchNoMemo substring filter (server-side).
enddateNoLatest clip. Int (UTC sec), ISO-8601, or relative shorthand like '-2h', '-1d'.
startdateNoEarliest clip. Int (UTC sec), ISO-8601, or relative shorthand like '-2h', '-1d'.

Schema Changelog

Changes observed during successful MCP inspections.

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

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses server-side search behavior, limit default, day-tile aggregation, the fact that some view values return alert items with an 'msec' field and no 'zones', and a relevant version-specific bug fix. This is substantial behavioral context that annotations alone do not provide.

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 purpose and sibling comparison are front-loaded, followed by parameter notes and the crossover warning. The description is dense and somewhat run-on, but nearly every clause carries useful information for correct invocation; only the final UI3 bug note is marginal.

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?

For an 8-parameter read tool with no output schema and only a readOnlyHint annotation, the description supplies returned fields, default limit behavior, date input formats, tile semantics, and a critical warning about alert-side view values. An agent has enough information to call it correctly and interpret the response shape.

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

Parameters4/5

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

Schema description coverage is 100%, so the schema already documents every parameter. The description still adds meaning by explaining the practical purpose of 'tiles' for calendar views and by warning that certain 'view' values produce alert-shaped results with different fields. It repeats some schema details (date formats, search server-side, limit default) but the crossover caveat is genuinely additive.

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 recorded clips for a camera') and even enumerates the returned fields (path, duration, resolution, flags, memo). It explicitly distinguishes itself from the sibling bi_list_alerts by explaining that clips include continuous recordings while alerts are AI/motion events.

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 by positioning the tool as complementary to bi_list_alerts and clarifying the difference between continuous recordings and alert events. It also flags the crossover case where alert-side view values are passed to this tool, which is exactly the kind of alternative/edge guidance an agent needs.

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