Blink Camera MCP Server

blink-camera-mcp

An MCP server for Amazon Blink cameras, including the pan/tilt mount that Blink's own API gives you no way to move.

Install it with uvx blink-camera-mcp. It is listed in the official MCP Registry as io.github.AbhijatSaxena/blink-camera-mcp.

Give any MCP host — Claude Desktop, an IDE agent, your own client — the ability to see where a camera is pointing, aim it, and look through it.

camera_status       where it points, travel limits, session state, stream URL
pan_tilt            aim at an absolute angle, wait until the hardware confirms
pan_tilt_nudge      turn relative to where it points now
pan_tilt_stop       stop the motors
pan_tilt_home       go to the saved home position
pan_tilt_set_home   save the current angle as home
pan_tilt_overview   360° sweep
snapshot            one still frame, returned as image content

Why this exists

Blink cameras are cloud devices. There is no local API, no ONVIF, no UVC — video exists only as a short-lived session brokered by Blink's cloud, capped at 300 seconds. Two consequences:

1. Anything that wants to use the camera has to hold that session open and refresh it.
2. The pan/tilt mount is not a device you can talk to. It has no endpoint of its own: it is driven inside the camera's media session, and its position comes back on the same socket. A client that reads only the video and skips every other message never sees any of that traffic, which is why the mount has looked uncontrollable for years.

This server owns the session (or reuses one), frames it correctly, routes the accessory messages, and exposes the whole thing as MCP tools with closed-loop semantics.

Install

pip install blink-camera-mcp          # or without installing: uvx blink-camera-mcp

The distribution is blink-camera-mcp; the command it installs is blink-mcp.

You need Python 3.10+, a Blink account, and ffmpeg on PATH for snapshot (set BLINK_FFMPEG if it lives somewhere unusual).

Configure

Credentials come from the environment, and only the first run needs them:

export BLINK_USERNAME="you@example.com"
export BLINK_PASSWORD="..."
export BLINK_CAMERA_NAME="Front Door"      # optional; defaults to the only camera

The token is cached (token material only — a password is never written to disk), so later runs need no credentials. Cache location defaults to ~/.blink-mcp/state.json; override with BLINK_STATE_FILE.

If Blink asks for a 2FA code, the server will not prompt you and will not take the code from anywhere but a file:

export BLINK_2FA_FILE=/path/to/code.txt

Write the newest code into that file; it is read once and deleted. This keeps a live credential out of chat logs, shell history and argument lists.

Add it to your MCP host

blink-mcp --print-config

{
  "mcpServers": {
    "blink": {
      "command": "uvx",
      "args": ["blink-camera-mcp", "--stream-port", "9000"]
    }
  }
}

Hosts that manage their own Python (Claude Desktop, VS Code, LM Studio, …) run uvx as above. If you installed it into a virtualenv instead, set command to that interpreter and args to ["-m", "blink_mcp", …].

Claude Desktop — one-click

Download blink-camera-mcp-0.1.1.mcpb from the releases page and open it. Claude Desktop prompts for your Blink email and password (kept in the OS keychain), and asks for the 2FA code file only if your account uses verification. The bundle carries no server code of its own — it depends on this package from PyPI, so it can never drift from the released version.

LM Studio, VS Code, Cursor, Cline and friends

They all read the same JSON as above. Paste it into the host's MCP config — LM Studio: mcp.json; VS Code: .vscode/mcp.json; Cursor: .cursor/mcp.json. Cline installs it from this README.

Hermes

Hermes' curated catalog is for remote, OAuth-authenticated servers, and this one has to run on a machine that can reach your camera — so add it as an ordinary stdio server in ~/.hermes/config.yaml:

mcp_servers:
  blink:
    command: "uvx"
    args: ["blink-camera-mcp"]
    env:
      BLINK_USERNAME: "you@example.com"
      BLINK_PASSWORD: "…"

Restart the session (or /reload-mcp) and the eight tools show up like any other.

Two ways to run it

Standalone (default) — the server owns the camera's live session and publishes the video to a local TCP port (tcp://127.0.0.1:<port>, or a fixed one with --stream-port 9000). Point OBS at it as a Media Source if you want the camera as a webcam as well.

Against a bridge — if something else already holds the session:

blink-mcp --control-url http://127.0.0.1:9100 --stream-url tcp://127.0.0.1:9000

This matters because Blink allows one live session per camera: a viewer and a controller have to share it or take turns. Running two things that each insist on their own session means one of them loses.

What "closed-loop" means here

The mount reports its angle while it is moving. So pan_tilt does not sleep and hope: it sends the command and returns only when the hardware reports that its motors stopped at the requested angle — typically well under a second.

pan_tilt_nudge(+4)  -> settled=True moved=True elapsed=0.67s -> pan=117 tilt=-75
pan_tilt_nudge(-4)  -> settled=True moved=True               -> pan=113 tilt=-75

Two deliberate behaviours, because a confident wrong answer is worse than a failure:

• if the mount never confirms, the tool fails rather than returning the last angle it happened to know (a stale position dressed up as success would have an agent announce a move that never happened);
• a command to the angle the camera already holds is a no-op reported as moved: false — success, not failure.

Privacy and safety

• snapshot decodes a frame of whatever the camera is pointed at. The tool description says so, and tells the agent to use it only when the user asks. Nothing here captures anything on its own.
• The server talks to Blink directly, and the token cache holds no password.
• Any bridge control plane is loopback-only by design: it moves a physical camera.

How it was built

The accessory channel is undocumented. It was recovered from the official Android app — dex bytecode and the native library's symbol table — and then verified against hardware:

frame        [flag:1][id:4 big-endian][length:4 big-endian][payload]
send         flag 0x14 INLINE_COMMAND, id = commandId
             move=3 [0,0,0,0,<pan>,<tilt>,0]   stop=4  home=5  set_home=6  overview=7
receive      flag 0x15 ACCESSORY_MESSAGE, id = message id
             POSITION=2 / HOME_POSITION=3 [<counter>,<pan>,<tilt>,<status>]
             ROSIE_LIMITS=4   PAN_OVERVIEW_COMPLETE=5   lights/siren = 0/1/6/7

status is 0x00 idle and 0x10 moving. Angles are single signed bytes.

The same protocol knowledge is being contributed upstream to blinkpy so every Blink integration benefits, not just this server. blink_mcp/immi.py is byte-identical to the module submitted there, and switches to the upstream copy automatically once it ships.

Standing on the shoulders of blinkpy, which implements the Blink cloud API and the IMMI transport.

Limitations

• Verified on a Blink Mini with the pan/tilt mount. Other camera families use a different live transport (WebRTC with JSON-RPC commands rather than this binary channel) and are not supported yet.
• One live session per camera, as above.
• Blink caps a session at 300 s; the server rotates it around 270 s and consumers never notice.
• snapshot needs ffmpeg; it decodes one frame from the stream rather than opening a second session.

Tests

pytest                    # 68 offline tests: protocol bytes, closed-loop logic, tool layer,
                          # a real stdio handshake, and a stub control plane

The suite is offline and needs no camera. For real hardware:

python tests/live_smoke.py --state-file ~/.blink-mcp/state.json

which logs in, moves the camera out and back, and captures a frame.

License

MIT