Submit
AbhijatSaxena

blink-camera-mcp

Community AbhijatSaxena
Updated

MCP server for Amazon Blink cameras: see, aim (pan/tilt) and capture, over the undocumented accessory protocol

blink-camera-mcp

cipypipython

An MCP server for Amazon Blink cameras, including thepan/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 asio.github.AbhijatSaxena/blink-camera-mcp.

Give any MCP host — Claude Desktop, an IDE agent, your own client — the ability to see wherea 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 onlyas 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 isdriven 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 thattraffic, which is why the mount has looked uncontrollable for years.

This server owns the session (or reuses one), frames it correctly, routes the accessorymessages, 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="[email protected]"
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 laterruns need no credentials. Cache location defaults to ~/.blink-mcp/state.json; override withBLINK_STATE_FILE.

If Blink asks for a 2FA code, the server will not prompt you and will not take the codefrom 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 livecredential 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 thereleases page and open it.Claude Desktop prompts for your Blink email and password (kept in the OS keychain), and asks forthe 2FA code file only if your account uses verification. The bundle carries no server code of itsown — 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 amachine 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: "[email protected]"
      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 videoto a local TCP port (tcp://127.0.0.1:<port>, or a fixed one with --stream-port 9000). PointOBS 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 controllerhave to share it or take turns. Running two things that each insist on their own session meansone 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: itsends the command and returns only when the hardware reports that its motors stopped at therequested 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 ithappened to know (a stale position dressed up as success would have an agent announce a movethat 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 saysso, and tells the agent to use it only when the user asks. Nothing here captures anything onits 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 — dexbytecode 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 toblinkpy so every Blink integration benefits, not justthis server. blink_mcp/immi.py is byte-identical to the module submitted there, and switchesto the upstream copy automatically once it ships.

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

Limitations

  • Verified on a Blink Mini with the pan/tilt mount. Other camera families use a differentlive transport (WebRTC with JSON-RPC commands rather than this binary channel) and are notsupported 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 secondsession.

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

MCP Server · Populars

MCP Server · New