Posting this in the AI subforum on purpose, since the audience here is more likely to actually have opinions on agent tooling than the general Blue Iris room.
Curious how many folks here are using Claude Code (or any LLM agent) with MCP servers. I've been building one over the last few weeks and it's changing how I troubleshoot BI completely. Wanted to see if there's interest in the project going public, and try to gauge if anyone might want to contribute. The reason I'm asking before pushing it out is that standing up a real OSS project (CI on GitHub Actions, a release pipeline, contributor docs, a test matrix across BI versions, issue triage) is a meaningful chunk of work on top of the code itself. If it's just me using it, none of that overhead is worth doing. If there are a few others who'd actually use it, and ideally a couple who'd contribute, it pays for itself.
What it is
bi-mcp is a stdio MCP server that wraps Blue Iris's HTTP/JSON API, the undocumented camconfig cmd, and a parser for BI's .reg camera exports (for the stuff the API doesn't expose: trigger zone polygons, per-class AI thresholds, alert action chains, ONVIF event handlers, etc.).
Built and tested against BI 5.9.9.71 (x64) on Windows 10. Currently 21 tools, 15 read-only by default, plus 6 mutating tools that only register when an env flag is set. It wraps 18 of the 23 documented JSON cmds. The remaining 5 are either niche or destructive enough that I haven't decided whether to expose them.
What you can do with it
A real session from today: I asked it to "find issues on my install." Over about 15 minutes of back-and-forth, here's what came out of it.
It noticed my PTZ camera had "AI: not responding" warnings in the log, pulled the CPAI-side config, cross-referenced to a fix I'd applied earlier that day, did the UTC to EDT timezone math to confirm the warnings had stopped after the fix, and flagged a verification window to re-check in the morning.
The bigger one was my busiest spotter. Road-facing cam with about 5900 alerts in the queue, and three PTZ-handoff action rows that hadn't fired in two days. It pulled the BI log filtered for "ONVIF Event:" on that camera and showed me the IVS tripwires WERE firing on the camera side, roughly 160 events in 48 hours, but BI wasn't translating any of them into PTZ preset calls. Then it walked the alert lifecycle and found every ONVIF event was landing as a "Retriggered: ONVIF,Motion_A" on top of an in-flight motion alert, never as a fresh trigger. From there it identified the "Run on retrigger: New zones/sources (exclusive)" dropdown as the culprit. The "exclusive" qualifier requires the source set to replace, not add, and since Motion_A stayed present from the original trigger, the rows never re-evaluated. One dropdown change, three months of broken PTZ handoffs explained.
It also surfaced cross-camera action-set inconsistencies via a .reg walker that buckets rows by type, description, and filter shape, then flags fields where one camera diverges from the cohort majority. Two were known intentional and already in its memory of my install. One was a real misconfig.
For mutations (PTZ presets, profile switches, manual record toggles, clip exports, alert memo updates) every write is verified after the fact. Read before, write, read after, report whether the change actually landed. It won't claim success on writes that BI silently dropped.
It's not infallible. Twice in that same session it misread a config field and I had to correct it. But the workflow of "explain what you see, here's what I think, push back if I'm wrong" turns into a real investigative pair-debugging loop, not a black box.
The other nice part is the agent builds up a memory of your install over time by writing markdown files. My camera roster, which spotters call which PTZ presets, which ONVIF source tokens have to be hand-typed because the BI UI leaves them blank, all of it gets remembered between sessions, so it doesn't re-ask the same questions every time.
What's left before I push it to GitHub
A couple of useful JSON cmds I haven't wrapped yet (camset for preset image management and grid layout, and the alert-counter reset path). The parser exception taxonomy could be tighter, so .reg parse failures report distinct error kinds instead of flattening to one. Install docs need to actually exist; the README currently assumes you already know what MCP is. And I haven't picked a publishing pipeline. Right now it's just a local Python package; I haven't decided between PyPI, a tagged GitHub release, or "clone and pip install -e ."
The question
Anyone else here doing this? If so, what are you using and what's working or not working for you? And if there's interest in this one going open source, I'd love contributors. There's plenty of room to wrap more of the API, add tests against a wider range of BI versions, and build out the agent-facing operating manual.
Curious how many folks here are using Claude Code (or any LLM agent) with MCP servers. I've been building one over the last few weeks and it's changing how I troubleshoot BI completely. Wanted to see if there's interest in the project going public, and try to gauge if anyone might want to contribute. The reason I'm asking before pushing it out is that standing up a real OSS project (CI on GitHub Actions, a release pipeline, contributor docs, a test matrix across BI versions, issue triage) is a meaningful chunk of work on top of the code itself. If it's just me using it, none of that overhead is worth doing. If there are a few others who'd actually use it, and ideally a couple who'd contribute, it pays for itself.
What it is
bi-mcp is a stdio MCP server that wraps Blue Iris's HTTP/JSON API, the undocumented camconfig cmd, and a parser for BI's .reg camera exports (for the stuff the API doesn't expose: trigger zone polygons, per-class AI thresholds, alert action chains, ONVIF event handlers, etc.).
Built and tested against BI 5.9.9.71 (x64) on Windows 10. Currently 21 tools, 15 read-only by default, plus 6 mutating tools that only register when an env flag is set. It wraps 18 of the 23 documented JSON cmds. The remaining 5 are either niche or destructive enough that I haven't decided whether to expose them.
What you can do with it
A real session from today: I asked it to "find issues on my install." Over about 15 minutes of back-and-forth, here's what came out of it.
It noticed my PTZ camera had "AI: not responding" warnings in the log, pulled the CPAI-side config, cross-referenced to a fix I'd applied earlier that day, did the UTC to EDT timezone math to confirm the warnings had stopped after the fix, and flagged a verification window to re-check in the morning.
The bigger one was my busiest spotter. Road-facing cam with about 5900 alerts in the queue, and three PTZ-handoff action rows that hadn't fired in two days. It pulled the BI log filtered for "ONVIF Event:" on that camera and showed me the IVS tripwires WERE firing on the camera side, roughly 160 events in 48 hours, but BI wasn't translating any of them into PTZ preset calls. Then it walked the alert lifecycle and found every ONVIF event was landing as a "Retriggered: ONVIF,Motion_A" on top of an in-flight motion alert, never as a fresh trigger. From there it identified the "Run on retrigger: New zones/sources (exclusive)" dropdown as the culprit. The "exclusive" qualifier requires the source set to replace, not add, and since Motion_A stayed present from the original trigger, the rows never re-evaluated. One dropdown change, three months of broken PTZ handoffs explained.
It also surfaced cross-camera action-set inconsistencies via a .reg walker that buckets rows by type, description, and filter shape, then flags fields where one camera diverges from the cohort majority. Two were known intentional and already in its memory of my install. One was a real misconfig.
For mutations (PTZ presets, profile switches, manual record toggles, clip exports, alert memo updates) every write is verified after the fact. Read before, write, read after, report whether the change actually landed. It won't claim success on writes that BI silently dropped.
It's not infallible. Twice in that same session it misread a config field and I had to correct it. But the workflow of "explain what you see, here's what I think, push back if I'm wrong" turns into a real investigative pair-debugging loop, not a black box.
The other nice part is the agent builds up a memory of your install over time by writing markdown files. My camera roster, which spotters call which PTZ presets, which ONVIF source tokens have to be hand-typed because the BI UI leaves them blank, all of it gets remembered between sessions, so it doesn't re-ask the same questions every time.
What's left before I push it to GitHub
A couple of useful JSON cmds I haven't wrapped yet (camset for preset image management and grid layout, and the alert-counter reset path). The parser exception taxonomy could be tighter, so .reg parse failures report distinct error kinds instead of flattening to one. Install docs need to actually exist; the README currently assumes you already know what MCP is. And I haven't picked a publishing pipeline. Right now it's just a local Python package; I haven't decided between PyPI, a tagged GitHub release, or "clone and pip install -e ."
The question
Anyone else here doing this? If so, what are you using and what's working or not working for you? And if there's interest in this one going open source, I'd love contributors. There's plenty of room to wrap more of the API, add tests against a wider range of BI versions, and build out the agent-facing operating manual.
