bi-mcp: a Blue Iris MCP server for Claude Code / LLMs (read + control via the JSON API)

[George M]

Since Claude Desktop has worked well with my Home Assistant mcp, i decided to give this a try. I used the github connection for the install and ran into a problem with the SDK mismatch. Claude straighten it out but gave the warning that any updates i would run into the same problem. are there any plans to use the later SDK? Here is what was reported.

What was wrong
bi-mcp wasn't actually "still connecting" — it was crash-looping on startup, so Claude Code never got a tool list and it never showed up under Developer.

Root cause: bi-mcp declares its dependency as mcp>=1.2.0 with no upper bound. When the binary was rebuilt this morning (05:47), it pulled the latest SDK, mcp 2.1.1, which removed the low-level @server.list_tools() / @server.call_tool() decorator API the code is written against. The server died instantly with:

What I did
Pinned the SDK back to 1.x inside bi-mcp's pipx venv (using uv):

Then verified directly: the server now completes the initialize handshake and returns its full Blue Iris tool list (bi_get_actionset, bi_get_alert_image, …), clean exit, no stderr.

What you need to do
Restart Claude Code so it relaunches the MCP process — the current session already has the crashed instance cached. After restart, bi-mcp should appear under Developer with its tools.

Heads-up — it'll break again on the next rebuild
The venv is fixed, but the unbounded mcp>=1.2.0 in the source repo (git+GitHub - whoamiTM/bi-mcp: MCP server for Blue Iris NVR — exposes the Blue Iris JSON API and .reg config to LLM agents.) means any future pipx reinstall/rebuild will re-pull mcp 2.x and reintroduce this. Durable fix is to pin mcp>=1.2.0,<2 in that repo's pyproject.toml. Want me to note the exact change for when you next touch that repo?

Let me save this so it's on record for next time:


Recalled a memory, saved 2 memories
Saved to memory so this is a fast diagnosis next time.

Summary: bi-mcp was crashing on launch because a rebuild pulled the incompatible mcp 2.1.1 SDK. I pinned it back to mcp 1.29.1 in its venv and verified the server now handshakes and lists tools correctly. Restart Claude Code and it'll show up under Developer.

 

[whoami ™]

TLDR: I measured it and MCP won by a lot locally.

I went in assuming MCP was pointless overhead for something like Blue Iris. Stateless HTTP API on my own LAN, I wrote the server myself, I'm the only client, so why pay for a subprocess and a pile of tool schemas when a skill with a CLI would be leaner. Seemed obvious. So I benchmarked it against my live install instead of arguing about it.

Setup is Blue Iris 5.9.9.71 on the LAN, my own bi-mcp server (25 tools), 7 samples per case, medians. Four paths, bare requests straight to the BI JSON API as the floor, the package called in process, the real MCP stdio round trip, and a CLI subprocess which is what a skill would actually be shelling out to.

Bare HTTP was 34.4ms for status, 37.9ms camlist, 75.4ms alertlist. Through MCP it was 42.5 / 49.3 / 81.6. So the entire MCP tax is 8 to 12ms per call. Server startup is a one time 408ms and tools/list is 2.3ms, both of which you pay once and never again.

The CLI subprocess path, the "skill" path, was 276.5 / 273.7 / 346.0. Roughly 6x slower than MCP. And it isn't my code being slow, Python itself starts in 8ms, but import bi_mcp.tools costs 114ms and you eat that on every single invocation. That's the whole thing right there. A long running MCP server pays the import and the login handshake once, a shell out pays both every time you call it.

The token argument didn't hold up either. Full schema for all 25 tools is 35,236 bytes which is around 8,800 tokens if it's all sitting in context. But my client is loading them deferred now, names only, about 107 tokens. So the standing cost is a bit over 1% of what I assumed I was paying.

What I'd still say for skills is that they're a better home for knowledge than for plumbing. My AGENTS.md has a couple years of accumulated gotchas in it, stuff like the update cmd silently clearing the flagged bit, tracks returning access denied on this build, camconfig setmotion being read only despite what the manual says. Tool descriptions can't really carry that and the file only gets read if the model decides to read it. A skill loads the knowledge and the how-to-call-it together, which is a real win. Just not a latency one.

Where I do still think the complaint lands is Home Assistant's Assist pipeline, which is a different animal entirely. That's conversation agent indirection plus intent matching plus serializing state on every turn, and the overhead there is real and large. Custom prompt with a plain function call is the right shape for that and I don't think you're cutting corners by doing it.

Numbers are from my hardware and my network so your mileage will vary, especially if your NVR isn't on the same LAN segment. But the import cost per subprocess spawn is going to bite anyone doing the shell out approach regardless.

One more thing worth saying, because my whole post was written from a spot most people aren't standing in.

I wrote the server. I know the API, I know which cmds are broken on my build, I know the payload shapes, and I've got a couple years of notes on the gotchas. When I say a skill carries knowledge better than tool schemas do, that's easy for me to say, because I already have the knowledge to put in it. Somebody coming at Blue Iris or Home Assistant fresh doesn't. They'd have to go read the JSON API docs, figure out what's actually implemented versus what the manual claims, work out auth, find out the hard way that some cmd returns access denied for no documented reason, and then get their agent to wrap all that into a skill that doesn't hallucinate menu paths. That's not a weekend, that's a project, and it's a project you have to finish before you get any value at all.

An MCP server is somebody else handing you all of that already done. You point your client at it and you're asking real questions in about five minutes. The tool schemas are the discovery layer, and that's the actual point of MCP that I glossed over. It's not there for the person who wrote the server, it's there for the person who didn't. Your agent reads the schemas and knows what's callable without anyone writing a skill or a doc, and that's genuinely worth something.

There's also the "get your agent to build a skill" part, which sounds easier than it is. The agent will happily write you a skill for an API it half remembers, and you won't find out which half was wrong until it confidently tells you to set something that doesn't exist. Verifying that against a live system is the expensive part, and it's the part that gets skipped.

So my numbers say MCP costs about 10ms a call locally and a skill shelling out to a CLI costs 230ms, but that's a tuning argument for somebody who already has both options built. If you don't, MCP is just the thing that works today, and I'd install one rather than spend a week building the leaner version of something I don't understand yet. Build the skill later, once you actually know what belongs in it. That's roughly the order I did it in anyway, I just didn't notice until I ran the benchmark.