blink-camera-mcp

blink-camera-mcp is an MCP server for controlling Amazon Blink cameras, specifically the pan-tilt base that the official Blink API cannot move. It implements viewing, aiming (pan/tilt), and frame capture through an undisclosed accessory protocol, and can be integrated into any MCP host, such as Claude Desktop, IDE agents, or custom-built clients.

Purpose: Blink cameras are cloud devices with no local API, ONVIF, or UVC, and video exists only as short-lived cloud sessions (capped at 300 seconds). Any program using the camera must maintain the session and refresh it. The pan-tilt base has no independent endpoint; it is driven internally by the camera media session, and its position is also returned over the same socket. Clients that only read video and ignore other messages will never see this traffic, which is why the pan-tilt has appeared uncontrollable for years. This server is responsible for holding (or reusing) the session, correct encapsulation, routing accessory messages, and exposing closed-loop control semantics as MCP tools.

Main capabilities:

• View where the camera is pointing and the pan-tilt travel limits.
• Aim the camera by absolute or relative angle, and confirm the new position.
• Capture a snapshot, decoding one frame from the existing stream without opening an additional session.
• Closed-loop control: the pan-tilt reports angles as it moves, and after pan_tilt sends a command it returns only when the hardware reports that the motor has stopped at the target angle, usually well under one second.
• Two intentional behaviors: if the pan-tilt never confirms, the tool fails instead of returning the last known angle (avoiding an agent announcing a movement that did not happen); if the command points to the current angle, it is treated as a no-op and reports moved: false (success rather than failure).

Usage: Install: uvx blink-camera-mcp. The distribution name is blink-camera-mcp, and the installed command is blink-mcp. It has been registered in the official MCP Registry as io.github.AbhijatSaxena/blink-camera-mcp. Requires Python 3.10+, a Blink account, and ffmpeg for snapshot (if the ffmpeg path is unusual, set BLINK_FFMPEG). Credentials come from environment variables and are only needed on first run. Tokens are cached (token material only; the password is never written to disk), so subsequent runs do not require credentials. The cache location defaults to ~/.blink-mcp/state.json, can be overridden with BLINK_STATE_FILE. If Blink requires a 2FA verification code, the server will not prompt for it, nor will it obtain the code from anywhere else; it only reads it from the file: write the latest verification code to that file, and it is deleted after being read once. This avoids real-time credentials appearing in chat logs, shell history, or argument lists. Adding to an MCP host:

• Hosts that manage Python themselves (Claude Desktop, VS Code, LM Studio, etc.) can run uvx directly.
• If installed into a virtualenv, set command to that interpreter and args to ["-m", "blink_mcp", ...].
• Claude Desktop one-click install: download blink-camera-mcp-0.1.1.mcpb from the releases page and open it. Claude Desktop will prompt for the Blink email and password (stored in the operating system keychain), and will require a 2FA verification code file only if the account uses verification. The bundle does not include the server code and depends on this package on PyPI, so it will not drift from the release version.
• LM Studio, VS Code, Cursor, Cline, etc.: all read the same JSON, paste it into the host's MCP configuration (LM Studio: mcp.json; VS Code: .vscode/mcp.json; Cursor: .cursor/mcp.json; Cline is installed from the README).
• Hermes's curated directory is for remote OAuth-authenticated servers, while this server must run on a machine with access to the camera, so add it as a normal stdio server in ~/.hermes/config.yaml, and after restarting the session (or /reload-mcp) the eight tools will appear like any other tools.

Two run modes:

• Standalone mode (default): the server holds the camera's live session and publishes video to a local TCP port (tcp://127.0.0.1:<port>, or use --stream-port 9000 to fix the port). You can point OBS at it as a media source and treat the camera as a webcam.
• For bridge mode: if another program already holds the session,that session can be reused. This matters because Blink allows one live session per camera: the viewer and controller must share or take turns using it. Running two programs at the same time that each require an independent session will cause one of them to fail.

Use cases: Suitable for scenarios that need to programmatically view, aim at, and capture Blink camera footage, especially a Blink Mini with a pan/tilt base. Can be integrated into Claude Desktop, IDE agents, OBS, and more.

Limitations:

• Verified on a Blink Mini with a pan/tilt base. Other camera families use a different live transport (WebRTC with JSON-RPC commands, not this binary channel) and are not currently supported.
• One live session per camera.
• Blink limits sessions to 300 seconds; the server rotates at about 270 seconds, imperceptible to consumers.
• snapshot requires ffmpeg; it decodes one frame from the stream rather than opening a second session.
• Privacy and security: snapshot decodes whatever frame the camera is pointed at. This is stated in the tool description, and the agent is told to use it only when the user requests it. The server itself captures nothing. The server communicates directly with Blink, and the token cache does not store the password. Any bridge control plane is by design limited to loopback, because it moves a physical camera.

How it was built: The accessory channel is undocumented and was recovered from the official Android app (dex bytecode and native library symbol tables) and verified against the hardware: status 0x00 is idle, 0x10 is moving. Angles are signed single bytes. The same protocol knowledge is being contributed upstream to blinkpy, benefiting all Blink integrations, not just this server. blink_mcp/immi.py is byte-for-byte identical to the module submitted upstream, and will automatically switch to the upstream copy once it is published upstream. It is based on blinkpy, which implements the Blink cloud API and the IMMI transport.