# reolink-mcp

An open-source MCP (Model Context Protocol) server for Reolink cameras: lets
Claude — or any MCP client — see and control Reolink cameras on the local
network. Snapshots, device state, AI detection states, PTZ presets, and
deterrence controls (spotlight, siren, IR/white LED). Local network only, no
cloud.

**Market gap (verified 2026-07-08):** no dedicated Reolink MCP server exists
on GitHub, npm, or PyPI. Closest prior art requires a middleman:
`dedsxc/mcp-frigate` (needs Frigate NVR), `homeassistant-mcp` (needs Home
Assistant). This is a first-mover standalone niche.

A user with a Reolink camera adds `reolink-mcp` to their MCP client config,
asks "show me the front door camera," and gets a live snapshot — direct to
camera, no NVR or home-automation daemon in between.

<!-- mcp-name: io.github.ed-dryha/reolink-mcp -->

## Quickstart

Requires a Reolink camera reachable on the local network and its admin
username/password.

### 1. Create your camera config

Copy [`config.example.yaml`](config.example.yaml) to
`~/.config/reolink-mcp/config.yaml` (or point `RMCP_CONFIG_FILE` at a copy
anywhere else on disk):

```yaml
cameras:
  front_door:
    host: 192.168.1.44
    username: admin
```

Passwords never go in this file. Set one `RMCP_CAMERAS__<name>__PASSWORD`
environment variable per camera instead — `<name>` must exactly match the
camera's key in the YAML above (lowercase snake_case):

```bash
RMCP_CAMERAS__front_door__PASSWORD=<camera-password>
```

> **Concurrent-session limit:** Reolink cameras allow only a limited number
> of simultaneous sessions. `reolink-mcp` holds one `reolink-aio` session per
> configured camera for as long as the server runs — running it alongside
> another system that also holds sessions on the same cameras (an NVR,
> another MCP server, etc.) can exhaust that limit. See
> [Camera compatibility & session limits](#camera-compatibility--session-limits)
> below.

### 2. Add it to your MCP client

**Claude Code:**

```bash
claude mcp add reolink -- uvx reolink-mcp
```

**Claude Desktop** (`claude_desktop_config.json` — macOS:
`~/Library/Application Support/Claude/claude_desktop_config.json`, Windows:
`%APPDATA%\Claude\claude_desktop_config.json`):

```json
{
  "mcpServers": {
    "reolink": {
      "command": "uvx",
      "args": ["reolink-mcp"],
      "env": {
        "RMCP_CAMERAS__front_door__PASSWORD": "<camera-password>"
      }
    }
  }
}
```

**Any other MCP client** (generic stdio):

```json
{
  "command": "uvx",
  "args": ["reolink-mcp"]
}
```

That's it — ask your MCP client to "show me the front door camera."

## Tools

Built on [`reolink-aio`](https://github.com/starkillerOG/reolink_aio) and the
official [MCP Python SDK](https://github.com/modelcontextprotocol/python-sdk).
Every tool carries `readOnlyHint`/`destructiveHint` annotations so MCP
clients can gate approvals — Observe tools are read-only, Control tools
mutate camera state, and `set_siren` is the only tool marked destructive.

| Tool | Type | Purpose | Destructive |
|------|------|---------|-------------|
| `list_cameras` | Observe | Enumerate every configured camera with live connection status, model, and host | No |
| `get_device_info` | Observe | Model, firmware, hardware details for a camera | No |
| `get_capabilities` | Observe | What a camera supports — PTZ, siren, spotlight, IR/white LED, zoom, AI detection types — in neutral feature vocabulary | No |
| `get_states` | Observe | Current device state: day/night mode, white LED/spotlight, IR lights, siren capability, and motion | No |
| `get_recent_events` | Observe | Current AI detection state (person/vehicle/pet plus any camera-reported extras) from an on-demand poll, plus the plain motion flag | No |
| `get_snapshot` | Observe | Live still image from a camera, returned as an MCP image content block | No |
| `set_siren` | Control | Sound or stop a camera's siren — ~5s safe default, 60s hard cap, over-cap requests refused not clamped | **Yes** |
| `set_audio_alarm` | Control | Enable or disable a camera's siren/audio-alarm feature — needed when `set_siren` is accepted by the firmware but produces no sound | No |
| `set_spotlight` | Control | Turn a camera's spotlight on or off | No |
| `set_ir_lights` | Control | Set a camera's IR lights to `auto`, `on`, or `off` | No |
| `set_white_led` | Control | Turn a camera's white LED on or off, with optional brightness | No |
| `set_zoom` | Control | Zoom a camera to an absolute position (0-100) or a relative in/out step | No |
| `list_presets` | Control | List a camera's named PTZ presets | No |
| `ptz_move_to_preset` | Control | Move a camera to a named (or numeric) PTZ preset | No |
| `ptz_position` | Control | Read a camera's current pan/tilt/zoom position, naming the nearest saved preset when close | No |
| `ptz_guard` | Control | Configure a camera's PTZ guard point and auto-return (`set`/`goto`/`enable`/`disable`) | No |

## Safety

- **`RMCP_READ_ONLY=true`** starts the server with all 10 control tools
  stripped at startup — they are simply never registered, not hidden. A
  one-line notice is printed to stderr; the client sees a clean,
  observe-only server with no control tools in its registry at all.
- **`set_siren`** defaults to a ~5s burst when no duration is given, and
  refuses (never silently clamps) any request over its 60-second hard cap —
  a clear error asks for a shorter duration instead.
- **Capability gating**: every control tool checks the target camera's
  actual capabilities before sending any command, and refuses cleanly (e.g.
  "camera 'front_door' has no siren") instead of letting a raw API error
  from an unsupported feature reach the client.

## Camera compatibility & session limits

Validated live during development on:

| Camera | Validated capabilities |
|--------|-------------------------|
| P437 | Siren, spotlight, zoom |
| P320 | IR lights |

PTZ tools (`list_presets`, `ptz_move_to_preset`, `ptz_position`,
`ptz_guard`) are mock-validated only — real PTZ hardware validation is
pending.

**Concurrent-session limit:** `reolink-aio` maintains one long-lived session
per camera for the lifetime of the server process. Reolink cameras cap the
number of simultaneous sessions a camera will accept; running `reolink-mcp`
alongside another system that independently holds sessions on the same
cameras (an NVR, Reolink's own app, a second automation stack) can hit that
cap. This project's own development setup runs against cameras shared with a
second, independent system and has been exercised under that exact
coexistence condition — if you see login/session errors, check what else
currently holds a session on the camera first.

## License

MIT