Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@blueiris-mcp Show me a live snapshot from the front door camera"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for Blue Iris, the Windows NVR/camera-management software. Lets an LLM check camera health, pull live or historical snapshots, search the clip/alert archive, and drive PTZ cameras — all through Blue Iris's existing JSON API, no extra software on the Blue Iris box required.
Blue Iris's JSON API is undocumented enough that its session-handshake auth scheme (a custom two-step MD5 challenge, not a bearer token or HTTP digest) has to be reverse-engineered by reading network traffic. This package does that once so you don't have to.
Blue Iris already has a web UI and a JSON API, but neither is something an LLM agent can use directly. This wraps the API as MCP tools so an agent can answer questions like:
"Is the front door camera actually seeing anything right now, or is it stuck on the no-signal placeholder?"
"Show me what the driveway camera saw at 6pm yesterday."
"Who showed up at the front door today?" (Blue Iris's own AI recognition results are in the alert log's memo field, e.g. "John:74%")
"Pan the workshop camera left for a second and grab a frame."
Related MCP server: Axis MCP
Tool | Description |
| Configured cameras with live health: |
| Live or historical JPEG frame ( |
| Recorded segments for a camera, newest first, across Blue Iris's full retention window for that camera. |
| Motion/AI alerts for a camera, newest first, including Blue Iris's own recognition |
| Directional nudge, home, zoom in/out, stop, or jump to a saved preset. |
Requires a Blue Iris account with JSON API access (the same username/password as the web UI login).
pip install blueiris-mcp
# or: uvx blueiris-mcpConfigure via environment variables:
Variable | Required | Default |
| no |
|
| yes | — |
| yes | — |
~/.claude.json or claude_desktop_config.json){
"mcpServers": {
"blueiris": {
"command": "uvx",
"args": ["blueiris-mcp"],
"env": {
"BI_URL": "http://192.168.1.50:81",
"BI_USER": "your-username",
"BI_PASSWORD": "your-password"
}
}
}
}~/.hermes/config.yaml)Hermes' mcp_servers config supports the same stdio transport:
mcp_servers:
blueiris:
command: uvx
args: ["blueiris-mcp"]
env:
BI_URL: "http://192.168.1.50:81"
BI_USER: "your-username"
BI_PASSWORD: "your-password"Auth: POST /json {"cmd":"login"} returns a session token. Then POST /json {"cmd":"login","session":<id>,"response":<hash>} where hash = md5(f"{user}:{session}:{password}") — a single MD5 pass, no realm string. This client re-authenticates on every call rather than caching a session, since call volume through an MCP tool is inherently low.
list_clips/list_alerts (Blue Iris's cliplist/alertlist commands) have no date-range parameters — they return everything currently retained on disk for that camera. Retention is whatever Blue Iris is configured to keep (commonly a few days to a couple of weeks, storage-dependent).
If your setup has another process also driving a camera's PTZ (e.g. an automated monitoring script), avoid sending PTZ commands to that camera at the same time from here — Blue Iris does not arbitrate between simultaneous PTZ sources, and the result is erratic movement.
uv venv && uv pip install -e ".[dev]"
uv run pytestTests are fully mocked (via respx) — no live Blue Iris instance needed.
MIT
Fetch a JPEG frame from a camera.
Omit pos_ms for the current live frame. Pass pos_ms (Unix epoch
milliseconds) to pull a historical frame instead -- use list_clips
or list_alerts to find a timestamp of interest first (their
date field is epoch seconds; multiply by 1000).
| Name | Required | Description | Default |
|---|---|---|---|
| camera | Yes | ||
| pos_ms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It clearly explains that the tool returns a JPEG frame, distinguishes live vs historical behavior based on pos_ms, and warns about the epoch unit mismatch. It does not mention error cases or authentication, but the key behavioral trait (what happens with and without pos_ms) is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs, front-loaded with the core purpose. Every sentence adds value: the first sentences states what it does, the second explains the optional parameter's behavior and how to source timestamps. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no output schema, and no annotations, the description provides a complete contract: what it returns (JPEG frame), how to get live vs historical frames, and how to find suitable timestamps via sibling tools. It also warns about the unit mismatch. There is no missing information critical to invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain all parameters, and it does. pos_ms is thoroughly explained: omit for live, pass Unix epoch milliseconds for historical, and specifically notes the multiplication from seconds. camera is somewhat self-explanatory but the description could benefit from referencing list_cameras; however, the primary parameter is handled with exceptional clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource phrase: "Fetch a JPEG frame from a camera." It clearly distinguishes this from sibling tools (list_cameras, list_clips, list_alerts, ptz) by focusing on fetching a frame, not listing or controlling. The live vs historical distinction further clarifies the tool's unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states usage for both live and historical frames: "Omit pos_ms for the current live frame" and "Pass pos_ms ... to pull a historical frame instead." It also directs the user to list_clips or list_alerts to find timestamps, and provides a critical unit conversion tip (epoch seconds to milliseconds). This gives clear when-to-use and how-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List motion/AI alerts for a camera, newest first.
This is the fast path for "who/what triggered this camera and when" --
Blue Iris's own memo field carries AI recognition results when
available (e.g. "Rahi:74%" for a matched face), so this often
answers identity questions directly without a separate face-recognition
lookup. date is epoch seconds, same convention as list_clips.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| camera | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses that results are ordered newest-first, that 'date' is in epoch seconds and follows the same convention as list_clips, and that the memo field carries AI recognition results—these are useful behavioral details beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: the first states the core purpose, the second adds valuable context about the memo field, and the third clarifies the date format. Each sentence earns its place, though the second is a bit verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with an output schema present, the description covers the essential aspects: purpose, ordering, date semantics, and memo field. It does not explicitly explain the 'limit' parameter, but the schema default and output schema partially mitigate that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate, but it does not. It only implies the 'camera' parameter through the phrase 'for a camera,' and the 'limit' parameter is not mentioned at all, leaving the agent to guess its meaning despite the default of 20.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List motion/AI alerts for a camera, newest first,' which clearly states the verb (List), the resource (motion/AI alerts), and a key behavior (newest first). It also positions the tool as the 'fast path' for identity questions, effectively distinguishing it from siblings like list_clips.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says this is the 'fast path for who/what triggered this camera and when,' providing clear when-to-use context. It also notes that it can answer identity questions 'without a separate face-recognition lookup,' suggesting an alternative approach, though it does not explicitly contrast with sibling list_clips.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured Blue Iris cameras with live health status.
Each entry includes is_no_signal (true when the feed is down and
Blue Iris is showing its grey "no video" placeholder -- this is
different from is_online, which only means the camera isn't
disabled), fps, error, and ptz_capable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains important nuances, such as the difference between is_no_signal and is_online, which prevents misinterpretation of camera health. It also specifies that is_no_signal indicates a specific grey placeholder image, adding useful behavioral context beyond a simple field list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences with no filler. The first sentence states the purpose, and the second provides detailed field semantics. Every sentence adds value, and the structure is clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters) and the presence of an output schema, the description covers the essential meaning of key fields. It explains the critical distinction between is_online and is_no_signal, which is likely not obvious from schema alone. It could mention whether the list is sorted or if any filtering options exist, but these are not necessary for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts no parameters, and the input schema is empty, so there are no parameter semantics to describe. The baseline for zero-parameter tools is 4, and the description does not need to compensate for undocumented parameters. It instead focuses on output meaning, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific action: 'List configured Blue Iris cameras with live health status.' This uses a concrete verb and resource, and the additional field definitions further clarify what the tool returns. It is distinct from sibling tools like get_snapshot and list_alerts, so there is no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to enumerate cameras and their health, but it does not explicitly state when to use this tool over siblings or when not to use it. For example, it doesn't mention that get_snapshot is for images or list_alerts for events, leaving usage context implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recorded video segments for a camera, newest first.
Covers Blue Iris's full retention window for that camera (typically a
few days, depending on configured storage limits -- there's no
separate date-range filter on this endpoint, it returns everything
currently on disk). Each entry's date (epoch seconds) and msec
(segment duration) can be used with get_snapshot to pull a frame
from within that segment.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| camera | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It reveals ordering ('newest first'), scope ('full retention window'), limitations ('no separate date-range filter'), and how data fields (date, msec) relate to get_snapshot. This goes well beyond a basic read-only hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight paragraphs: the first sentence states purpose clearly, and the second adds valuable context about retention and usage. Every sentence contributes new information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is robust for behavior and integration, covering retention, ordering, and linkage to get_snapshot. The output schema covers return values, so no need to explain those. However, the missing parameter semantics for limit and the implicit handling of camera make it slightly incomplete overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meanings. It only implicitly references the camera parameter via 'for a camera' and completely omits the limit parameter. This is a significant gap given the description is the sole source of semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb and resource: 'List recorded video segments for a camera, newest first.' This distinguishes it from sibling tools like list_cameras and list_alerts by focusing on video segments and their ordering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: it covers the full retention window and lacks a date-range filter, implying it's for retrieving all available segments. It also mentions integration with get_snapshot, but does not explicitly exclude alternative tools or state when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pan/tilt/zoom a PTZ-capable camera, or jump to a saved preset.
action is one of: left, right, up, down (momentary move, held for
duration_s seconds, capped at 3.0), home, zoom_in, zoom_out, stop,
or goto_preset (requires preset, 0-99).
Only cameras with PTZ hardware respond -- check list_cameras'
ptz_capable field first. If this Blue Iris instance has an
automated pipeline that also drives a camera's PTZ (e.g. a monitoring
script using a dedicated preset slot), avoid sending competing PTZ
commands to that camera at the same time -- Blue Iris does not
arbitrate between simultaneous PTZ sources and the result is erratic
movement.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| camera | Yes | ||
| preset | No | ||
| duration_s | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers rich behavioral disclosure. It specifies action semantics (momentary move, held for duration_s, capped at 3.0), requires preset for goto_preset (0-99), and explicitly warns about erratic movement caused by simultaneous PTZ sources. This goes far beyond a simple 'moves a camera' and covers side effects and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense: a clear purpose sentence, a structured list of actions with constraints, and a final caution paragraph. Every sentence adds operational value or a critical caveat, and code-formatting for parameters improves scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description covers all necessary operational knowledge: valid actions, parameter constraints, prerequisite hardware checks, and environmental caveats about competing PTZ pipelines. An agent can safely decide when to invoke and how to construct arguments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description must compensate. It does thoroughly: 'action' values are enumerated with meanings, 'duration_s' is explained as seconds with a 3.0 cap, 'preset' is described as required for goto_preset with a 0-99 range, and 'camera' is implied to be a PTZ-capable camera. This fully compensates for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence clearly states the tool's function: 'Pan/tilt/zoom a PTZ-capable camera, or jump to a saved preset.' It names the resource (PTZ-capable camera) and specific verb actions, and the subsequent list of actions (left, right, up, down, home, zoom, stop, goto_preset) distinguishes it from sibling read-only tools like list_cameras and get_snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs users to verify PTZ capability via list_cameras' ptz_capable field before using, which is a clear when-to-use precondition. It also warns against sending competing PTZ commands when an automated pipeline is active, effectively stating when not to use the tool. This is exceptional guidance beyond a generic 'use to control camera.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: list_cameras for status, get_snapshot for frame retrieval, list_clips and list_alerts for historical data, and ptz for camera control. There is no overlap in functionality.
Most tools follow the verb_noun pattern with snake_case (list_cameras, get_snapshot, list_clips, list_alerts). The exception is 'ptz', which is a concise, recognizable command name but breaks the verb_noun pattern slightly.
The server exposes 5 tools, which is well-scoped for its purpose of interacting with a Blue Iris server. Each tool addresses a distinct need without excessive or inadequate coverage.
The tool set covers the core surveillance workflows: camera listing, snapshot retrieval, clip listing, alert listing, and PTZ control. Minor gaps exist such as lack of timeline traversal or configuration changes, but the surface is solid for common use cases.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/smaniktahla/blueiris-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
